A lot of people say agile projects are different than “traditional” projects. They might be, but not in the ways people typically think they are. Agile projects are faster (short iterations, working software sooner, and a sense of urgency in the entire team from the first day), but they still have many of the same problems as some traditional project lifecycles.

For testers, the biggest challenge of being on an agile project team is that the software is always changing. With new code being pushed into the test environment daily or even hourly, the system you’re testing becomes a moving target. Dealing with that kind of change can require different approaches to testing, with different skills, tactics, and tools. There are certain aspects of testing software that don’t change just because the project team is using an agile approach to implement software, particularly in the mechanics of test execution, but some testers may need to make significant changes to their testing approach if they are going to add value on an agile software project.

Exploratory testing is invaluable to an agile project. In many ways, exploratory testing embodies the Agile Manifesto, by emphasizing responsiveness to change and working software over things like comprehensive documentation and following a plan. As a result, the skills and tactics of exploratory testing (chartering, branching, backtracking, modeling, resourcing, etc.) are going to be very valuable to you as you test software that is always on the move.

Another thing that makes exploratory testing useful is that it doesn’t take a lot of advance preparation. This is important because most agile methodologies emphasize volunteerism and constant planning. Volunteerism means that within the scope of a sprint, team members choose what they’re going to work on when. Constant planning means that features are re-prioritized at the beginning of each sprint based on the ever-changing values of the project stakeholders. The net effect is simple: There’s no comprehensive project plan. Feature delivery schedules have the potential to change every week. As a result, you need to be able to test anything, anytime, with as little upfront preparation as possible.

In a rapidly changing project, it is important that you make good decisions about what to test and when. If you test features that aren’t ready (an easy mistake to make when the software is evolving quickly) and generate defects, you will lose credibility with the rest of the team. You need to always be aware of the state of the software. That means talking to developers, paying attention in daily stand-ups, and being adept at whatever systems are used to keep track of project work.