Life Cycle of Test Case After about 3 months or so, 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 T Cs for the new CR (change request), from client, with one of my colleagues. Impa ct of that CR was huge and it was affecting a large number of TCs in my Test Sui te. Suddenly, I thought that I must share this experience with others too. A cou ple of days I organized my observations/experience related to the topic, and fin ally it is in front of you. There are 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 Softwar e Testers go through these two life cycles throughout their career. Yet in this domain, there exist 'Test Case Life Cycle' and it is also gone throu gh by the Software QAEs and Testers. Here are the main/must/basic 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 finalized (for new project or for a CR) and the testi ng plan is being written, at that time the ideas for test cases float in the min ds of Testers. Surely they think how they will be going to test the addressed fu nctionality. How they are going to ensure the application will work as desired. And most important, surely they get excited about thinking how they are going to bring the application or update to its knees. All the testers think test cases far prior to documenting or executing those. This is the 'Inception' stage of Te st 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 te sting plans and the templates of testing plans, so I am not going to peep in unw anted details at this stage and focusing on just my area of concern) including t he testing strategy. In Testing Strategy we plan the Test Cases. What will be te sted 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, s pecify integration testing plan, module testing plan, System and UAT Testing Pla n. All these are in fact the abstract level plans of test cases. In simplest wor ds we may say the identification of test scenario is the stage where TC is 'Plan ned'. The deliverables of this stage may be 'Testing Scenarios Document(s)', 'De cision Table(s)', 'State Transition Diagram(s)' 'Check list(s)' etc. 3. Documented After the abstract level planning, we are now ready to dig out 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 fa cilitating to document the TCs (e.g. RTH-Turbo; an open source freeware TC manag ement tool that personally I have used for more than 2 years and I like it the m ost. You may find an article about the review of this tool on the same forum). T his 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-put s/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 s tage of life cycle of TC. They may doubt about my skills and may advocate that o nce a test case is documented, it is ready to run or execute. Yet, experienced t esters would surely realize and understand why I am granting this activity the s tatus of a separate stage in TC life cycle. Most of the times, a test case is re ady for execution once it is documented. As soon as the CR is deployed or the Ap plication is released by the development, Testers may start executing their TCs written in TC document. But, for large and complex applications, where several m odules consume the data and services from each other or even from other applicat ions, the things are not so simple. In order to properly execute TCs, Testers ha ve 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 sp ecific test case. But when it comes to testing at module or integrating level, t here may be several inter-dependent or even independent requirements that may no t 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. Pers onally, I have done it several times especially for testing reports and other co mplex business logic. So, in my opinion, this activity must be recognized as a s olid 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 can escape from it in any way. All the Testers execute the test cases a nd 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 a nd 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 m ust be ranked too. By ranking I mean the categorization of Test Case in the cont ext of its future usage. Tester must at least add some comments whether the exec uted 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 prioritize the TCs in order to assure certain level of confidence for successful release in short time by executing mi nimum number of TCs. 7. Retired Last but not the least, is the 'Retired' stage of TC Life Cycle. Simply speak ing 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, som e TCs were updated and some TCs were falsified. So the falsified TCs must be ret ired. They may be kept in the repository (especially when using some TC manageme nt tool, a tester may not delete the TCs) but at least the tester must marked th ese 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 knowled ge and experience. All the testers go through this life cycle throughout their t esting career knowing or even un-knowing. All the Test cases go through these st ages. All the positive critics about this article are welcomed and thanked in anticipa tion.