Agile Testing: A Practical Guide for Testers and Agile Teams

People often say, “Our management won’t give us time to do things right, we don’t have time to refactor, and we’re under tight deadlines.” However, it’s not hard to make a clear business case showing what growing technical debt is costing the company. There are many ways to measure code and defect rates that can translate technical debt into its impact on the bottom line. Merely pointing to your decreasing velocity may be enough. Businesses need their software development teams to remain consistently productive. They may have to reduce the scope of their desired features in order to allow enough time for good, test-guided code design and good practices such as continual small refactoring.

Good coverage from automated regression tests is key to minimizing technical debt. If these are lacking, budget time in each iteration to build up the automated tests, plan a “refactoring iteration” to upgrade or add necessary tools, and write tests and do major refactoring efforts. In every iteration, take the time to guide code with tests, refactor the code you’re touching as needed, and add automated tests where they’re missing. Increase your estimates to account for this work. In the long run, the team will be able to go much faster.

Working Incrementally

One reason agile teams are able to create a quality product is that they work on a small scale. Stories represent a few days of work, and each story may be broken into several thin slices or steel threads and built step-by-step. This allows testing each small piece and then incrementally testing as the pieces are put together.

If your team members are tempted to take on a large chunk of functionality at once, encourage them to look at a stepwise approach. Ask questions: “What’s the central business value in this story? What’s the most basic path through this piece of code? What would come next?” Suggest writing task cards to code and test the small pieces, get a proof of concept for your design, and confirm your test and test automation strategy.

Read more about small chunks and thin slices in Chapter 8, “Business-Facing Tests that Support the Team.”

Coding and Testing Are Part of One Process

People who are new to agile often ask agile testers, “What do you do until all the stories are finished and you can test?” Experienced agile practitioners say, “Testers must be involved throughout the whole iteration, the whole development process. Otherwise it doesn’t work.”

Testers write tests, based on examples provided by customers, to help programmers understand the story and get started. Tests and examples provide a common language that everyone involved in producing the software understands. Testers and programmers collaborate closely as coding proceeds, and they both also collaborate closely with the customers. Programmers show testers the functionality they’ve written, and testers show programmers the unexpected behaviors they’ve found. Testers write more tests as coding proceeds, programmers make them pass, and testers do more exploratory testing to learn whether the right value has been delivered. Each agile iteration consists of dozens of constant, quick, incremental test-code-test-code-test iterations.

When this collaboration and feedback cycle is disturbed, and testing is separated from development, bad things happen. If a story is tested in the iteration after which it was coded and bugs are found, the programmer has to stop working on the new story, remember how the code worked for the last iteration’s story, fix it, and wait for someone to test the fix. There are few facts in software development, but we know for sure that bugs are cheaper to fix the sooner they’re found.

When coding is constantly guided by tests, and testing happens alongside coding, we’re much more likely to achieve the behavior and provide the value that the customer wanted. Testing is a team responsibility. If your team doesn’t share this view, ask everyone to think about their focus on quality, their desire to deliver the best possible product, and what steps they can take to ensure that the team achieves its goals.

Read more about coding and testing in Chapter 18, “Coding and Testing.”

Synergy between Practices

A single agile development practice such as continuous integration can make a difference, but the combination of multiple agile practices is greater than the sum of the parts. Test-driven design, collective code ownership, and continuous integration together deliver rapid feedback, continually improving code design and the ability to deliver business value quickly. Automating tests is good, but using automated tests to drive development, followed up by exploratory testing to detect gaps or weaknesses, is many levels of magnitude better.