Don’t wait to test – Go explore!

The biggest shift in mindset between traditional testing and modern Agile testing is the drive to investigate, rather than waiting to be told to test. In the traditional model testing came last and there was a lot of information to tell us what needed testing.

This type of development trains testers to wait to be told what needs testing. Which is fine in organisations and structures that support that style of development and testing. But what about when we’re going faster? What about where there’s uncertainty about what we’re building? What about Agile?

The difference with Agile development is that testing is pushed throughout the lifecycle of development. Testing is there to Inform development rather than confirm development.

This shifts the idea of what testing is and has to be. We need to move from the idea that we check what’s been made meets spec to becoming explorers; those who hunt for information about what good looks like.

This is a big mindset shift for testers who come from that traditional testing mentality. You get thrown at a team and there’s a whole bunch of uncertainty and nobody’s saying what to test. We have to develop ways of thinking and testing that supports how these Agile teams work… so here’s my tip: Don’t wait to test.

Don’t wait to be told

This means getting stuck into your team and working out what needs testing yourself by setting your own scope. Investigate the risks around a piece of software or a project and working out what could be investigated to find out if something is good.

There might not be requirements or Acceptance Criteria (and the ACs might not be enough) so we need to investigate and push quality narratives. If we wait to be told what to test and how to test that thing it’ll be too late to influence it.

• Listen in stand ups to understand what’s being worked on.
• Constantly review for risks of what could go wrong to work out what needs testing.
• Be technical and engage with the engineering side of things to understand what needs testing.
• Education is key to be able to understand things and know what risks could be there. Learn about what makes products good (think about the non-functional stuff too).
• Get used to exploring to find (and then share) information.

Be proactive; nobody is going to tell you off to finding out something and sharing it. But make sure to be pragmatic and work within the scope of your project to avoid creating unnecessary noise for people.

Don’t wait until the end

This means learning to shorten feedback looks by testing early. Learn to speak up in meetings or to raise risks as we create tickets through Triforce. We don’t have to wait until there’s a finished product to test and not all testing happens through the UI, think about the risks we can test for via APIs or by pairing with a developer to test the code.

• Test everything, even ideas, designs and architecture by raising risks through critical analysis.
• We can test non-functional elements before a finished product exists with different tools and techniques.
• Learn how to shift testing left by getting closer to the code (maybe just start by testing APIs).
• Ask your team “what does good look like” to get ideas about quality early.
• If you have an idea for something to test, jump on it. Finding the information sooner is better than later!

Don’t assume there’ll be a testing phase or time to cover testing; we have to make time for testing by getting stuck in as soon as we can to understand and share quality information.

Don’t wait to be asked

As a tester you are the quality expert on the team, so you have to champion it. This means getting used to pushing ideas and information to your team (rather than waiting for a pull). Create quality narratives from the testing you do and use this to push information to the team as soon as possible.

People don’t know what they don’t know (or don’t know about risks) so if we wait for a pull on things that aren’t being thought of, we’ll be waiting for a while. As the experts in quality we need to be that trusted advisor and give information in a timely manner to help make decisions on whether something is good.

• Be pragmatic, know what to share and when. if you keep telling people everything (complex edge cases or out of scope stuff) you’ll loose credibility.
• Practice being engaging when you speak to help sell your narrative, add the “why do I care” to any issues or risks (what’s the business need for the fix?)
• Find the right time to share information, in stand ups, debriefs or specific meetings to talk about issues.

A shift of mindset

As I’ve mentioned before, this different way of working is a change from what people are used to. It lacks the comfort of being told what’s right and shifts ownership way more onto you as a tester for owning and championing quality. It’s gonna seem like a lot of work and is daunting to get started, but there are ways to move towards this different mindset.

• Take baby steps. Just do one thing at a time, maybe start with raising risks on a piece of work before it’s developed.
• Practice being more informed. Be more present and start listening in more to other people’s updates, try to understand what they mean for the quality of (and risks on) the project.
• Work with others. Talk to your team about risks and the things you could do to find out about quality, they can help you see what’d be good.
• Try something. If you learn by doing, try exploring something to practice working with uncertainty or try a new tool to get information about the non-functional elements of the system.
• Practice sharing information. Run a debrief to share information you’ve found and practice pushing information up to people.

Don’t go slow by waiting to be told when and what to test. Go faster by exploring and sharing information.