Listed below are the typical steps in a Software Testing Life Cycle (STLC). Note that these are not set in stone and can change per your requirements. Phases can collapse or get more granular as needed. I have tried to list steps in a fairly granular fashion. Several of these can be combined into a larger "phase".
Requirements analysis and review
This covers functional and non-functional requirements and their impact on testing. An RTM (requirements traceability matrix) may be prepared along with defining the acceptance criteria/done definition for various requirements. Additionally, any specific testability requirements may be conveyed to stake holders while considering automatability of requirements. In the past, one might consider a formal requirements sign-off too with testing as one of the stakeholders. In the Agile world, a high level set of requirements can be agreed upon (perhaps at an epic level or even high level stories) with changes expected as teams go through each iteration or sprint (e.g. Scrum).
Design review
Continuing from the previous stage, here a greater degree of clarity around requirements is available. Teams may review design and mockups which help the test team with preparation of test plan and cases. Teams may iterate until acceptable designs are identified.
Test planning
This is the stage where test plan(s) is/are prepared including initial effort estimates, resource plans, test tool identification, etc. I listed out test plans to mean both an overall test plan and individual test plans for sub-components or modules as the case may be. Depending on the size and nature of your application, you may have just one over arching plan or an overall plan supported by sub-level plans.
Test design
The test team creates test cases followed by cross-functional reviews typically involving development team and product managers/owners. These could be automated and/or manual tests.
Test environment preparation
Here, the test bed/lab setup is performed. Any 3rd party software required is installed and integrated. Product builds are installed on this environment and sanity/smoke tested prior to starting an extensive test campaign. In summary, all required hardware and software components are setup, integrated and made ready.
A point to note - the ideal goal here is to mimic the real world or production environment. Depending on your resourcing situation, you may either have a replica of your production deployment or a close enough clone.
Test data preparation
Necessary test data required to execute all identified tests is prepared. The nature of data to be prepared is dependent on the type of inputs accepted by the SUT. While this step may sound simple, there are considerations to be made on the data to be selected. Unless you have unlimited time and resources at your disposal, you will need to pick a subset of data which constitutes a representative sample whose successful execution will provide a certain degree of confidence in the ability of your application to handle most (any) inputs. Let's call it the test data selection problem which we will touch upon in a subsequent post. For now, know that selecting the right set of data has a significant bearing on the outcome of your testing exercise/campaign. Note that the necessary workload needs to be simulated to match real world usage.
Test Oracle preparation, Test stubs and driver preparation as needed, Test termination/exit criteria definition
Here we identify a mechanism or an entity which is used to confirm whether the software performed correctly or otherwise. An example would the requirements definition itself which the application must satisfy. For automated tests, we need to develop suitable test oracles (e.g. functions which return a boolean value or some such method) to check if the observed behavior is accurate. Other tasks include preparing any needed stubs and drivers and determining the criteria for terminating your tests.
Test execution
True to it's name, this stage involves running of the tests and reporting results.
Test results analysis and reporting defects
We could combine this with the previous stage but I have separated it out for a little bit more clarity. In this stage, test results are analyzed and defects (bugs) reported.
Fix verification, retest
Defects (bugs) reported are fixed and fixes are verified. Necessary regression tests are run to ensure fixes haven't introduced new defects. In the real world, expect fix failures, unexpected regressions and lot of duh moments.
Test closure
Prepare and submit the report of all testing performed, defects found, etc. and relevant artifacts. You would normally archive it at some location for later reference.
Requirements analysis and review
This covers functional and non-functional requirements and their impact on testing. An RTM (requirements traceability matrix) may be prepared along with defining the acceptance criteria/done definition for various requirements. Additionally, any specific testability requirements may be conveyed to stake holders while considering automatability of requirements. In the past, one might consider a formal requirements sign-off too with testing as one of the stakeholders. In the Agile world, a high level set of requirements can be agreed upon (perhaps at an epic level or even high level stories) with changes expected as teams go through each iteration or sprint (e.g. Scrum).
Design review
Continuing from the previous stage, here a greater degree of clarity around requirements is available. Teams may review design and mockups which help the test team with preparation of test plan and cases. Teams may iterate until acceptable designs are identified.
Test planning
This is the stage where test plan(s) is/are prepared including initial effort estimates, resource plans, test tool identification, etc. I listed out test plans to mean both an overall test plan and individual test plans for sub-components or modules as the case may be. Depending on the size and nature of your application, you may have just one over arching plan or an overall plan supported by sub-level plans.
Test design
The test team creates test cases followed by cross-functional reviews typically involving development team and product managers/owners. These could be automated and/or manual tests.
Test environment preparation
Here, the test bed/lab setup is performed. Any 3rd party software required is installed and integrated. Product builds are installed on this environment and sanity/smoke tested prior to starting an extensive test campaign. In summary, all required hardware and software components are setup, integrated and made ready.
A point to note - the ideal goal here is to mimic the real world or production environment. Depending on your resourcing situation, you may either have a replica of your production deployment or a close enough clone.
Test data preparation
Necessary test data required to execute all identified tests is prepared. The nature of data to be prepared is dependent on the type of inputs accepted by the SUT. While this step may sound simple, there are considerations to be made on the data to be selected. Unless you have unlimited time and resources at your disposal, you will need to pick a subset of data which constitutes a representative sample whose successful execution will provide a certain degree of confidence in the ability of your application to handle most (any) inputs. Let's call it the test data selection problem which we will touch upon in a subsequent post. For now, know that selecting the right set of data has a significant bearing on the outcome of your testing exercise/campaign. Note that the necessary workload needs to be simulated to match real world usage.
Test Oracle preparation, Test stubs and driver preparation as needed, Test termination/exit criteria definition
Here we identify a mechanism or an entity which is used to confirm whether the software performed correctly or otherwise. An example would the requirements definition itself which the application must satisfy. For automated tests, we need to develop suitable test oracles (e.g. functions which return a boolean value or some such method) to check if the observed behavior is accurate. Other tasks include preparing any needed stubs and drivers and determining the criteria for terminating your tests.
Test execution
True to it's name, this stage involves running of the tests and reporting results.
Test results analysis and reporting defects
We could combine this with the previous stage but I have separated it out for a little bit more clarity. In this stage, test results are analyzed and defects (bugs) reported.
Fix verification, retest
Defects (bugs) reported are fixed and fixes are verified. Necessary regression tests are run to ensure fixes haven't introduced new defects. In the real world, expect fix failures, unexpected regressions and lot of duh moments.
Test closure
Prepare and submit the report of all testing performed, defects found, etc. and relevant artifacts. You would normally archive it at some location for later reference.
