Agile Testing: A Practical Guide for Testers and Agile Teams

Your job as tester is to make sure enough time is allocated to testing, and to remind the team that testing and quality are the responsibility of the whole team. When the team decides how many stories they can deliver in the iteration, the question isn’t “How much coding can we finish?” but “How much coding and testing can we complete?” There will be times when a story is easy to code but the testing will be very time consuming. As a tester, it is important that you only accept as many stories into the iteration as can be tested.

If you have to commit, commit conservatively. It’s always better to bring in another story than to have to drop one. If you have high-risk stories that are hard to estimate, or some tasks are unknown or need more research, write task cards for an extra story or two and have them ready on the sidelines to bring in mid-iteration.

As a team, we’re always going to do our best. We need to remember that no story is done until it’s tested, so plan accordingly.

Testable Stories

When you are looking at stories, and the programmers start to think about implementation, always think how you can test them. An example goes a long way toward “testing the testability.” What impact will it have on my testing? Part III, “The Agile Testing Quadrants,” gives a lot of examples of how to design the application to enable effective testing. This is your last opportunity to think about testability of a story before coding begins.

Janet’s Story

One team I worked with told me about issues they had in the previous release. The team was rewriting the first step of a multistep process. What they didn’t anticipate was that when the development on the new step started, the rest of the process broke. No testing could be done on any other changes in that iteration until the whole first step was finished.

Testability had not been considered when planning the story. In the next release, when they decided to rewrite the second step, they learned from their previous mistake. The programmers created an extra button on the page that allowed the testers to either call the new page (in flux) or the old page to allow them test other stories.

Remember to ask, “How can we test this?” if it is not obvious to you.

—Janet

During iteration planning, think about what kind of variations you will need to test. That may drive other questions.

Janet’s Story

During one iteration planning meeting that I was in, the programmers started talking about implementation and drawing pictures on the whiteboard to show what they were thinking.

I thought about it for a bit and asked the question, “Can it be done more simply? The permutations and combinations for testing your proposed implementation will make testing horrendous.”

The programmers thought about it for a couple of minutes and suggested an alternative that not only met the customer’s needs, but was simpler and easier to test. It was a win-win combination for everyone.

—Janet

When testability is an issue, make it the team’s problem to solve. Teams that start their planning by writing test task cards probably have an advantage here, because as they think about their testing tasks, they’ll ask how the story can be tested. Can any functionality be tested behind the GUI? Is it possible to do the business-facing tests at the unit level? Every agile team should be thinking test-first. As your team writes developer task cards for a story, think about how to test the story and how to automate testing for it. If the programmers aren’t yet in the habit of coding TDD or automating unit tests, try writing a “XUnit” task card for each story. Write programming task cards for any test automation fixtures that will be needed. Think about application changes that could help with testing, such as runtime properties and APIs.

Lisa’s Story

The application that I work on has many time- and date-dependent activities. The programmers added a runtime server property to the web application to set the server date. I can specify a date and time override, and when the server starts up, it behaves accordingly. This allows kicking off monthly or quarterly processes with a simple override. This property has helped in testing a wide variety of stories.

Markus Gärtner [2008] told us his team has a similar property, a “DATE_OFFSET” counted in “days to advance.” However, this was only used by the Java components of the application where the business logic lives. The back-end systems in C and C++ don’t use the date offset, which caused a problem.

—Lisa

If you have similar issues because other teams are developing parts of the system, write a task card to discuss the problem with the other team and come up with a coordinated solution. If working with the other team isn’t an option, budget time to brainstorm another solution. At the very least, be mindful of the limitations, and adjust testing estimates accordingly and manage the associated risk.

Lisa’s Story