Iterative testing is an emerging trend in the software development world that emphasizes solid testing and engineering principles in an agile development sprint. At Three Pillar, we employ an agile development methodology that breaks software product development into bite-size pieces – 2 week sprints to be exact. For QA testers, this requires the ability to work alongside development teams to get and refine acceptance criteria, write acceptance tests, and perform various types of testing.
What does a typical 2-week sprint look like for QA testers at Three Pillar? Usually it goes something like this:
Day 1: During the first day of the iteration, the highest priority stories are picked from the product backlog. The QA tester, along with the rest of the team members and the Product Owner, work to define the acceptance criteria for each user story. High-level questions are asked, and the acceptance criteria is written as part of each story.
In the second part of the planning session, the testing tasks for each story are identified and estimated. Some typical testing tasks are: “Define high level tests,” “Write automated tests,” “Perform manual exploratory testing,” “Write a GUI smoke test,” and “Generate test data.”
Days 2/3: On the 2nd and 3rd days of a sprint, the tester has conversations with the Product Owner to refine acceptance criteria for each story. The goal of these conversations is to elicit the details of what is expected from each feature. These conversations may go on the following day/s.
Also, during days 2 and 3 of a sprint, the Tester starts writing acceptance tests. This is a collaborative task that helps drive development as developers start focusing on writing code to pass the acceptance tests. The acceptance tests writing will span to the next few days. This process may also trigger new questions and new conversations with the Product Owner to clarify acceptance criteria.
Days 4/5: Days 4 and 5 are where exploratory testing typically begins, as the coding of the first stories may be completed. After making sure the “happy path” tests pass, the tester gets to use his creativity to discover conditions that no one may have thought of. Exploratory testing typically goes on until close to the end of the iteration.
Days 6/7: As soon as more of the stories are coded, the tester starts performing tests that verify combined functionality to make sure the new user stories that have been implemented integrate smoothly with the existing ones. This task will go on at least for a couple of more days.
Days 8/9: Assuming that the development of all the stories is done by the 8th or 9th day of the iteration, it is the time to run end-to-end tests that verify real-life scenarios. The goal of these tests is to check that all the new functionality increases the value of the software and it is ready for delivery.
Day 10: On the last day of the iteration, we demonstrate the stories to the Product Owner and get his or her acceptance. This demo usually requires some set up, like generating the appropriate data and making sure all the features are included in the demonstration. The whole team focuses on generating a polished version that can be presented to customers.
Note: The lifecycle of iteration testing may vary in each project. The duration of these tasks is not a fixed prescription; it is intended to be merely indicative. Sometimes tasks may end sooner and some times they may spill over to the end of the iteration.