Why your QA team should be just as friendly with UX as they are with developers

Gareth Thomas
Nov 16 · 5 min read

Gareth Thomas | Senior QA at Purplebricks

It’s no longer the nineties. Your QA team and developers are (hopefully) not embroiled in a war of attrition against each other and are instead peacefully working together towards a common goal of producing a great, working product.

The “shift left” attitude towards testing and quality assurance that is en vogue has radically changed the day to day work life of QA teams. It has lead engineers to move from simply raising and closing bugs, to testing APIs without a front end, become experts in Selenium, Cypress and Cucumber, review code—and in some extreme cases—become nearly indistinguishable from their former nemeses.

But at most organisations, this left-shift has been constrained purely to the “technical” field. There are definitely positives to this, as many businesses, including Purplebricks, have already discovered. However, it fails to utilise the “soft” skills that any good QA engineer should have; a hands-on understanding of the product, understanding the site of common errors, and an empathetic view of users.

Image for post
Image for post
Design and QA working together.

In our mobile app team, we’ve tried to add that skillset to the design process throughout the product lifecycle, something that’s forced us not only to shift left, but also to shift right.

The shift left

Just like a “technical” left shift, this is all about getting involved earlier in the creative process. Whether it’s a formal meeting or an ad-hoc Slack call, you call it a “test kickoff” or “three amigos”. Effectively, the initiation of any design work should start with your QA engineers getting together with your UX, UI and copywriters and making sure everybody is on the same page.

The design team should use this opportunity to clarify any queries they have around the functionality and acceptance criteria, and your QA team should take the chance to impart their experience of the product:

  • Have your design team considered any edge cases?

What that experience entails will depend on your team structure, your product and the maturity of your engineers, but I’m sure you get the point. Your QA team should be product experts, as there will almost certainly be intricacies that they are aware of that your design team may not be.

The Design Box

After your team was set on the right path, and your design team has produced a “finished” product, it’s time for a design box. This is a close cousin of the more commonly known dev box, where QA engineers and developers test together on local code, meaning defects can be found earlier and fixed sooner.

A design box very much runs on the same principle. Using a prototype or even screenshots, your designers and QAs will run through the acceptance criteria or test cases you’ve defined and ensure they’re met by the design before developers start using them to code.

The Manual Part

While there’s very much an emphasis on reducing manual test effort, both at Purplebricks and across the digital world, there is still value in it when focused on the right things.

Hopefully, by the time your QAs get their hands on something to test on the intended medium, the majority of defects, technical and creative, have been found and ironed out, and the character of testing can now change tack.

Testing of our mobile app is naturally UI heavy, so we’ve always taken a “UX first” stance, but a statement that vague can lead to confusion if not defined. Some questions a QA can tackle during manual testing that can add real value during manual testing from a UX perspective are:

  • Is it accessible? Are there any colours that don’t contrast enough? Are the issues specific to a certain device? Are there any flows that confused you, an expert user?

Depending on the context and your own quality gates, it’s not necessary to tackle all of these issues prior to release, but they can inform the next iteration of your product.

The Shift Right

While we may be aiming to shift our testing left, a good QA will still take some ownership of quality after the product’s release, and tasks like collating user feedback, looking for troublesome platforms and interpreting analytics and usage statistics are very closely linked to the sort of work a design team will perform in a discovery phase.

Not only will this production insight help to increase a QA engineer’s empathy with the end user, but it’s something that’s very useful to feed back into your team’s next kick off.

Additionally, depending on just how in-depth your analytics are, understanding exactly how your users interact with your product can help your QA team refine how they test, increasing the value of that manual test phase even further.

How can we forge this friendship?

This will very much depend on your organisation, your ways of working, your product, and your team structure, but here are some things that work for us.

  • Introduce your QA team to your design team! It might seem obvious but with many firms still seeing design as a “beginning” and test as an “end”, there might not be much natural crossover between these two worlds.

While they may be considered worlds apart, quality assurance and design are much more closely related than you’d think. In classic terms, quality assurance is “being sure what we’ve built is right”. The more we shift left (and right), it moves ever closer to design’s “being sure we’re building the right thing” in the first place.

Purplebricks Digital

Discussing all things Digital

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store