Our last Agile Mëtteg was about “Agile Testing – Fact or Myth”, it was held as a workshop, where the specific exercise executed has been developed by Alistair McKinnell, a description of the workshop can be found as shared Google Doc. To wrap it up shortly, a set of statements is given to the participants, and they have to decide for every statement wheter it is a fact about agile testing, or a myth.
We started the workshop by a short round of introduction of the participants, to see which roles they fulfill at their jobs and which background they have, also to see, what they already know about agile and agile testing. After that, we explained the exercise, and handed out the statements to the participants, which we previously had printed on cards.

We did two iterations of the game, therefor we added some more statements to the initial set provided by A. McKinnell:

• Switching roles is allowed.
• In Agile, the final quality sign off is missing.
• Everyone in an agile team has adequate testing skills.
• Agile teams don’t need testers.
• User Acceptance Testing is useless.
• Some tests just can not be automated.
• If it´s too trivial, no testing is needed.

Within one iteration the participants discussed the statements within two groups, and after all cards had been marked as “fact” or “myth” we did a round-up, and discussed the cards that had been marked differently by the two groups or where the participants had problems sorting the cards. These have been

Testers will have to learn how to program

Testers need to learn how to program to write automated tests
vs. Testers just need to learn to write tests in frameworks like FitNesse or Cucumber, and the programmers will write the fixture code.

Some tests just can not be automated

Not all tests can be automated
vs. All tests can be automated, but it might need a lot of effort.

Everyone in an agile team has adequate testing skills

This depends on the definition of “adequate”. Everyone can do testing in an agile team, but on different levels. E.g. the programmers don´t have very deep exploratory testing skills, but they can execute basic testing activities.

At the end we opened a general question & answer session concerning the speciality of “agile testing” where various topics have been discussed, including test automation, testability by design, test responsibility in an agile team, integration testing, and scheduling of test activities within a sprint and a release.

We described an example of session-based testing that we introduced for a customer team, which is a form a manual regression testing where tests are written on cards that are placed in a box. This session typically takes 1 to 1.5 hour every week (initially once a month) and most bugs are fixed on the same day. This is a very good illustration of switching the testing role as team members never pick the same cards in the box.

It also came out that many people had a special interest in methods for ATDD/ BDD which we tried to answer.

Following a list of ressources that have been used to prepare & run the workshop, also the references I gave during the workshop are listed here:

• Workshop: Agile Testing – Fact or Myth
• Top 3 Myths of Agile Testing
• Agile Testing Myths
• Which role does Testing play in an Agile development organisation?
• Agile Testing Environment
• Lisa Crispin & Janet Gregory – Agile Testing: A Practical Guide for Testers and Agile Teams
• Gojko Adzic – Specification by Example: How Successful Teams Deliver the Right Software
• Gojko Adzic – Test Driven .Net Development with Fitnesse (or as a free PDF)
• Gojko Adzic – DbFit: Test-driven database development
• Sharon L. Bowman – Training from the back of the room

Finally some phtographs of the session: