What can Quality Assurance do for you?

When undertaking a new development project, it can be difficult to balance resources, cost, and timescales.

Development is vital, after all, the product can’t be built without it, but what about Quality Assurance? Sometimes that is considered optional.

Here we take a closer look at how our QA team operates and present some arguments in favour of not only not scrimping on QA, but how a robust approach can keep costs down in the long run and be a shorter path to a complete product.

Why can’t developers test as they go?

A common knee-jerk reaction to trying to get the best of both worlds – having some quality assurance take place while economising on time and resources – is to have your development team do the testing too.

But being a developer is a full-time occupation (and so is being a QA engineer!) which means something inevitably has to be compromised. On top of that, when creating any content, it’s possible to get “tunnel vision” and not spot something that a fresh pair of eyes could catch.

Experience means a lot too. The greatest strength of a developers lies in building functionality, where a QA engineer makes it their business to think about testing efficiently, and approaching products as user might.

Why test at all? Wouldn’t it be quicker, cheaper, or easier not to?

In 1723 the phrase “A stitch in time saves nine” was coined and three-hundred years later, it’s still relevant!

This Project Triangle shows Cost, Quality and Time at its three vertices:

Your projects’ priorities can be balanced anywhere in the area of this triangle, with an equal balance of all three in the centre. As you start to value one thing above the others, a sacrifice has to be made. Reducing or removing proper testing of your product will save you time and money in the short term, but at a cost to quality.

“In the short term?”, we hear you ask?

With little or no product testing prior to a release, you risk:

• Releasing a buggy live build that your users’ access. This can be catastrophic, resulting in lost confident and potentially lost users as they start to look for a more reliable option. Once lost, it’s very difficult to win that trust back.
• You’ll then spend more time and resources in addressing these issues.
• You may need to draft in your developers to test instead. Developers tend to prefer building new functionality and won’t be able to do that while they’re ‘stuck’ testing.

There’s a lot to be said for thoroughly testing before a release, even if that leads to initial delays and requires more resources in the short-term.

What does QA bring to the development process, especially if introduced before coding has begun?

Quality Assurance solves problems.

That might mean literal issues in functionality, compatibility, or ensuring users with disabilities can use the product as intended. Above all it means thinking of the product as an end user would and ensuring their experience is a positive one.

We believe in a shift-left approach (more on that in the next section) – introducing QA before coding has even begun – in order to review requirements and designs, make suggestions and champion the user from the start. A capable QA engineer will be able to anticipate bugs and know what kind of issues a user might run into. The earlier these things can be anticipated, the quicker and less costly it becomes to fix them, possibly even before they have been built!

An early start will allow QA to define a proper testing strategy: what, where, when and how testing should take place as well as selecting the best tools for the job. This in turn allows us to align QA and developers in what it means to consider a feature “complete”: how it should be designed, build, tested and how users will access it.

This alignment and strong communication mean greater efficiency in testing and a stronger bond between developers and the testers who support them. As a result, testing ceases to become a blame culture of finding faults, but instead celebrating that every issue found means a better product.

“Quality Assurance helps to develop a product that meets the client and user expectations and is on a consistent level of quality. It builds trust in the company, resulting in the users’ greater willingness to choose the product/brand again.” – Marta Rydel, Senior QA Engineer

How does gravity9 approach Quality Assurance? 

Our QA professionals are a key part of the development team.

Although their remit may differ (with developers working on new functionality and QAs on all manner of testing) we consider them symbiotic. Often, our developers have experience in testing and our QA professionals can code!

We follow a shift-left approach, introducing testing early in the development lifecycle. The concept was first coined in 2001 by Larry Smith who said, “Test early and often.”

QA is introduced at the beginning of a project, working with developers on requirements gathering and design reviews before coding begins. It’s easier to suggest and action changes on paper and so QA can offer early input and different perspectives (championing the end users’ point of view).

We’re experienced in both manual and automated regression testing and will pick what works best for a specific situation, as well as accessibility testing – to ensure the product is suitably accessible to users with disabilities.

Although we’re experienced and look for self-sufficiency in our people, we are also constantly self-improving! We share knowledge; techniques, processes, and tools on a cross project basis (while maintaining client data security of course).