for a feature from the GUI through the middleware and platform. Within a timebox, developers don't always complete an entire feature or feature set, but they do complete a coherent testable feature or chunk of a large feature. The developers and testers have deep feature-based knowledge of the code.
Contrast the lack of feature-based knowledge in a waterfall project with the focus on delivering features in an agile project and you'll find that implementing by feature may require much less exploratory execution post-coding, because the exploration needs to happen before coding starts. The exploration is best when defining user stories and also works well when developing system-level tests from the user stories. You can imagine the kinds of questions everyone can develop, the test design, and the learning from the questions and design before the code is even written.
On waterfall projects, exploratory system-level testing exposes architectural mistakes and side effects. But on agile projects, where the developers write architecturally coherent features, those waterfall kinds of errors tend to be exposed much earlier-or don't even exist.
What Kind of Testers Does an Agile Project Need?
My preference for agile testers who can script and code is based on the fact that the types of problems the testers need to discover tend to be more complex and cross features but don't necessarily cross the architecture. Those kinds of errors require critical thinking skills and the skills to get a computer to help explore the feature or feature set. Manual, black-box testers who don't understand the requirements, the design, or the code cannot do this kind of work.
Do I think all testers need to write code? In my perfect world, the answer would be yes so that the testers could perfectly know when to explore with questions, a keyboard, and with code. (My perfect developers use test-driven development and continuous integration, aside from being angels, too). But I know many valuable testers who don't write code yet understand the requirements, the system's architecture, and how the features are supposed to work. These testers can explore a feature manually or with help from someone who can write scripts or code. The key is that these testers are generalists.
Agile projects require true generalists as testers: people who have requirements-, design-, and code-understanding skills. Without those skills, they can't think critically enough about the product under development, and they might not be able to create enough variety of tests. If they understand the requirements, design, and code, they can turn that understanding into crafty tests. Some of those tests will be exploratory. Even some of the exploratory tests will need to be automated in order to repeat them. And, I've seen great testers on agile projects who can quickly create automated tests to do some of their exploration.
Agile projects require testers who can develop tests quickly and know which of those tests will need to be repeated. Testers should also be able to create those easily repeatable tests. I prefer tests that the testers can give to the developers and say, "Hey, run this and make sure you don't have those icky problems we discussed when we were talking about this user story."
Exploratory testing doesn't vanish on an agile project. It can't occur just at the end of a feature, iteration, or at the end of a project. Exploratory testing must occur at the beginning, as a part of the idea that the tests drive the system's design and code, in the middle as developers are sorting through what they are writing, and at the end to continue learning about the