Testing Doesn’t Just Happen at the End

The idea that testing happens at the end of building something is still hugely prevalent. After all, we need to have something to test right? Well yes, we need something but that DOESN’T NEED TO BE A FINISHED PRODUCT.

In the olden days of QA (Quality Assurance) assurance was a check of a finished product that came off of a production line. This is the view of testing that has prevailed into software development, that someone has a big rubber stamp and can APPROVE a finished product. But even in a production like for mechanical engineering more testing happens at the design and component stages (think market research as testing).

To speed up delivery (super useful in Agile environments) we need ways to shorten how long it takes to get feedback and fix things. That’s why we don’t have to just test a finished product at the end but instead can test earlier by testing CODE, DESIGNS AND EVEN IDEAS.

Assumptions and Bad Foundations

Why would we want to test ideas? Well that’s because humans are fallible and have biases which leads to uncertainty in what we might be asking for. People might assume knowledge, or assume something’s a good idea to do… both of these things lead to risk; of building something wrong based on poor knowledge or just building the wrong thing because the idea was bad.

By testing the ideas early, we’ve saved a lot of time in building the wrong thing and can start working on what’s actually needed.

Okay so as well as ideas, what about designs and architectural thinking for software? A key part of testing that usually gets thought of as “being at the end” is non-functional testing (things like performance and security). These are things that need to be DESIGNED FOR AND BAKED INTO YOUR CODE AND SOFTWARE it’s really hard / impossible to retrofit them in after something’s been fully built. If we don’t test as we design and build for these things then we’ll end up with flakey foundations for our product. In fact, by testing them at the end of building a product and only finding issues at the end you have to ask yourself “AM I HAPPY TO HAVE TO REBUILD THIS WHOLE THING AGAIN?”

So what can I do?

TESTERS

Keep fighting the good fight, socialise and educate your team mates on how testing earlier can help your teams. Run Triforce and risk analysis sessions to call out issues as early as possible and get testing earlier, headlessly via APIs if you can.

PRODUCT OWNERS / MANAGERS

Understand how quality can be baked in early and get testers into your teams as early as possible to help you; testers are valuable from inception of a project after all. Make sure time is given to testing throughout the software delivery lifecycle and set up sessions like Triforce to help engage with testers and give them a seat at the table.

DEVELOPERS

Make things testable as early as possible and engage with risk reviews or quality conversations that testers may want to have. Remember that baking a fix in early is better than having to raise a defect and fix it later. Implement tooling to benchmark for non-functional elements like performance and security oh and WRITE UNIT TESTS AS YOU GO.

RECRUITERS

Understand that shifting testing earlier is a specific skillset in itself and may require exploratory testing. Evangelise to organisations (especially start ups) how this type of testing is important in environments of fast paced development and uncertainty. Work with organisations to understand the problem space of testing and how a tester could help them to shift left / right and create a job spec accordingly.