Why you need testers in a new team

We usually think of testers coming in at the end and checking things were built right. This can be via manual or automated tests, but the prevailing view is still I need a thing to be built so I can test it.

Testing is much more than that, a lot of testing can happen before we’ve built something and we need championing to ensure we bake quality in from the start. This type of testing won’t be the traditional “I asked for X… check it did X… Pass” testing and so teams and hiring managers need to understand what this testing looks like.

Testing early in development

There’s so much more to testing than checking a finished product meets specifications. Just like the old saying “prevention is better than cure” a lot of testing can be done earlier to prevent bugs from ever happening (speeding up your team to delivery).

Refining the ask – When we’re early in building a product there might be a lot of uncertainty about what we want, this leads to assumptions which could lead to things not as we want. Testing can ask questions to help refine out what you’re asking for.

The Chair Example

This is something that’s used a lot in testing. Imagine that a product owner has asked for a chair, well we can test that idea by asking questions and teasing out knowledge.

How many people want to be able to sit down at once?
How long will they be sitting for?
Is this for social interaction, work, eating?
Do they actually want to be able to lie down too?

Instead of a chair, do they actually want a sofa bed?

Raising risks from designs – Like with refining the ask, uncertainty can lead to assumptions which leads to defects, by reviewing designs and architecture we can tease out potential risks and issues early. Raising these issues early means that the team can build software with these issues in mind and avoid defects happening.

Exploring the build – Testing can happen before a product is completed, you can look at services and components and explore the code to uncover potential issues earlier. This can include working with developers on where to add closer to the code tests or to run and debug code with them. This can also be working as a liaison between development and product, demoing and explaining what’s been built to help them know if it’s what’s wanted.

These early types of testing need a certain type of tester, one with the skills to explore and share information without being told what’s needed. They need to be a strong communicator and collaborate who can work across the team.

This is why an early hire should ideally be someone senior, who can push what testing is needed rather than waiting to be told what to do.

This type of exploratory testing is predominantly manual and not automated as it’s not confirming what we know and usually doesn’t need repeating. In fact for early days on a project / company we might find that the code base is changing too often for automation anyway.

Regression pack / Deployment checks – these are the traditional tests that go “I asked for X… check it did X… Pass”. These are important to ensure that what we want to stay the same, stays the same even when we deploy the code or make changes to it. These are the tests that we’d automate and would usually wait to have something to test against before starting.

But ideally we should keep on top of these tests and get writing them as we build the code, especially if the code will change a lot / we’re working fast paced, so that we have safety that desired behaviour doesn’t change.

Baking quality in earlier

When we’re starting with development and architectural designs, some of the decisions we make can have a massive impact on the product we build for years to come. It’s not always likely of feasible that we’ll have the time or desire to rebuild the core of our software much later on, which means these initial parts of the system need to be robust and make for a good foundation.

Non functional considerations like performance and security (and even usability) need to be designed and architected in from the start. They’re not something that you can just bolt on at the end, which means we need to champion for them early. Testing should be benchmarking what we build for these considerations from the start so that we know that they are fit to be the foundations we build upon.

Testers can also help with really helping to define what “good enough now” means for a product in the early says and help to explain what your path may be to “good enough later”. It may be that the team just hasn’t considered what they’re missing and haven’t thought to ask about certain behaviours or considerations (we don’t know what we don’t know).

Like before, this requires a certain type of tester who can think about wider risks and champion solutions for them. In a lot of cases people need to be shown a problem in order to understand it, which means the tester having to explore for and benchmark against areas of quality.

Where teams don’t know what they don’t know, the tester you bring in needs to be able to actively bring in this information and champion it. Which means looking for a generalist that can speak to (and test around) a large number of topics.

For hiring managers and recruiters

As a testing community we need to help organisations understand how there’s so much more to testing than the old school “I asked for X… check it did X… Pass” checks. Teams need to understand the real value that testers can bring into teams earlier and know to ask for the right type of testing!

When we talk to recruiters looking for a first tester into an organisation help them to understand what testing is needed in the problem space. That this testing needs to be championing quality, working with uncertainty, active (not reactive) and an exploratory generalist. Don’t be afraid to challenge the view that new teams just need automation or scripted testing (this might be the only testing the hiring manager knows about).

Why do you need testing earlier in teams?

because early stages of development is when there’s the most uncertainty, assumptions and the risk of things going wrong.

we need testing to dispel the uncertainty and prevent bugs from happening early!

More Blogs