Full Time Scrum Master experiment part 3 – Who’s doing the testing?

One of the biggest questions about this experiment has been ‘who’s doing the testing?’ I, as a full time tester, quit that to be the scrum master, right? And we only had the one tester on our squad. I don’t recommend dropping your tester in favour of a scrum master, a tester is a vital part of the team and they have experience, training and knowledge that you can’t just spread over the team. In this case, it just happened to be a tester who wanted to try out being a scrum master, and after the experiment we’re hoping to have a full time tester again to ensure testing is valued, executed to a high quality and to write and maintain automation.

The quality and speed of our testing wasn’t going to suffer over the experiment, this was a mission I gave myself. Since the testing would be spread between our designer and our developers it was up to me to ensure they knew what they were doing.

I ran a couple of ‘test 101’ sessions with the squad. I covered basics which would get them testing quickly:

Context driven testing
Risk estimation
Basics of how to write a test plan
Happy path testing
Negative testing
Regression
Keeping scope small ( linked to CDT)
Recording what you’ve done
Deploys

I ran the sessions informally, just two people and me. We had some paper to draw things on, such as happy path flow charts or mind maps. I brought my laptop to show previous test plans to refer to, or show off our tools and processes. It was interactive, in all sessions there were lots of questions and answers. Often the questions would bring up an opportunity for insight into another facet of testing I hadn’t considered. We covered whatever came up, and kept it under an hour.

Here are the benefits of minimal, up-front coaching:

Fast start, can pick up test cases right away
They can find gaps themselves
They come to me with random questions as they come up
New learning as it’s relevant
You learn better from doing
Less pressure to be perfect right away

When cases came up to be tested, I paired with whoever was doing the testing. Letting them ‘drive’ the mouse and the computer, and offering tips as they went through it. I buddied people through deploys. The highlight was buddying a developer leading a group deploy and three other members of the team were watching the process. It was great for increasing interaction and teamwork! The whole team got involved in deploying a change, it made it quite exciting.

The team dove into testing with me reviewing their test plans and giving advice. I paired up with them when they needed it, made myself available to answer questions and share blog posts and information as it came up.

We ran into some issues initially:

Access to various aspects of the database and test tools was restricted by the business. It wasn’t too much of a problem for our developers but our designer was locked out of some of the processes. We had to raise issues with our IT helpdesk and then wait for the request to get to the top of the queue.

Our designer was excited to learn how to test and also didn’t happen to have too much else on, so she dived into it. There was a temptation from the developers then to keep on developing and give the testing to the designer. This was the opposite of what I wanted, because it took our designer away from her design work and it put a lot of pressure on her.

We got around this by reminding everyone to test things in daily stand up, and by introducing a Work In Progress limit to our ‘doing’ column. That way if someone wanted to start something new into the sprint, they had to first test something that was already developed and ready for test.

As a follow up to the test 101 sessions I’d run, I assigned ‘homework’. I pulled stories from our backlog which had good acceptance criteria and gave them to people to write test plans for. They had no time pressure because these were stories which weren’t immediately going to be brought into the sprints. I encouraged them to team up to write the test plans, and to ask any questions they had. Then when they were happy with them, they flicked them back to me to ‘mark’. It was a lot of fun!

A few weeks later I ran a test 102 session with two of the developers. We played the dice game, talked a little about oracles and heuristics, exploratory and session based testing and a little about monkey testing.

There are ongoing benefits to the team picking up the testing and learning about the processes and challenges though: