Last week Pete Walen asked me the following question via twitter: The Question (read it carefully!): What is it that makes Agile Testing different from “other” testing?

Agile vs agile?

What is agile testing? And what is agile? Let me first say that I do not distinguish agile and Agile. For me it is all the same. Agile is a mindset, a way of looking at the world. For me it is not a process or method. It is more a container than a way of working. This blogpost discusses agile vs Agile and I like it. It describes agile as a mindset and Agile with a capital A as something commercial: “The problem here is that all of these sensible suggestions got formalized into “Agile”, with a Capital A. This set of suggestions for “things that seem to work” got boxed up into a package with a bow on top, to be sold to companies and managers.”

Agile testing?

And agile testing? What is agile testing? I rather say testing in an agile context instead of agile testing. Good testing in an agile context is done by looking first to the details of the specific situation. Remember the 7th principle of context-driven testing: “Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.”

Testing is an essential part of software realization. Implementing testing in an agile context is a challenge. It comes with some interesting challenges for testers:

  • by the iterative nature of working, there is less time to test compared to the testing most of us are used to in a more traditional (waterfall) context. It requires a different approach to testing. There is a different phasing to testing in an agile environment.
  • how can I make sure that I can perform sufficient testing fast enough to keep up with the project?
  • testers need to ensure that “self-managing teams” do enough testing
  • cope with the changing team dynamics in which people work and where interaction is important
  • integrating structured testing in an environment where change is common
  • deliver added value as a tester when there is no software to test

Testers need to deliver immediate value. In an agile environment rapid feedback allows the team continuously forward. Testing should instantly provide useful and understandable information about the status of the products in development. It allows the team to deliver insightful value to the business continuously and to make maximum progress.

Different?

So what is the difference? I think the testing itself is not so much different, it is the context in which you do the testing is different. If you are aiming on differences between waterfall and agile my list of most important differences would be:

  • less time to prepare, execute and report (short sprints).
  • iterative and incremental approach: excellent unit testing is essential.
  • test automation (some rather call it automated checking or tool assisted testing) is essential for fast feedback and continuous integration.
  • role change: less testing, more coaching. Testers become “test coaches” or “quality directors” to make sure the team is doing sufficient testing. Enough (not too much nor too little) and of good quality.
  • cope with less certainty: change is common. Test documentation needs to deal with change by being transparent, using simple dashboards and light weight test documentation.
  • team work: where many testers are used to work in TEST teams, they are now working in DEVELOPMENT teams.
  • continuous critical thinking: testers need to help the team by thinking critical about the impact and risks. Where testers were used to do that upfront while writing documents like master test plans, they now have to do that continuously throughout the project: in grooming sessions, daily standups, planning sessions, etc. But also in their own work: making choices about what to cover: broad and depth.

Again: the testing itself is not so much different, it is the context in which you do the testing is different!