Agile testing days 2012: Escaping the Matrix

Before I go to a conference I always set myself a goal and imagine what the conference will be like. Even though I always encounter nice surprises during a conference, most of the time the conference was more or less what I expected from it. Boy what was I wrong about my expectations for the agile testing days. It exceeded my expectations by far!

The past two years has changed my view on testing quite a bit. In my relatively young career as a tester I felt from the start that there was more to testing than what I have been told and have seen. I was driven by other goals than just ‘finding bugs’ and ‘report on quality status’. I wanted to contribute to the products quality and motivate and align people to do the same. So I started looking for an answer. In a way there is some resemblance in the Matrix themed keynote Markus Gärtner presented. My quest to ‘espace’ from the Matrix begun.

After some time I read Daniel Pink’s book ‘Drive’ which made me aware of a different approach on working. This brilliant, yet simple book set my spark to embrace the values I later also found in the agile approaches on software development.

Now, almost two years after the beginning of my quest, I attended the agile testing days. A thriving conference where people gather to discuss testing in an agile -at least in name- context. What surprised me the most about this conference is the openness and interactivity of the participants and speakers.

Speakers were easy to speak to and were really encouraging to share your own story. It so happened that I found myself doing a usability test quiz with Lisa Crispin and Janet Gregory after Gojko Adzic’s Keynote on reinventing software quality.  Also after I -among others- just simply asked Gojko Adzic about his new book ‘Impact Mapping‘ he instantly organized a ‘bonus’ session on the topic. How cool is that!

Since this was my first multi-day conference where I wasn’t a speaker, I could fully focus on all the talks and activities and so I did! The whole four days were one big information gathering and spreading. During lunch, diner, bar time and even when I tried to get some sleep I was busy with all the topics. Just like Janet Gregory, Peter Walen, Huib Schoots, Sigurdur Birgisson (aka Sigge) and a lot of other people I also tried to keep up with the talks by creating mindmaps. Due to my attention span and battery life of my laptop the results are mixed, but it certainly helped me organize the huge flow of information. It also helped in summarizing the following highlights:

Workshop: Winning big with specification by example – Gojko Adzic

Gojko’s award-winning book Specification by example influenced me the most this year. In the book Gojko shows us how teams cope with the decreasing time to market and rapid changing environments and products. By using specification by example teams are able to deliver high quality software without compromising on the -minimal needed- documentation.

Gojko began the workshop presenting some succes stories and elaborating what specification by example is.

Since I already read the book and know a bit about the topic I decided to make an illustration  while listening to Gojko. I usually draw this illustration when I explain people why we should start with specification by example.
In the first picture -on your right – I show how we are working now with business analysts describing use cases or other type of functional documentation based on requirements, which are often based on examples. After the documents are created, other team members, like developers and testers, create code and test cases based on examples they think of while interpreting the functional documentation.

So if everybody already seems busy with examples why not use this examples as specifications? That’s basically one of the key points in specification by example and what the second picture -on your left- tells. I know this is a simplification, but I really missed this kind of illustration in the specification by example book.

The workshop became interactive soon and me and my German colleagues for the day were really serious on getting something good out of the workshop. The best exercise was about the writing good examples. We reviewed several examples on the criteria:

• shared understanding
• usage for acceptance test
• usage for regression test
• candidate for -living- documentation.

I found this exercise quite useful and simple. It gives participants concrete examples of how writing specification could work and what makes a specification strong or weak. I instantly used this exercise in my own teams to improve writing on specifications.

One of the biggest takeaways from the tutorial for me was to make teams aware of the speed of the pipeline. In my daily job I see that to many teams just don’t take responsibility as a team and still rely on individuals and their tasks, hence ‘Silo’  or ‘phase’ thinking. If you let people see the purpose of collaboratively creating specifications or test automation they are more willing to help.

An other takeaway are 3 adoption methods for specification by example:

1. Begin as an experiment – Begin with returning bugs for instance or a product with little risk.
2. Use a tool as an excuse – With the introduction of a tool you can also adopt the principals and start from there.
3. Shock Therapy – This is more some kind of an approach Matt Heuser also kind of promoted in his Keynote. Try to find a flexible team and/or a team where the processes is already changing, then just begin and seek for success before management intervenes.

My final takeaway was the reminder that teams really need to create executable specs in stead of creating scripts. In my team I’m always promoting separation of the system behavior – the what-  from the actual steps the system or user takes to get to a goal – the how -. The hard part here for us is that we always strive for the most human readable specification, but we don’t want to compromise on maintainability and efficiency in automation. These to are contradicting each other sometimes.

Exploratory testing presentations by Gitte Ottosen and Sigge

Besides learning more about specification by example one of my goals was to learn more about exploratory testing. I experimented a bit with session based testing before which I really liked, but I needed to know more to really get the hang of it.

Gitte Ottosen’s presentation was a very clear experience based story about her explorations in different kind of exploratory testing techniques.
I was as happy as a kid peeking in his brand new unicorn wallpapered room for the first time. This was exactly what I was looking for. Gitte shared pros and cons on every technique. Based on these she concluded that a combination of Session based testing and Microsoft’s -or should I say James Bach’s- ‘General functionality and stability test procedure’ helped here the based. I will definitely try them out soon. But I also can’t wait to do a bug hunt testing session. Or should I say ‘Workshop’….

Sigge uses the term workshop rather than ‘test session’ to get as many people on board. Sigge does exploratory testing with testers, developers and stakeholders from the business. Where Gitte focussed on what techniques there are, Sigge showed us how we actually could facilitate such sessions. He provided examples of reports and -agile- templates. Sigge furthermore gave tips on how to give test sessions a focus and how to move people to exploratory testing. Basically he gave away a whole toolbox of tips. Go check out their presentations and start testing by exploration!

It’s the economy stupid – Lucius Bobikiewicz

Lucius brought us a presentation not about testing. Nor did his presentation offer new revolutionary ideas. Despite this facts I found Lucius’ presentation very useful. In his presentation he taught us how to communicate agile to the business. Simply stating that we need to adopt agile principles and everything will turn to the better might be received by your manager as you are going to the beach and enjoy the sun.

Lucius illustarted how traditional project management fails to deliver value early. From that illustration he created a simple business case showing how you can deliver value early with an agile approach. His presentation continued explaining the benefits of an agile approach on the whole product life cycle. As I said, nothing new here, but they way Lucius demonstrated the math on how to gain revenue and net profit was a really simple approach I can use for a conversation with every manager.

Reinventing Software Quality – Gojko Adzic

If I’d done a survey….No wait…You can tell from the people’s reactions at the conference, on Twitter and blogs that this was probably the most enthusiastic received keynote at this conference. With such good keynotes this is an accomplishment of it’s own.
Gojko rebelled stating we -testers- understood the third quadrant of Brain Marick’s Agile testing Quadrant “completely wrong”.
His point being that we focus on the health of a system. Although health is a key quality of the life of a software product it doesn’t give the software product a purpose to actually life.

To proof his point Gojko plotted Maslov’s hierarchy of need on software quality. The health of a system is a basic need which is depicted on the two lowest level in the hierarchy. For a software product to have purpose however it also needs to be usable, useful and -I’ld say of course- successful.

It is surprising to see how many software products we have in our world that are simply not being successful. At this point you might think who is really living in unicorn land. Is it the product managers who have no clue if a software product will get them business success? Or is it the software tester that tests if a software product will actually gain business success? Well, in my opinion they both are in unicorn land. Gojko absolutely has a point that a software product needs to bring business success. And yes, you need to verify the product does the trick, but I don’t think that testers have to base there testing on success. So who does it then?!
The business does! So there any role for testers here? Absolutely yes! I think the role of a tester is like the role he or she has in test automation.
In test automation a tester can facilitate a developer and tell him what to strive for. As with test automation I think a tester can facilitate his/her product owner by showing what you can do with impact mapping, usability testing, A/B testing, piloting and all other kinds of tests in production. These are the tests that are not based on risk, but are much more based on value. This is quite a cool concept if you think about it. It means that testing does not longer only costs money -in order to save money-. Testing can actually get you money! It’s just a different type of testing. I haven’t completely wrapped my head around this thought, but I’ll get back to it soon.

Biggest lesson

I learned a lot from the presentations I summarized above. However, my biggest lesson is yet to be described. Despite I understood most concepts of the presentations, I always caught myself thinking: “How on earth are we going to adopt all these wonderful concepts into my and my colleagues daily work?” I honestly had a feeling I was in unicorn land sometimes. This gave me a wonderful feeling. So I want to stay there. Or – to put it differently – how do I free al these managers and colleagues from the matrix they life in? Jurgen Apello’s presentation ‘Let’s help Melly‘ and Morpheus (from the Matrix movie) gave me the answer. The following conversation takes place in the movie the Matrix:

Neo: I thought it wasn’t real  -by ‘it’ Neo means the matrix-
Morpheus: Your mind makes it real
Neo: If you’re killed in the matrix, you die here?
Morpheus: The body cannot live without the mind

In a way this conversation has a link with the spiral dynamics theory Jurgen apello presented. Don’t just expect that adopting a method works. In order to see unicorn land is as fake as the matrix one must transform from within and understand where you are coming from and what you are striving for. Only then your efforts to change will not be killed. I envy those who understand this concept and are already there.

With so much good presentations and talks it’s hard not to write about them, but I have to stop somewhere. I do however like to thank:

• Matt Heuser for bringing fun and gaming in to the conference. (I will play the shortcut game soon!)
• Huib Schoots for showing banks can be changed in their approach on testing (and all the bar jokes)
• Scott Barber for all his energy and vision on being agile
• Markus Gärtner for his brilliant Matrix themed presentation on changing the game of testing and become an agile tester.
• Stevan Zivanovic for his tips on agile test skills for testers. Hope to see the ‘Testers agile pocketbook’ will become a nice book.
• Lasse koskela for his calm brought presentation on self coaching
• Ralph Jocham for his very clear presentation on Sprint backlog in ATDD
• Mike Scott for sharing his Fitnesse experience and comparing it to my own experience with Twist. – Expect some exciting news (and a blog post) on Twist soon by the way –
• Lisa Crispin and Janet Gregory for busting testing myths and taking the usability quiz and encouraging me to present on it.
• Pete Walen for encouraging me to blog.
• Tony, Chris and Ruchika of Red gate I had a great time with in- and outside of the conference.
• Anna for all her brilliant tweets. 😉 (Even during the creation of this blog)
• My colleagues Eric and Simone for telling me all the good stuff about the presentations I did not attend.
• …and all the other people how made this conference a great experience.

You can find my AgileTD mindmap here. Beware this is rather raw material. Unfortunately I didn’t take – digital- notes of everything that interested me.

See you all on Twitter and till the next conference.

• Tweet