A Day in the Life (of a Software QA Tester)

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.

Ricardo Aprigliano

Ricardo Aprigliano

Product Engineering Manager

Ricardo Aprigliano is a Product Engineering Manager in 3Pillar’s Buenos Aires, AR office. Ricardo’s specialties include quality improvement, agile testing and managing talented teams of software developers and designers in a lean and agile development environment. He has been in the software industry for 16 years, contributing from different roles to deliver applications for financials, telecommunications, government and health care. Prior to joining 3Pillar, Ricardo worked as the Argentina QA Lead for Network Solutions and the QA Lead for Cubecorp. Outside of work, Ricardo’s interests include studying modern history, cooking, and spending quality time with his family.

Leave a Reply

Related Posts

Building a Microservice Architecture with Spring Boot and Do... This is the first post in what will be a 4-part series on building a microservice architecture with Spring Boot & Docker. This post will provide a...
Building a Microservice Architecture with Spring Boot and Do... Part II: Getting Set-Up and Started Introduction and Tools In this part, we'll get to work on building out the solution discussed in Part I. I'm goi...
Building a Microservice Architecture with Spring Boot and Do... Part III: Building Your First Microservice, its Container, and Linking Containers We're about ready to actually get started with building a microserv...
Building a Microservice Architecture with Spring Boot and Do... This is the fourth blog post in a 4-part series on building a microservice architecture with Spring Boot and Docker. If you would like to read the pre...
Innovation Wars, with Scott Bales Scott Bales joins us on this episode of The Innovation Engine to dive into the concept of "innovation wars." Among the topics we'll discuss are what c...


Sign up today to receive our monthly product development tips newsletter.