Conventional Software Testing on a Scrum Team
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
If you're a professional software tester, or work in quality assurance, I consider you to be (like me) a "conventional software tester." Increasingly, conventional software testers are finding themselves on teams using the Scrum development process. For testers unfamiliar with iterative lifecycles, this can be a real challenge. Having been on a variety of projects using Scrum as a conventional software tester, I'll share three stories that describe different approaches for testers.
What Is Scrum?
According to the Scrum web site, "Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices." The best place to start learning about Scrum is the About page on the Scrum web site. It is a good idea to learn as much about Scrum as possible as a tester, particularly the principles and theory behind it. To understand the terminology in this article, I'll summarize some aspects of Scrum.
Scrum is a software management process that uses an iterative lifecycle and that focuses on communication, particularly feedback loops. Each iteration, called a Sprint, lasts about four weeks. A Sprint is a block of time in which development of software is completed. Ideally, a complete vertical slice of the application is delivered at the end of each Sprint. When each "slice" is put together, you have the complete product. A Sprint is a longer feedback loop in which the software developed in the last iteration is demonstrated to project sponsors and end users.
Short feedback loops also occur daily. These daily Scrum meetings last for 15 minutes, during which team members describe what they're working on and raise issues they might be encountering. The Scrum Master (the person who manages the administration of the project) runs the Scrum meetings.
Work to be done over the life of a project (a project contains several Sprints) is summed up in a Product Backlog. The Product Backlog contains a list of features needed for the project; this is the big picture for the project. Each Sprint also has a Sprint Backlog containing the tasks to meet a certain number of features in the Product Backlog. This describes the work for a particular Sprint. These documents are often written at a high level. Details can be filled in depending on practices of the team. How to execute tasks to meet the goals of the project is left to the team in Scrum, so it's common to see Scrum teams using Extreme Programming or other methodologies within Scrum.
For the tester, the most important things to note about Scrum are its iterative lifecycle and frequent communication. Both can require some adjustment on the part of the tester, who can be relied on to do all of the following:
- Test within each iteration, rather than at the end of a development lifecycle
- Decide what to test when a product is still unfinished
- Collaborate with team members rather than working in isolation
- Participate in daily status meetings that are a maximum of 15 minutes long
- Seek product information individually through testing, and work with other team members to figure out what to test, rather than testing from requirements documents