Some learned lessons from the Agile Testing Days (part 3)

In the week of the 14th of November I was at the Agile testing days in Potsdam and I’m going through my notes of this event. It is unbelievable how many ideas one can get by visiting presentations, talking to other testers and discussing test topics. This is part 3 of this blog.

Understand business goals and research alternatives. (Gojko Adzic (@gojkoadzic) - “Product Management using Effect Maps”)
Why is a feature really wanted by the business? This is something all members of a team should be aware of. This is because of awareness of the goal. The goal is a business goal and technology is a way to reach such a business goal. For example increasing the registered users by a million. With a mindmap technique (effect mapping) you could search for all alternatives for reaching that goal. Discuss all alternatives, draw this mindmap and get fresh ideas about this. Maybe the feature requested was not the fastest or the right way to get to the goal. Maybe an advertisement campaign could do the same for less money. Always research the alternatives and a good way is using a effect mapping.

Understand the "Why?

Some learned lessons that I could take right with me in my briefcase: Lisa Crispin(@lisacrispin) & Janet Gregory(@janetgregoryca): “Appendix A: Lessons Learned since Agile Testing Was Published”

• Try to understand the business value of a feature that is asked to be implemented (also mentioned by Gojko Adzic with effect mapping talk)
• Test automation: Needed, but maybe developers can do a better job scripting than you as a tester.
• People should be allowed to make mistakes, from mistakes you learn more than when everything went ok.
• Learn continuously in your job: opportunities enough. (also mentioned by Huib Schoots)

The next part of this posting come from some discussions and my own thoughts from a informal discussion in the evening on one of the Agile testing days. (it was called PATS)

Yes, there was beer too, and pizza later :-)

What makes a great tester is not possible to define, but you can help people learn and improve and become great testers.
What makes a great tester: Well, skills are not important, those can be learned, but it is very difficult to describe the “great tester”. When you think about it and discuss, you would almost try to describe the “greatest employee” or “the perfect human”. I’ve got more ideas about this, but that would be a different blog post. You could help employees really develop themselves (so this is also not only for testers) to create an environment where people can make mistakes. Or even set a goal for people to fail. Celebrate failures: you have learned something! (at least you would expect the latter).
Another good point is to give people the time (for example 2 or more hours a week ) to do something for themselves instead of expecting them to do that in their own time.

We still got a lot of work to do concerning risks and communication with the business about risks.
I’ve seen it myself, but mostly I get positive reactions from the business when I start to talk with them about risks, but this could be different. “We want 0% risk when we ship this.” We should ask the business for an acceptable risk level, but first I guess we should explain more about it.
Also I see a difference in perception about risks in the testing world. Are risks part of a test report and release advise or should they be used before starting testing or even developing. I would say, discuss those risks before starting developing stuff, maybe it is an idea to discuss product risks together with the effect map of Gojko Adzic. Well, this is one subject I will surely put more thoughts in.

I just liked this slide so much I had to put it in: "Where would you bite first?" (Gojko Adzic)

Anyway
I learned a lot at this great conference (and will do more the coming weeks). I met a lot of testers and (!) developers and discussed testing. At one of the presentations it was asked how many testers there were in the public. About 2/3rd of the people raised their hands. So this was also a bit of a mixed conference. So the ‘other’ group was there too :-), which made it more interesting.

Furthermore it was not a massive conference such as Eurostar, it felt like a small group of people even. (don’t know how many people attended). The ‘market’ as you see with lots of events was small (about 10 companies at the most) and relaxed. Just like the conference itself. I enjoyed it and I think I will be there next year too. Maybe I’ll see you there? Follow the Agile Testing days on Twitter.

Finally a 'thank you' for the organizers of this event
Thank you organizers (Díaz & Hilterscheid) for organizing this great event. It was good to be there. I had a nice talk with one of the organizers (José Díaz) about the conference. But also the Agile Testing Days app that was introduced for Android as well as for Apple devices. It had some flaws, but it worked good enough for me. Well, testers will be the first ones to complain of course :-)

José Diaz introducing the speakers.