Contact us

Drop us your deets and we'll be in touch as soon as we can.
Scroll down.

Quality assurance for digital products

We discuss quality assurance (QA),where it fits into a business, how QA testers improve things, and what happens if you don’t have any QA...

Erik Mclean, Unsplash

Quality assurance (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 and 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 plans 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:

  • Integration testing to check that the new features integrate with the existing system and any 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.
  • Exploratory testing to think outside the box to find ‘edge cases’ that may not be part of the usual user flow.
  • Regression testing to check areas of the system that have already been built and tested but may be impacted by the introduction of new functionality.

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 even has a role to play 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…

More in this series

We love a good chat

Honestly. Sometimes you can't shut us up. Something you want to talk to us about? Excellent stuff.