There are some discussions around do we need testers in scrum model of development and can we Increase quality by putting testers in the Scrum team?
We do hear both objections:
- “But that’s obvious! Scrum teams are supposed to be cross functional!”
- “Scrum teams are supposed to be role-less! We can’t have a guy who is only a tester!”
Yes, the role of the tester has changed in a scrum team and what people mean by “tester” in this case is “A guy whose primary skill is testing” rather than “a guy whose role is to do only testing”.
Why do we need Testers part of the Scrum Team?
First of all, developers are often quite lousy testers, especially testing their own code. Secondly, it’s not easy for the developers to test all the use cases and work flow of the system as the primary focus of the developers is unit testing and the testing role should be dedicated to test the overall work flow.
The tester is the “signoff guy”
In addition to being “just” a team member, the tester has an important job. He is the signoff Guy. Nothing is considered “done” in a sprint until he says it’s done. Most of the times, people found that developers often say something is done when it really isn’t.
Even if you have a very clear definition of “done” developers will frequently forget it. We programmers are impatient people and want to move on to the next item ASAP. 🙂 So how does Mr. T (our tester) know something is done then? Well, first of all, he should (surprise) test it! In many cases it turns out that something a developer considered to be “Done” wasn’t even possible to test! Because it wasn’t checked in, or wasn’t deployed to the test server, or couldn’t be started, or whatever. Once Mr. T has tested the feature, he should go through the “done” checklist (if you have one) with the developer.
For example if the definition of “done” mandates that there should be a release note, then Mr. T checks that there is a release note. If there is some kind of more formal specification for this feature then Mr. T checks up on that as well. Etc. A nice side effect of this is that the team now has a guy who is perfectly suited to organize the sprint demo.
What does the tester do when there is nothing to test?
This question keeps coming up. Mr. T: “Hey Scrum master, there’s nothing to test at the moment, so what should I do?” It may take a week before the team completes the first story, so what should the tester do during that time?
Well, first of all, he should be preparing for tests. That is, writing test specs, preparing a test environment, etc. So when a developer has something that is ready to test, there should be no waiting, Mr. T should dive right in and start testing.
If the team is doing TDD then people spend time writing test code from day 1. The tester should pair-program with developers that are writing test code. If the tester can’t program at all he should still pair-program with developers, except that he should only navigate and let the developer do the typing. A good tester usually comes up with different types of tests than a good developer does, so they complement each other.
If the team is not doing TDD, or if there isn’t enough test-case writing to fill up the tester’s time, he should simply do whatever he can to help the team achieve the sprint goal. Just like any other team member. If the tester can program then that’s great. If not, your team will have to identify all non-programming tasks that needs to be done in the sprint.
When breaking down stories into tasks during the sprint planning meeting, the team tends to focus on programming tasks. However usually there are lots of non-programming tasks that need to be done in the sprint. If you spend time trying to identify the non-programming tasks during the sprint planning phase, chances are Mr. T will be able to contribute quite a lot, even if he can’t program and there is no testing to do right now.
Examples of non-programming tasks that often need to be done in a sprint:
- Set up a test environment.
- Clarify requirements.
- Discuss deployment details with operations.
- Write deployment documents (release notes, RFC, or whatever your organization does).
- Contact with external resources (GUI designers for example).
- Improve build scripts.
- Further breakdown of stories into tasks.
- Identify key questions from the developers and get them answered from the business stake holders.
On the converse side, what do we do if Mr. T becomes a bottleneck? Let’s say we are on the last day of the sprint and suddenly lots of stuff is done and Mr. T doesn’t have a chance to test everything. What do we do? Well we could make everybody in the team into Mr. T’s assistants. He decides which stuff he needs to do himself, and delegates grunt testing to the rest of the team. That’s what cross functional teams are all about!
So in summary, Mr. T does have a special role in the scrum team, but he is still allowed to do other work, and other team members are still allowed to do his work. How can Scum model make the Tester’s job easy and increase Quality?
Increase quality by doing less per sprint
This goes back to the sprint planning meeting. Simply put, don’t cram too many stories items into the sprint! If you have quality problems, or long acceptance test cycles, do less per sprint!
This will almost automatically lead to higher quality, shorter acceptance test cycles, fewer bugs affecting end users, and higher productivity in the long run since the team can focus on new stuff all the time rather than fixing old stuff that keeps breaking. It is almost always cheaper to build less, but build it stable, rather than to build lots of stuff and then have to do panic hot-fixes, Maintenance and Service Packs. 🙂