Selling Testing into a Project

Half of the battle in testing isn’t how we test, it’s selling the idea that we should test in the first place. As testers we need to be able to advocate for quality and why we need to be testing in projects.

I’ve worked in organisations that are new to Agile, going through a transformation, or haven’t worked with dedicated testers before. In both of these types of organisation there’s learning that needs to be done about what testing is and why we need to do it; not because people always disagree but because they just don’t know. Being able to sell the idea of testing means bringing people on that journey, so that they know what testing means for them and what’s in it for them too.

Why we need functional testing

What is it?

This is your testing that tells you that you’re building the right thing. From ideas through code to workflows, functional testing is our way of using critical analysis and review to say “okay this does the thing I want it to do”. Functional testing isn’t just limited to scripted testing (Does it do X? Yes it does X – tick) it also can be covered by exploratory testing to find out more about it.

Why do I want it?

• To build the right thing – we could build things wrong, we need a way to stop that and make sure that we’re on the right track.
• To make the product saleable – we could build something that nobody wants or misses the mark with customers, we need a way to check for that.
• To reduce costs – doing the wrong thing means having to do it again taking time and money, we need a way to stop that happening early.
• To document the project – what happens if how things work is just in someone’s head, we need a way to document behaviour so we can easily share it.

Why we need Scripted testing / automation

What is it?

This is your checking that tells you that you’ve met your requirements (or acceptance criteria). We use scripted tests (in manual or automated fashion) to ask “does this thing do X? Yes it does X!). This testing is scripted because we can write a script of steps with assertions to pass or fail against.

This testing isn’t limited to testing behaviour or workflows, we can test code and services through Unit and Integration tests.

Why do I want it?

• To know things haven’t broken – scripted tests can be used to tell us that something does the thing we expect, we can use them to confirm behaviour over and over again and check for regressions.
• To have faster / cheaper tests – scripted tests can be close to the code (like unit tests) so are smaller and cheaper to run, these tests are faster to run so don’t hole up releases.
• To have auditable results – scripted tests set up a conformation of pass / fail with a result that can be used to prove the outcomes of testing (really good in a regulated environment).
• To have test metrics – some organisations like to see progress of testing through numbers, being able to report on pass / fail numbers is a simple way to provide test reporting or metrics to management.

Why we need exploratory testing

What is it?

This is your testing to find out more about the product, by running investigations related to risks we can find out more about quality and share it back to the team. We can explore and analyse throughout the technical and development stack as well as throughout the lifecycle in order to test anything and everything.

Exploratory testing isn’t just adhoc clicking about, we can use risk analysis to structure our ideas, set out a scope of testing and prioritise it in order to find the information that’s useful to the team. Likewise, exploratory testing isn’t limited to business logic or workflows; we can test architecture, code, services and the technical aspects of development too.

I’ve written more about exploratory testing here and how it’s not adhoc testing here.

Why do I want it?

• To reduce risk – what could go wrong in a product isn’t limited to the ACs as we might have forgotten something (we can’t write down everything), we need a way to see if what we’ve built fails or if edge cases occur.
• To start testing earlier – we need a way to ensure we reduce rework and build the right thing up front, by testing ideas, designs and acceptance criteria we can prevent bugs from being coded.
• To test anything – some things we can’t script for or automate, we need a way to test the “untestable” including code that can’t handle unit tests, wireframes, ideas and human factors.
• To report on quality – metrics can tell you how far testing is progressing but we need a way to tell us how good something really is, exploratory testing yields information about how things really work that we can share via quality narratives.
• To work with your team – we need a way to integrate testers into all areas of the team including design, product ownership and coding. Exploratory testing allows us to work with and pair meaningfully with team members to build relationships and become trusted advisors.
• To share information – who knows how things work and can onboard a new team member or give a client demo? Somebody who has learned about the system, somebody who’s made test notes about how things work and can share them… someone who has exploratory tested!

Why we need non functional testing

What is it?

This is your testing for the things around functionality, telling you how that functionality performs in different ways.

• Security – Can only the right people interact with it?
• Performance – Does it work well when lots of people interact with it?
• Usability – Can people interact with it in a good way?
• Accessibility – Can everybody interact with it in a good way?
• Observability – Can we get information about / see how it’s working or how it failed?
• Compatibility – Can people use it in different ways and with different tools?

As with functional testing, we can use different approached to perform this type of testing both scripted and exploratory (or a mix of both for completeness).

Why do I want it?

• To see how good things really are – we need to be able to see how the product will work in the real world and that it still does what we want it to when in the hands of users.
• To avoid rework – we need early insights into potential problems (like memory leaks or data leaks) so we can build fixes for this up front, rather than having to rebuild later.
• It’s the right thing – making something that works for everyone and is good to use just feels good to do as an engineer, we need a way to show that we’re doing right by our customers and building something that’s truly awesome.
• To help us later on – we’ll have to support our product in the wild once it’s deployed so we’ll need logs and monitoring to help us diagnose issues. Plus we won’t want to be called out to refactor everything in order to fix memory leaks or compatibility issues, so let’s bake that in now.

How can we sell?

Testing can be a hard sell, sometimes education (like the points above) isn’t enough. So we can look to models for motivating change (like WebAIM’s hierarchy for motivating accessibility change).

Bad motivators:

• Guilt – Telling people they’ve failed or saying people don’t care about quality if they say they don’t add testing.
• Punishment – Talking about legal or regulatory pushback / fines if we don’t test or have evidence of our testing.

Medium motivators:

• Requiring – Adding requirements for testing or definitions of done that say testing will be conducted to say something is finished.
• Rewarding – Talking about the saleability of a higher quality product and the profits that’ll come from that.

Good motivators:

• Enlightening – Educating people on what testing can do for them and all the risks we have and can overcome through testing.
• Inspiring – Showing how people’s lives and work can be better through having a quality champion to improve their work. We can also show examples os successful testing within other teams and the wins they’ve had through testing.

Show your teams that testing is important by making it worth their while. Sell them on the benefits.