Software Testing Life Cycle
The Software Testing Life Cycle (or STLC), is a continuous process of validation and authentication. It's an integral part of software development, and needs to be managed with precision.
Before we begin, there are a few points that should be clear. First off, STLC and Systems Development Life Cycle (SDLC) are not the same, although they aren't completely different either. STLC is a part of SDLC, and therefore cannot exist without it. The two are merged in such a way that each step in STLC should coincide with a particular point in SDLC, making it a repeating process even after the completion of a software.
Secondly, STLC should always concur with the following basic points:
The testing process should satisfy the preliminary design and development process.
It should be able to be easily modified as the need arises.
It should meet all needs of the stakeholders.
The software testing life cycle consists of a series of stages through which a software product goes through, and describes the various activities pertaining to testing that are carried out on the product. Here's an explanation of the STLC along with a flowchart.
Introduction to Software Testing Life Cycle
In every organization, testing is an important phase in the development of a software product. However, the way it is carried out differs from one organization to another. It is advisable to carry out the testing process from the initial stages with regard to the SDLC to avoid any complications.
The Need For a Constant Testing Process
Conventional methods prescribe testing to be a phase independent of designing and creating. It comes after the entire module is constructed and essentially 'ready for testing'. But something like that cannot be done in software development. Let's say we were to roughly divide a conventional constructive method into four parts: gathering requirements, design, building, and post-construction. Now, with the depth of coding required to complete each step, bugs are bound to pop up in all stages. But if you don't test, you'll never find out where the bug is. If a bug was found while gathering requirements, the cost and time taken to resolve the issue would be very small. As the process gets more and more complicated, finding a bug during building or designing would be exponentially tougher to resolve. Even if you were to employ a testing phase between building and post-construction, the chances of finding all the bugs aren't always 100%. And if you miss one, which gets on to the post-release version, the cost of resolving the bug will be astronomical.
The Software Testing Life Cycle (or STLC), is a continuous process of validation and authentication. It's an integral part of software development, and needs to be managed with precision.
Before we begin, there are a few points that should be clear. First off, STLC and Systems Development Life Cycle (SDLC) are not the same, although they aren't completely different either. STLC is a part of SDLC, and therefore cannot exist without it. The two are merged in such a way that each step in STLC should coincide with a particular point in SDLC, making it a repeating process even after the completion of a software.
Secondly, STLC should always concur with the following basic points:
The testing process should satisfy the preliminary design and development process.
It should be able to be easily modified as the need arises.
It should meet all needs of the stakeholders.
The software testing life cycle consists of a series of stages through which a software product goes through, and describes the various activities pertaining to testing that are carried out on the product. Here's an explanation of the STLC along with a flowchart.
Introduction to Software Testing Life Cycle
In every organization, testing is an important phase in the development of a software product. However, the way it is carried out differs from one organization to another. It is advisable to carry out the testing process from the initial stages with regard to the SDLC to avoid any complications.
The Need For a Constant Testing Process
Conventional methods prescribe testing to be a phase independent of designing and creating. It comes after the entire module is constructed and essentially 'ready for testing'. But something like that cannot be done in software development. Let's say we were to roughly divide a conventional constructive method into four parts: gathering requirements, design, building, and post-construction. Now, with the depth of coding required to complete each step, bugs are bound to pop up in all stages. But if you don't test, you'll never find out where the bug is. If a bug was found while gathering requirements, the cost and time taken to resolve the issue would be very small. As the process gets more and more complicated, finding a bug during building or designing would be exponentially tougher to resolve. Even if you were to employ a testing phase between building and post-construction, the chances of finding all the bugs aren't always 100%. And if you miss one, which gets on to the post-release version, the cost of resolving the bug will be astronomical.
No comments:
Post a Comment