Teaching testing to developers

07/08/2017 by Christian Kram | Filed in testing | Comments Off on Teaching testing to developers

The challenge

Teach a team that has been heavily reliant on a single tester the basics of agile testing in half a day.

 

Since I am not the first one to do so, I gathered some sources that I wanted to get some inspiration from and incorporate ideas from into the workshop I was going to give. The starting point was the holy trinity of agile/exploratory testing books:

Now these provide some great insight about what to do, but I didn’t want just to rely on the pedagogy classes I had at university on how to teach, so I added one more book to the mix:

And whenever inspiration for testing is needed, TestSphere is an awesome source. And to complete stimulus satiation I decided to incorporate some ideas of the splendid four hour tester project.

 

Now that would be enough to set up a whole week of teaching testing. My main focus was to convey the idea that testing is an activity and not a role. And that it is a whole team effort, not just a single person’s duty. So I decided to make that the main focus of the first half of the session. It became pretty obvious to me quickly that the second half would have to be about general testing methods and ideas, not so much about the tooling landscape we have and certainly not about automation guidelines. Furthermore it was important to me to get people actively involved and that as a team, by that emphasizing the whole team idea by getting the whole team on their feet from time to time.

For the first half the Coach’s guide to agile testing was a splendid resource of ideas, which heavily influenced my general setup and some of the activities, throw in some Agile Testing and here you are. The second half was more evenly distributed as I incorporated some things from the four hour tester and some things from Explore It!

All in all my syllabus for the workshop looked like this:

  1. Introduction
  2. Agile Testing
  3. Whole Team Apporach
  4. Test quadrants
  5. modelling
  6. Automation
  7. Methods and heuristics

 

I have taught and tweaked this workshop several times by now, but the general outline has stayed the same so far. So here is a short summary of the parts and the sources this is based on.

Introduction

 


I started out with the Jenga Testing game to show different approaches in testing and to foster collaboration. Some people are hesitant at first, especially if they are not used to gamification elements, but that’s alright. In my experience this bodes very well and gets people involved quickly and makes for a nice discussion. For further information see Coach’s guide to agile testing, chapter 2.

Agile Testing

This follows the Coach’s guide to agile testing structures as it is based on chapter 3 of that book. The idea is to promote an agile testing mindset and let people realize that agile is not just short iterations and stand-ups, but there is more to it, neatly summed up in the agile testing manifesto:

 

This is usually done more in an ex-cathedra teaching style, albeit loosened up with some nice exercises provided in the book.

Whole Team Approach

Strictly speaking is this a topic already raised in the part before, but since it was important in the context of developers relying too much on a tester I decided to give this some more emphasis. People seem to be reluctant, but mentioning the bus factor (or if you are not that morbid, call it the “someone wins the lottery and leaves the company”-factor) and that they are seen and judged together as a team usually triggers some nice discussions (…no, that story is not done until it’s ship, so what good does it do for the customer if it sticks in the test column?). In addition I introduce the broken comb idea. If you pile up all combs of a team, you should still be able to comb. If the long tooth of a specialists comb breaks away, the shorter teeth of the other combs should make up for that.  Chapter 21 of Agile Testing is a nice reading in this context.

Test quadrants

This is a slight variation of what is proposed in chapter 4 of the Coach’s guide to agile testing. I usually start out with letting people write down all kinds of tests on stickies before I introduce the empty quadrants. Then people are to put their stickies where they think they belong in the quadrants. Chances are high that people have the same kind of test on a sticky but don’t always agree where to put it, so that leads to some nice discussion. In the end I usually show how the quadrants are arranged in chapter 8 of More Agile Testing.

Modelling

The description of this is very easy. I pretty much took the Modeling task of the four-hour tester introducing the FCC CUTS VIDS heuristic. The only adaption is to do it in groups. This is actually something I get a lot of positive feedback, especially from coders, as it helps them to shift in their thinking.

Automation

I was reluctant to include this part actually, but I wanted to stress the whole team approach here, so I somewhat reduced chapter 6 of Coach’s guide to agile testing to the max stressing the collaboration and talk to each other part.

Methods and heuristics

After shortly introducing heuristics in general and FCC CUTS VIDS and WASCID in particular, I usually introduce equivalence partitioning and coverages in a control flow diagram (the latter not for the sake of coverage number but as a way to test workflows which we see regularly). This is usually wrapped up by deciding for a heuristic or method in the group and apply it to what has been found out in the monitoring part. So it’s inspired by the test design part of the four hour tester, but puts some variation to it. And of course this part is heavily inspired by Explore It!

 

The feedback I am getting is usually very positive and things have started to trickle into the daily habits of teams. The content seems to be a lot for an introduction and for 3-4 hours, but it usually plays out nicely. Of course half a day is not enough to make someone a tester, but it is a first step to get people on track and provide them with an idea what testing is about. What would you do differently?