Life Cycle of Test Case

This article was originally published at "vietnamesetestingboard" on Jan 17, 2011. As that forum is no more free, so I am republishing it here.

I found it better to write about a rarely discussed issue, though almost all the Testers are following it almost daily in their job, i.e. 'Life Cycle of Test Case'.

Idea for this article floated in my mind while discussing about updating a few TCs for the new CR (change request), from client, with one of my colleagues. Impact of that CR was huge and it was affecting a large number of TCs in my Test Suite. Suddenly, I thought that I must share this experience with others too. A couple of days I organised my observations/experience related to the topic, and finally it is in front of you.

The two most discussed and widely known Life cycles, in the domain of SQA, are 'STLC: Software Testing Life Cycle' and 'Bug Life Cycle' and all the Software Testers follow these two life cycles throughout their career. Yet in this domain, there exist 'Test Case Life Cycle' and it is also gone through by the Software QAEs and Testers.

Here are the main/basic/must stages of TC Life Cycle

1. Incepted

2. Planned

3. Documented

4. Ready to Execute (R2E)

5. Executed

6. Ranked in Repository (RiR)

7. Retired

Following are the details of these stages;

1. Incepted

  As the requirements are finalised (for new project or for a CR) and the testing plan is being written, at that time the ideas for test cases float in the minds of Testers. Surely they think how they will be going to test the addressed functionality. How they are going to ensure the application will work as desired. And most important, they get excited about thinking how they are going to bring the application or its knees. All the testers think test cases far prior to documenting or executing those. This is the 'Inception' stage of Test Case or I call it that a test case is 'Incepted'.

2. Planned

  This stage of life cycle of test case is not other than Testing Plan. In the testing plan, you describe several things (a hell of stuff is available about testing plans and the templates of testing plans, so I am not going to peep in unwanted details at this stage and focusing on just my area of concern) including the testing strategy. In Testing Strategy we plan the Test Cases. What will be tested how, where and when? This is the planning of Test Case given at an abstract level in Testing Plan. e.g. We describe the testing environment requirements, specify integration testing plan, module testing plan, System and UAT Testing Plan. All these are in fact the abstract level plans of test cases. In simplest words we may say the identification of test scenario is the stage where TC is 'Planned'. The deliverable of this stage may be 'Testing Scenarios Document(s)', 'Decision Table(s)', 'State Transition Diagram(s)' 'Check list(s)' etc.

3. Documented

  After the abstract level planning, we are now ready to explore the details of our identified test scenarios, or to formally define the inputs/outputs/pre-requisites of the TCs. Here we properly document the Test cases in MS-Word/MS-Excel or any tool that facilitates the documentation of Test Cases. This phase of Life Cycle of Test Case is the second to most prominent one and all the Testers perform this activity at least fortnightly. Documenting a test case is again a widely discussed topic and I don't feel it better to bore my reader by trying to re-invent the wheel. Precisely speaking, writing the inputs/out-puts/pre-requisites of a TC is what I am calling that the test case is 'Documented'.

4. R2E (Ready to Execute)

  Some new testers may wonder why to explicitly and separately name this as a stage of life cycle of TC. They might say that once a test case is documented, it is ready to run or execute. Yet, experienced testers would surely realise and understand why I am granting this activity the status of a separate stage in TC life cycle. Most of the times, a test case is ready for execution once it is documented. As soon as the CR is deployed or the Application is released by the development, Testers may start executing their TCs written in TC document. But, for large and complex applications, where several modules consume the data and services from each other or even from other applications, the things are not so simple. In order to properly execute TCs, Testers have to prepare special sort of data according to specific requirements of TCs. No doubt that in TCs you define the pre-requisites, but that are for the single specific test case. But when it comes to testing at module or integrating level, there may be several inter-dependent or even independent requirements that may not be catered by the pre-requisites of specific TCs. In this case Testers have to explicitly revise/add TCs and have to prepare the environment accordingly. Personally, I have done it several times especially for testing reports and other complex business logic. So, in my opinion, this activity must be recognised as a solid separate stage of TC Life Cycle. Conclusively I can say that completion of Testing Environment Preparation is the stage when TCs are 'Ready to Execute (R2E)'.

5. Executed

  This is the most prominent and must followed/faced stage of TC life Cycle. No tester has escape from it in any way. All the Testers execute the test cases and record the results. Tons of theory is also available on this topic and I don't want to bother the readers to read details about it. Once a test case is run and its 'Actual outputs' have been noted by the tester, the TC is 'Executed'.

6. Ranked in Repository (RiR)

  Another important stage of TC life cycle which in my opinion is not given as much focus, most of the times, as it deserves. Once a test case is executed it must be ranked too. By ranking I mean the categorisation of Test Case in the context of its future usage. Tester must at least add some comments whether the executed TC is going to be re-executed in Regression/UAT/System/Integration testing. This small indication may benefit a lot for him, especially in the crunch times when release date is near and he have to prioritise the TCs in order to assure certain level of confidence for successful release in short time by executing minimum number of TCs.

7. Retired

  Last but not the least, is the 'Retired' stage of TC Life Cycle. Simply speaking a TC is 'Retired' if it is of no worth to execute it ever again. e.g. Tester have documented several TCs for a scenario, but the latest CR implied some new/changed business rules. On the basis of these new rules some TCs were added, some TCs were updated and some TCs were falsified. So the falsified TCs must be retired. They may be kept in the repository (especially when using some TC management tool, a tester may not delete the TCs) but at least the tester must mark these as retired TCs in order to save him/her from wasting his time and efforts of re-executing useless TCS.

That’s all about the life cycle of a test case according to the best of my knowledge and experience. All the testers go through this life cycle throughout their testing career knowing or even unknowing. All the Test cases go through these stages. All the positive critique about this article all welcomed and thanked in anticipation.

Regards,

Enjoy Knowledge Sharing.