Agile Testing: A Practical Guide for Testers and Agile Teams

Agile isn’t faster all by itself. Agile is only a benefit in a world that acknowledges the value of adapting. And that adaptability needs to go all the way to whoever is funding the project. It is not enough for the team to be agile. The sponsors need to be agile too. Are all of the requirements really required? Do we know exactly what the software needs to look like from the start?

Agile is faster because feedback allows you to find and focus on the most valuable features. If you are certain you know what needs to be built, don’t use Agile. If you don’t have time to gather and act on feedback from customers, then don’t use Agile. If you are sure that everyone understands exactly what needs to be done from the start, then don’t use Agile.

Agile practices build a technical and organizational infrastructure to facilitate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down.

To us, the value of agile development isn’t that it’s faster but that it delivers enough value quickly enough to help the business grow and succeed. Testers play a key role in providing the feedback that allows that to happen.

Testers need feedback too. How do you know that you have the right examples of desired behavior from the customers? How do you know if the test cases you wrote reflected these examples correctly? Can the programmers understand what to code by looking at the examples you’ve captured and the tests you’ve created?

One of the most valuable skills you can learn is how to ask for feedback on your own work. Ask the programmers if they get enough information to understand requirements and whether that information guides their coding. Ask customers if they feel their quality criteria are being met. Take time in both the iteration planning meetings and retrospectives to talk about these issues and suggest ways to improve.

Success Factor 5: Build a Foundation of Core Practices

An old saying in the testing business is, “You can’t test quality into the product.” This is, of course, true of agile development as well. We feel you can’t deliver high-quality software without following some fundamental practices. While we think of these as agile practices, they’ve been around longer than the term “agile development,” and they’re simply core practices of successful software development.

Continuous Integration

Every development team needs source code management and continuous integration to be successful. You can’t test effectively if you don’t know exactly what you’re testing, and you can’t test at all if you have no code you can deploy. All team members need to check in their work at least once a day. Every integration must be verified by an automated build that includes tests to provide rapid feedback about the state of the software.

Implementing a continuous integration process should be one of the first priorities of any software development team. If your team doesn’t have at least a daily verified build, stop what you’re doing and get one started. It’s that important. It doesn’t have to be perfect to start with. If you have a huge system to integrate, it’s definitely more challenging. In general, though, it’s not that difficult. There’s a plethora of outstanding tools, both open source and commercial, available for this purpose.

See the bibliography for more information about continuous integration.

Test Environments

You can’t test productively without a test environment that you control. You need to know what build is deployed, what database schema is being used, whether anyone else is updating that schema, and what other processes are running on the machine.

Hardware is getting less expensive all the time, and more open source software is available that can be used for test environments. Your team must make the investment so that you can effectively conduct automated and manual exploratory tests quickly and efficiently. If there’s a problem with the test environment, speak up and let it be a problem for the team to solve creatively.

Manage Technical Debt

Even good software development teams, feeling time pressure, neglect refactoring or resort to quick fixes and hacks to solve a problem quickly. As the code becomes more confusing and hard to maintain, more bugs creep in, and it doesn’t take long before the team’s velocity is consumed by bug fixes and trying to make sense out of the code in order to add new features. Your team must constantly evaluate the amount of technical debt dragging it down and work on reducing and preventing it.