Five key challenges for agile testers tomorrow (#agileTD 2011)

Gojko Adzic (@gojkoadzic)talked about the five key challenges he sees for agile testers tomorrow. He has two basic statementes/ assumption which guide him to these challenges: Technology is changing fast and the field of agile testing is quite well defined today.
According to Gojko, these challenges are

1. shorter delivery phases
2. agile is now mainstream
3. faster feedback
4. large „enterprise“ projects
5. validating business, not software

Remark: One cool thing about this session was that Gojko asked the audience for answers to this challenges and gave away Specification-by-Example-posters for answers he liked.

Shorter delivery phases
As an example for extremely short delivery phases he named flickr: They are updating there site multiple times per day (code.flickr.com).
Gojko expects that other businesses are going this direction as well in the future. This makes it impossible to run overnight builds anymore, or execute (automated) tests, which need hours and hours to execute.
Gojko showed the picture of the „Agile Risk Donut“ as a symbolization for the risk based testing approach, asking the question „If you only have two seconds to eat this donut, where would you bite into it?“

Another approach to tackle this problem could be massive parallezation of (automated) test execution, to finish testing faster.
The problem that stakeholders even don’t agree themeselves leads to the fact, that there’s no single business goal. As solution Gojko proposes, that all the stakeholders vote on business goals (like described by James Whittaker: bit.ly/accMatrix)
Many businesses just live with different kind of risks (e.g. how often is twitter’s fail whale to see?), also very often we’re de-risking more then necessary. Gojko’s conclusion is, that certain risks just have to be accepted.
To work together with the community on this, he created the website visualizingquality.org

Agile is now mainstream
Everybody is now agile, if they have understood the basic principles or not, this leads to people which have no idea about what they’re meaning.
„Agile“ is loosing its meaning, very often when going agile, the Business Analyst becomes the Product Owner, and the Product Manager becomes Scrum Master, and no further changes are being applied.

Faster feedback
Faster feedback is needed because of shorter release cycles, but in anycase it’s better to have feedback as fast as possible.

The setup of adding one agile tester to a development team has some risks in itself. If the tester has to do the testing for all the programmers, the tester becomes the bottleneck, feedback is not delivered fast enough.

A nice idea from the audience to solve this has been to get rid of the labels like „tester“ and „programmer“.
What Gojko proposes is, to make the tester a „test architect“, who teaches the programmers about testing, e.g. exploratory testing, and distributes the testing to the programmers, but is not allowed to test himself.

Large „enterprise“ projects
What about the whole-team-approach when there’s more then one team? What if the hole is smaller then the team? (Here Gojko showed a nice picture of a couple of guys, trying to fit through a gutter-hole).
To his understanding, implementation teams that develop in parallel, and integrate there solutions at the end results in a very unstable solution.
One solution could be a technique named „context mapping“, which belongs to the context of DDD (Domain Driven Design).

Validating business, not software
The goal has to be to give end-to-end feedback on business-level, not only on the level of software.
Solutions to this could be to skip stupid statistics and delivering valuable metrics instead, using effect maps, and a reasonable measuring of the productions systems and reaction on these measurements.
He recommended the books How to measure anything by Douglas W. Hubbard and The Lean Startup by Eric Ries for further informations on the topic.

Summary
Gojko listed the following action items to summarize his talk:

• adapt principles and practices
• teach others how to test
• help business define & validate actionable metrics
• look at risk/ value areas & visualize it!
• draw up contexts to inform testing

Update: Gojko was so kind to publish the slides of his talk on slideshare: