My biggest takeaways from AgileTD 2020: The future of testers isn’t in automation or testing

I was lucky enough to speak at AgileTD this year and also attend some of the talks. These are my main takeaways from the conference based on the talks that I was able to make.

My confirmation bias sense is tingling with this but…  

The future of testers is not in automation or testing – it will play a part but not as big as – helping teams build quality-in.  

Most teams see testing as either bug hunting or just another cost centre that needs eliminating. Therefore testers (at all levels) need to get much better at communicating the value of testing.

As testers we need to start shifting our skill set from doing the testing to advocating for testing within teams.

The skills we need to develop will take time to build as it’s not a matter of just attending training but having hands on experience of using and applying the skills.   

Otherwise testers risk becoming irrelevant in teams that begin to form without the need for testers if (or when) the next shift happens.

What is working in our favour is the slow shift to adopt new development ideas such as those expressed in Accelerate. But also teams figuring out how to really collaborate and not just cooperate. Think of the dance of passing tickets around that happens in a lot of development teams.

Which talks should you take the time to watch?

So which of these talk further lead me to believe the above. Let me break it down:

The future of testers is not in automation or testing

That is not to say it will go away, but it will not be the main objective of our roles.

Is not automation: Automation Addiction by Huib Schoots and Paul Holland (Day 1)

• A lot of people’s addiction to automation appears to come from automation tool manufactures marketing (promising the world) and sunk cost fallacy (making it hard for people to stop once they’ve started). I’d also add peoples job spec also asking for automation with no rational as to why they want it
• It is good for some things, generally things we know how they should behave and especially when we can isolate them from the UI.
  • UI’s can behave in unpredictable ways so not always the best place to put automation that needs to be consistent and reliable
• So what do you do?
• Focus on teams and start small: 
  • (Focus on) exploratory testing,
  • (Start small with) a good test strategy that includes what is and is not to be tested
• Automation should be focused and isolated

Is not testing: Let it go by Nicola Sedgwick (Day 3)

• We as testers need to let go of testing and start focusing on how we help teams understand what quality is and how they build it in
• Nicola does this by being a Quality Coach and using Quality Engineers embedded in teams to help them mitigates the risks
• This was a great talk and something lots of others have been advocating.
• I think we still need to better define the Quality Coach and Quality Engineer roles but we have to start somewhere
• I’ve written a little about what testers could do next
• You can also learn a more about Quality Engineer from my TestBash Manchester talk (paywalled)

Also see

• Testing is not the goal! By Rob Meaney (See below for more)
• Beyond the bugs by Rick Tracy (See below for more)

Communicating the value of testing

How to pitch and value testing properly in the age of DevOps by Bjorn Boisschot (Day 1)

• A fairly simple and affected approach to getting the test team behind a testing vision that they can then use to describe what it is that they do.
• Rather than the typical dry approach of traditional testing (test scripts, reports, bugs) which all reinforce the bug hunter viewpoint of testing
• This gets testing focused more towards what the organisation is trying to do (think company mission statement) and focuses the testing vision towards that
• This helps others understand that it more then just bug hunting but about helping make decisions on the quality of the products and how they affect end users
• His approach was to create a testing mission based on the company vision statement. With a focus on the why of testing and not the what or the how (see Simon Sinek: Start with why). From there they created a number of goals that would help them achieve that mission. Then they used the goal, question, metrics technique to make it measurable.
• For some in the org this approach made testing much more accessible and greatly improved their view of it.
  • But for others, well, they still didn’t care 

Beyond the bugs by Rick Tracy (Day 3)

• As senior members of the test team we need to help our testers understand what value they bring to teams. Then give them the tools (verbal and written communication skills) to make their value relatable to other roles. Otherwise they are very likely to be seen as bug hunters and a cost that can be eliminated.  
• Really fascinating talk where he showed how everyone outside of testing views our roles (bug hunters that cost money). He then showed how we need to cover three main arguments for others to see the value we bring. These being conceptually (does it make logical sense to them) practically (how can they/others use it) and monetary (what does it cost and what’s the ROI). 
• He then applied these three arguments to different testing scenarios from doing no testing at all to shifting testing as far left as possible and doing it earlier and earlier in the process. Through this he showed how the initial investment in testing increased but would dramatically decrease the costs later on in the process due to issues being found earlier and therefore easier and cheaper to fix.
• This all reinforced the idea that testers do much more then add costs to projects and finding bugs. Such as 
  • Manually finding issues that would otherwise affect users 
  • Testing earlier on in the process before code is written by testing requirements and designs to prevent issues entering into the systems earlier
  • Raising levels of team understanding in the product, the processes they use and potential issues that is could be introduced 
  • Types of risk that could affect the team and acting as a type of insurance of that risk 
  • Making testing relatable to non testers 
  • Providing sources of information for innovation and improvements within the teams ways of working 
• But all of this doesn’t just happen. You have to invest in your testers (and them in themselves!) for them to be able to do this such as their technical skills, improving their awareness, understanding risk, alignment with the org etc. IMO: If you keep testers ‘dumb’ and just bug hunting then that is all you will get 
• He then linked this investments to potential measures so you can see if your investments was paying off and a way for testers to see improvements. Cycle and lead times where two areas that came up quite often 
• These measures where then linked to business value. Two main ones being faster time to market and improved customer trust in the product. 

The skills we need to develop

These skills are not limited to just these talk but are great examples of what they are

How to keep your agility as a tester by Ard Kramer (Day 1)

• Great talk about how he uses the 4 virtues of stoicism to be a better testers. I actually think this would help a lot of people within development teams so if you’ve not heard of it before I recommend checking it out. 
• This looks like a good resource https://iep.utm.edu/stoiceth/ but this talk focused on just the 4 virtues of wisdom, courage, justice and moderation 

Also see 

• Extreme learning situations as testers (Day 3)
• How to keep testers motivated by Federico Toledo (Day 3)
• Beyond the bugs by Rick Tracy (See above)
• Testing is not the goal! By Rob Meaney (See below)
• Introducing psychological safety in a tribe (See below)
• Growing Quality from Culture in Testing Times by Tom Young (See below)
• Faster Delivery teams? Kill the Test column by Jit Gosai (See below)

Adopt new development ideas

Testing is not the goal! By Rob Meaney (Day 2)

• From  testability > operability > observability and his journey with his learning with these techniques and how teams have be able to make use of them.
• I think one of the really interesting points he made was understanding where your team is in their development life cycle.
  • Are they just starting out or are they an established team and product.
  • Depending on where you on this cycle will affect to what level you will need testability, operability and observability.
  • As the three things are about managing complexity and when you are starting out complexity isn’t the problem, product market fit is. 

Also see

• Faster Delivery teams? Kill the Test column by Jit Gosai (See below)

How to really collaborate and not just cooperate

Growing Quality from Culture in Testing Times by Tom Young (Day 1)

• Great story from Tom Young on how the BBC news mobile team have grown over the years and how focusing on their team culture has been one of the best ways to build quality into their product. All they way through the talk Tom shouted out to how the whole team help deliver their product

Faster Delivery teams? Kill the Test column by Jit Gosai (Day 2)

• See my post on what’s wrong with the test column: https://www.jitgo.uk/in-test-column/
• How to move away: https://www.jitgo.uk/how-to-move-away-from-the-in-test-column
• Creating psychological safety using ToC: infoq.com/news/2020/09/deliver-faster-kill-test-column/ 

Introducing psychological safety in a tribe by Gitte Klitgaard and Morgan Ahlström (Day 3)

• Hearing how other people have tried to address psychological safety in organisation was very interesting. There was a lot in the talk that I recognised from Amy Edmundsons work (Teaming and Fearless organisation). They didn’t use Amy definition of what psychological safety is but from what I’ve seen all the definitions are almost the same. Simply put are people willing to take interpersonal risks within group settings. If so they have psychological safety if not then they are considered lacking it. 
• The things that stood out for me was that all these types of initiatives take time and constant work. They are not things that you run a workshop, take a few questionnaires and you have the safety.
• Also psychological safety is very personal thing so what one person feels is not the same as another in the same team. 
• There is also a lot of misconception around psychological safety in that people feel that in psychologically safe environments will no longer have any conflicts and is all about everyone being comfortable. This is not the case.
  • PS environments are about being able to share your thoughts and ideas without the worry that it could be used against you in some way.
  • The main reason for PS is to establish environments conducive to learning from each other – which is what is needed for the knowledge work that we do 
  • But to learn effectively your need some level of discomfort
  • Too much discomfort and it can tip into fear which causes the flight or flight response  
    • and you’re not learning anything other then self protection 
    • The best way to protect yourself? Don’t say anything that could lead to a situation that causes conflict… 
  • So PS environments are about people being able to work through conflict productively that can lead to new insights and ideas

There was many, many more talks at the conference (perhaps too many) that I wasn’t able to make and thats not including the workshops so it is worth looking through the programme and seeing what stands out for you.

Think I missed a talk that should be in the list above let me know in the comments.

What is it about that particular talk that makes you think it should be included?

What above do you disagree with?