Mindset or methodology? Software Testing Clinic – Session 7: Agile Testing

July, 8th 2016Simon Tomes

The stakeholder can only speak to the BA who can only speak to the developer who probably won't speak to the tester.

Time's up! Did you do any testing?

This was Waterfall in its full glory, recreated during Session 7 of the Software Testing Clinic. I couldn't get enough of how awkward it felt with a team that wasn't allowed to collaborate.

It felt strange to relive this feeling. I endured copious flashbacks to my work life of 2003!

Mark Winteringham and Dan Ashby ran an excellent session. Attendees learnt about Waterfall and Agile and their relationship to testing.

I'll share my thoughts about Agile Testing and also some ideas that might help you reflect on your current approach.

Many ways to look at it

There are many ways to interpret Agile and I sensed this during the session. I have a hunch this comes from good and bad experiences. It was sometimes referred to as Agile process, Agile method and Agile approach.

Lisa Crispin and Janet Gregory share their thoughts in their Agile Testing book. The Agile Testing Quadrant describes the types of testing that exist in an Agile context.

The Agile manifesto is a set of principles – or way of being – to help those who want to practice Agile Testing.

Agile is a mindset and not a methodology. Scrum, Kanban and Waterfall are methodologies.

Perhaps consider Agile Testing as a mindset, with tools and methodologies that support testing.

Collaborate and experiment

Dan and Mark emphasised the importance of collaboration. They urged everyone to unlearn their traditional view of testing. With Agile Testing, testing is not an activity at the end of a development cycle.

It challenges you to explore ways to gather faster feedback. It asks you to question silos and to create a more harmonious team approach to developing a product.

Imagine for a moment you replaced "testing" with "experimentation". Agile and experimentation go hand-in-hand. The principles of the Agile manifesto have got your back!

Agile Testing with Heuristics and Oracles help you discover what your product actually does instead of what it was intended to do.

Here are three ideas that might help you and your team think about Agile Testing:

1. Start with the why

It's useful for a team to step back and work out what they believe in. Do this before working out what principles and methods you want to experiment with.

Take a moment to step away and ask: "What do we believe in as a team?".

Start with the why. Then collaborate on how you'll operate as a team. What you do next with Agile Testing will become super clear.

This might sound difficult if your development team is 200 people strong and claims to "do Agile". If there's a push for standardisation take this as an opportunity to try something different. It worked for Steve and his band of pirates.

Seek opportunity to learn from other teams, hoover up learnings and share them with your own team. Use that information to focus on what you and your immediate team believe in.

2. Rewire teams like microservices

Perhaps your team embraces Agile Testing. How do you ensure others appreciate what your team believes in and how you choose to operate? Should you spend time sharing your view on testing? Or should you spend time delivering value to your customers?

Maybe there's an opportunity to seek inspiration from microservices — in particular smart endpoints and decentralised control.

Smart endpoints help applications decouple themselves from each other.

Imagine a team inspired by different schools of testing. Maybe they want to try a combo of Agile and Context-driven. Clear endpoints allow other teams to connect regardless of testing approach. Other teams don't need to know the ins-and-outs of the team they are communicating with.

Let's decouple from another team's mindset, approach or process – even if they happen to be the same!

If a team changes how they do things then the opportunity to impact surrounding teams is low. This creates an environment where experimentation and failure is welcome.

Decentralised control partitions a system. It allows for a multitude of technology options. It's the antithesis of defined standards. Apply decentralised control to teams and autonomy amplifies motivation.

It's a subtle shift. Perhaps teams will spend more time focusing on their customers. They'll be less time and no need to worry about other teams.

3. Run daily testing retrospectives

There are a plethora of retrospective techniques. A team practicing Agile Testing will likely get together every two weeks. They reflect on everything about the sprint. Sometimes testing doesn't get the voice it deserves.

Try a daily retrospective with the scope set to just testing.

Invite your team to capture thoughts throughout the day. Or set aside a 5-minute time box.

Share those thoughts at the end of the day in a Slack channel, team chat room or wiki. Use them as a catalyst to improve collaboration.

A future for Collaborative Testing

At the core of Agile Testing is collaboration. A more meaningful name might be Collaborative Testing.

Perhaps we call it just that?

Over to you

Want to join the next Software Testing Clinic? Head over to the meetup and sign up!

I'd love to hear your views. What thoughts do you have about Agile Testing? What good and not-so-good experiences have you had?