Erik Mclean, Unsplash
Welcome to the Tech Digest – our regular wrap up of the issues, trends and themes affecting engineering, technology and digital product development. This issue, we’re discussing quality assurance (QA), looking at where it fits into a business, how QA testers improve things, and what happens if you don’t have any QA.
QA is a vital part of the product development process and strongly contributes to a company’s ability to deliver well-designed, robust digital products.
QAs and software testers are sometimes misunderstood as being blockers when trying to get projects live, but nothing could be further from the truth. QA testers are a key defensive component in a product team, working alongside project snd product managers to implement the vision whilst also protecting the team from hidden bugs that could come back to bite them down the line.
What is testing?
So what kind of software testing do QA teams do?
Our main aim is to test that the quality of the product meets the business requirements. If we find something that doesn’t meet those requirements, we highlight it to the product team by ‘raising a defect’ so it can be logged and scheduled to be fixed.
A defect isn’t just saying, ‘Oh here’s a bug…’. It’s a lot more detailed than that. It should include:
- A link back to the requirement it relates to, so that the development team can see how the feature was meant to work.
- Evidence of what the bug looks like, whether that’s a screenshot or video.
- Steps that the development team can take to replicate the defect – if the developer trying to fix the bug can’t replicate it, then they have no way of checking to see if they’ve fixed it.
Any defect raised is great for traceability, allowing us to timestamp when the defects occurred and when they are seen and fixed by the team.
The stages of QA
A common mistake product teams make is only bringing QA in to test the project after it’s been built.
QA needs to be involved in the project right from the very beginning, when the requirements are first being defined, as they test against those requirements from the user’s perspective. By getting involved early, the QA team can start writing test strategies and test cases for how they’ll go about conducting software testing once product components and features start to be delivered.
Once the project is underway, the QA team can start testing. This will include multiple types of tests to cover lots of different areas, such as:
- Unit testing to check that individual parts of the product work as expected and the code is correct.
- Integration testing to check that the new features integrate with the existing system and external software.
- System testing to test each user story as a separate entity, without worrying about how they connect to each other.
- User acceptance testing (UAT) to test business scenarios
- End to end testing where everything is put together into a ‘happy path’ scenario and tested as a whole.
QA wraps up the project by generating test reports about what defects were raised, and they backlog everything so that the team has a traceable history of issues. This helps to narrow down where problems appear when a new version of the product is created.
QA is even there after the project is finished! They help the team with any future defects and log them for the development team to resolve.
What if there’s little to no QA?
But what if you have so much faith in your development team and project managers that you think QA isn’t necessary?
Well, you’re wrong… Sorry pal 🤷🏻♀️
Without a dedicated QA team, pressure is put onto developers to check their own work and this never leads to anything good. And if that issn’t enough, the project managers take a hit too. They not only have to manage the project as a whole, but now they have to help to test the nitty gritty details of every feature of the product. Sometimes this can even lead to an ‘us vs them’ friction between developers and managers – not good for team morale or productivity!
Developers and managers might do their best, but bugs which would have been easily discovered through a robust QA process will inevitably be missed. Later to be found by the key stakeholders or end users. And almost always at the worst possible time.
The moral of the story? Be nice to your QAs because they might be the only thing standing between you and catastrophe…
Like what you see? Sign up to get the next issue straight to your inbox.
Like what you see? We’ve got more where that came from.
Newsletter sign up
Hot off the press
Want to be updated when we've got new stuff to talk about? Get a regular snapshot of what's happening at 383, straight to your inbox, once a month.