Last Saturday the first German Agile Testing and Exploratory workshop took place in Hamburg, Germany. As the content owner I asked every participant upfront in an e-mail to prepare a statement on the following three questions:
- What is your position in regard to Agile Testing?
- What is your position on Exploratory Testing?
- What is happening in the field with regard to Agile and Exploratory Testing?
The participants for this first workshop were (in the picture from left to right)
Here are the insights from my notes and memories.
We started the day with a delay. Finding the location is quite not that easy. One hour later than planned we got everyone introduced and got together the agenda for the day. In the introduction round, I heard someone say that he took the ISTQB course. Later he found out that the ISTQB approach to testing was too structured for the chaotic company he worked in. I think this has nothing to do with the degree of chaos in the company, but rather that the lectures of the ISTQB folks have been lying around, dying by not being adapted (and adopted). But maybe it’s just the perception of a tester that has learned testing in 2006 by self-education rather than getting sheep-dipped.
With five participants we had nine topics waiting. Here they are.
We had the questions of what Agile Testing actually is, and what Exploratory Testing is. We had three presentations, Charity Testing from Maik Nogens, I don’t want to be called QA any more from me, as well as Helping traditional trained testers contribute on Agile teams, also by me. In pursuit of a good mix between theory and practical testing, we had a session on testing a pen, dice games, Eusebiu’s hidden pictures game, and a sessions on Session Creator, to compensate for the missing Sven Finsterwalder who wanted to give a talk on it.
After getting the agenda down, we decided on the first topic. That was the question about what Agile testing actually was. Meike facilitated the discussion. She started with a mindmap about what her picture of testing and Agile testing consists of. After that we started to explore the contents of Agile testing. Meike collected many “Bapperlies” from our discussion on a flipchart. After roughly one hour we had come up with quite a large view on Agile Testing.
We wanted to cluster these notes into groups later on, since we felt that we might have additional insights from the other talks and discussions. We were also interested whether or not there is actually a special skill you need as an Agile tester. Among the things mentioned I noted down that the company culture and the mindset shift for an Agile tester. Another thing was the shift from validation to exploring the application whether or not it fits its purpose. However, these are not purely technical skills, but rather soft-skills. I felt a bit uneasy with this result, and was curious what we might find out later.
We continued with a prepared talk, the one from Maik on Charity Testing. Maik spoke about different crafts where people help others. For example as a carpenter you may help your friends, or as an artist you can create something for charity. In my past life I have contributed to a local swimming club for more than 10 years, serving as a trainer, department lead, secretary, helping seasonal preparations in the local outdoor swimming pool. But how can we testers contribute to the community? Maik remembered me about the Helpful Model, No matter how it looks, everyone is trying to be helpful (Quality Software Management Volume 1 – Systems Thinking, page 154).
Maik said that he gave an Indonesian farmer credit a few years back, so that he could get some expensive machines. Since then he got the amount repaid already. It clearly made him proud to help someone else. But ever since he was wondering whether he could actually also give the same favor to his local community.
In early 2011 he found a company which was looking for a student as a software tester as a part time employee. While he was still employed, Maik offered his services to that company with the words: “Hi, I’m a software tester, can I help you?” It was a government project. While they were looking for testers, Maik wanted to learn something. He clearly pointed to the win-win situation for both. He worked besides his job for some hours in the evening with the company. Sometimes he could fit 2-6 hours per week, sometimes it was less. He used Exploratory Testing with Session-based test management for this. When he felt he had more time, he negotiated for more test sessions. If he didn’t, he made his position clear.
One of the great things I heard was how he introduced test sessions and missions to them. Over time they got quite used to his clarifying questions regarding his missions, and they eventually started to prepare test missions for him. Since they used an online bug tracking tool, and he tested a web site, he was able to work from home easily, and provide his feedback on the product over email.
Unfortunately his involvement ended two months later due to personal emergencies and distractions. Though I would like to see more initiatives like this in the software development world. There are quite some, like the The Software Craftsman’s Guide to the World where you can find places where journeymen like Corey Haines are warm-welcomed.
After that we went for lunch break where the discussions continued. After lunch we needed something refreshing. So we went on to actually testing. We headed for the dice game, which I learned from Griffin Jones at this year’s CAST. After the puzzle, we went through a quick debriefing on how they explored the model of my calculations, and what helped them to do so, like note-taking. I hope for Meike and Christian to reveal some of their own insights into this game.
After that we went for another testing mission. Eusebiu’s puzzle on pictures was quite interesting. He gave us the URL of the puzzle, and we had to find bugs in it. I was able to find four bugs in that picutre, but I also found some other bugs. One for the calculation of the coverage value in the final screen, which yielded 318% for me. Seems I covered the application quite well. The second bug happened in my screen recording tool. While testing, I switched to fullscreen mode for my browser. This was no problem for the software, but after switching back to normal, I just recorded a black screen. When checking for updates for that software, I found out, that there were quite some bugfixes available. I didn’t follow up, whether my bug actually was fixed, yet, but I will do so. Anyways, this resulted in a bug magnet tag, that Meike attached to me.
After that we felt we had the energy to go for a definition of Exploratory Testing. We sat down in a brainstorming session. I made clear that I would love to challenge the available definitions of Exploratory Testing around with this exercise. We ended up with a bunch of sticky notes in the end.
We deliberately didn’t try to pick a single definition, but felt that we ended with a quite broad picture of it. We clarified some of the open questions on the board. We noticed that time had slipped by quite quickly. So we decided to follow-up on our morning exercise on a definition of Agile Testing.
First, we searched for additions we would like to make now four hours later. We added some more stickies to the list. Then we went on to cluster the different stickies using mute mapping for ten minutes. After that we tried to identify labels for each of the areas.
We ended up with the clusters culture of the company, value adding skills (as a tester on an Agile team), obstacles for us, requirements (in the software), test automation, and an overview of different roles we are interacting with on an Agile team. The more interesting things we found while discussing this result were among the notion that there are hardly any hard skills an Agile tester will need. It’s more likely that we bring different techniques and knowledge to the table that a developer will not know. Besides that there is a bunch of emphasis on different principles like courage to speak to the developer or customer, feedback, interactions, communication, and collaboration, but these principles can help a tester on whatever project he is working on. At the end of the day we found that the difference between Agile testers and traditional testers seemed a bit artificial.
We spent some time on this exercise. So, the time for the first GATE workshop was over rather quickly. I didn’t get to give one of my talks, and we didn’t get to talk about Session Creator. Mentally I am already preparing for the second workshop. I got some things which I will probably change, hoping for more participants the next time. One thing is to extend the workshop time maybe to two days. Another one might be the use of K-cards for facilitation, but it worked quite fine with five participants. On another note, I hope to get in touch with the DEWT folks to organize a joint-venture at some point. I’ll keep you updated here.
A special thanks goes to Christian for the nice pictures he made. Another thanks goes to it-agile GmbH who contributed the location for this day.