This is the title of a talk I submitted to two conferences this year. At one it made it into the program: the Agile Testing Days in Potsdam. It’s a pity that I got sick over the weekend, so I won’t give that talk. Anyways, I thought people might be interested in the talk, so I wanted to share some thoughts on my blog about it.

Initially I planned to deliver a classic presentation. Standing in the front, speaking, answering questions afterwards. I would have picked on the things that Michael Bolton mixed with the stuff I learned from Elisabeth Hendrickson, Lisa Crispins, and Janet Gregory. I would have talked about what testing does in Agile, what quality means in Agile, and why we should give up hunting for quality assurance since it’s spread among the whole team. In fact, us testers never were in the position to assure any quality, but it needed Agile to make this transparent to most of us it seems (I’m exaggerating). You don’t believe me? I recently asked a client with a stage-gate process what happens if they refuse the tester’s quality gate. The answer was simple: “The next gate overrules that decision.”

Then I joined a class called Training from the back of the room. While I had read the book back in January, and heavily got inspired by it, I took these thoughts further during Sharon’s class. During a break I talked to her whether she used the 4C model also for her presentations. She explained to me how she did it, so I prepared myself for this talk using the 4Cs: Connections, Concept, Concrete Practice, and Conclusion. I also came up with a two level model of the 4Cs. The connections had Connections, Concept, and Conclusion parts in them, as well as the Concept and Conclusion part. Fascinating.

So, the first third of the talk would have been on the connections of the attendees to the material. What do you know about Quality Assurance? What is Quality Assurance? We would then have digged deeper. What practices do you consider are part of QA, and who is actually responsible of it?

The next thing was to dig deeper into what an Agile team does, and how that assures quality. Picking up some of the things I wrote about in How to reduce the cost of testing, the attendees would have split into three groups digesting for some information on their own, and sharing this knowledge with the other participants later.

Now, the final piece was a call for action. Having discussed all these quality assuring practices, we would have compiled together a list of things an Agile tester actually needs to do. At the first GATE workshop we ended up with the insight that testers don’t need any particular practices that can also help a traditional tester. But this part would yield a toolbag for testers to become Agile in the long-run.

While I sketched out my ideas here, I hope you got a hook on the topic. I am quite certain to run such a workshop during the next year. I will re-submit this talk to some more conferences – maybe using a different title. Being inspired by the first GATE workshop, I still want to digest deeper into what successful Agile testers do differently from the ones that – well, you know what.