Why your QA team should be just as friendly with UX as they are with developers
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.
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?
- Are they aware of any platform specific issues?
- What has frustrated the QA engineer while using a previous iteration of the product?
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?
- Are there any repetitive tasks that quickly become frustrating, or are slow to execute, especially when considered as part of the whole product?
- How does the design hold up across different devices, screen sizes, environments of use?
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.
- Give your QA team some time to learn the basics of accessibility. Create a shared resource that they can refer to.
- Encourage manual testing on a range of devices. Whether these are physical or virtual, it’s one step closer to testing the same way your users interact with your product.
- Let your QA team see the analytics. Often considered exclusive to the realm of data analysts or developers, the democratisation of this invaluable information is essential for a cross-functional team.
- Encourage your QA team to understand Jakob Nielsen’s 10 Usability Heuristics for User Interface Design. Sure, your design team are intimately aware of them, but they can be eye-opening for a QA engineer.
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.
