As part of a strategy exercise, the Quality Assurance (QA) leadership team and I thought it might be a good idea to benchmark the perception of QA’s role in our own business.
Every response was laced with compliments about QA being ‘the bouncer of the delivery team’, with individuals noting that ‘nothing gets past our eagle-eyed jack of all trades’, and that QA is a crack team of ‘quality gatekeepers, ensuring everything the development team produces meets requirements’.
High praise indeed. What’s not to be pleased with, right?
Real QA lives in the grey
Based on these glowing reports from inside my own organisation, it seemed everyone was happy with how QA operates as a function - rigorously checking, assessing and approving the work of developers. However, therein lies the problem.
Put simply, in an agile world, QA is still viewed through a waterfall lens.
Although it’s great that QA is venerated as a Saint Peter-type figure that has the power to open the pearly gates to truly heavenly digital products, its role should transcend this simplistic perception within organisations.
Testing is part of QA, that’s true. However, it’s not the only string to our bow. Dynamic testing in real terms is often a binary process; things either pass or don’t. It’s very black and white; more at home in a factory than a digital consultancy. However, real QA lives in the grey and we need to dispel the perception of it being a two-dimensional beast.
Fundamentally, QA’s effectiveness is throttled if it’s perceived and treated in this way.
Static testing: Understanding the ‘why?’
For example, understanding the why is one of the biggest tools in the QA box. By shifting left and having QA in the room from day one, development teams - and wider project stakeholders - can gain a better understanding of the ‘why’ and ask far more concentrated questions later down the line - very often as things get more mission critical.
After all, we’ve all been in the room when something is passed over to test and a bunch of QAs find themselves asking ‘why?’, while pointing at multiple different things that have changed since the requirements were drafted.
Static testing could be the antidote to this ineffective way of working. It’s the basic practice of identifying risks and flaws before any code has been written. In essence, finding the bugs before they are born. This is only truly effective when carried out throughout the software development lifecycle. We need to move away from having a ‘testing phase’ and promote a blend of static and dynamic testing techniques throughout. Test early, little and often is the mantra that we live and die by here at xDesign.
Going beyond development and engineering
QA shouldn’t be limited to development and engineering, we have much to offer in other areas of a business too.
For example, a personal favourite of mine is working with UX designers when carrying out existing system reviews and competitor research. Sitting side-by-side (or in parallel when remote) looking at the usability of a product, finding pitfalls and things that seem unintuitive is the really rewarding part of a much more effective approach.
Using quality principles and testing techniques allows us to jointly identify things that work well, and that we may wish to consider when designing/building a solution later down the line. Equally, this more collaborative approach helps in finding things to avoid, and ensuring we don’t repeat the mistakes of others.
Whose responsibility is quality?
When using the Agile delivery model, quality is everyone's responsibility. That doesn’t remove the need for QA however - it simply evolves the role into a more consultancy-based one, and moves it away from being one of binary decision-making and approvals.
Within all product development lifecycles, QA should try and make sure the customer is the focus and help mitigate any blind spots or deviations. We should also be involved in stories, helping to define acceptance criteria whilst redefining the landscape changes.
Importantly, we should also support engineers in scope tests before code is written - whether automated or manual based - all of which should be based on agreed standards and criteria being mindful of end-user needs (including personas).
For example, if an automated test passes for the thousandth time, we do not question the validity of the result. Automation is a phenomenal time saver and has revolutionised testing but without ongoing QA layering do those positives become false?
If we run a manual test it may pass based on intention but we may be more inclined to question whether the test or the criteria are still (or maybe ever were) correct. We should always look to maintain continuous improvement across all testing strategies to maintain the integrity of our approach.
While we’ve mentioned shifting left, it is equally beneficial to shift right too - particularly as we work within real-world conditions. As a result, we should not rest in thinking that our upfront efforts will solve all problems. Rigorous QA is not a silver bullet after all.
What we need to deploy are continuous feedback loops from a real user experience. Working with analysts, engineers and architects we can help define what real-life scenarios might look like and help shape how we test pre- and post-deployment.
Principles for transcending two-dimensional QA
The team and I are always looking for ways to evolve the role QA plays within our own organisation. Based on learning and experiences, we’ve developed our own set of simple principles which help to shape the expertise we can provide and, ultimately, the value we bring. These principles include:
- Get involved in discussions early (passive and active)
- Only be in the room if it adds value
- Focus on the end user
- Automate what you can
- Test manually when it adds value
- When shifting left, test early, more often and in smaller chunks
- When shifting right, look to monitor, identify, investigate and remediate based on real-world scenarios and conditions
- Reflect, refine, improve, progress
Evolving what we do as QA specialists
QA is now a vital part of any organisation that delivers digital products and services to end-users. However, as we’ve explored, it’s not enough for QA teams to simply exist within a business as a so-called testing service to developers - one that spits out binary decisions as to whether digital products are ‘good to go’.
A truly evolved approach to QA can, and should, add so much more value to the product lifecycle - and by extension to the effectiveness and efficiency of an organisation that’s invested in our ever-expanding digital world.
So, let’s banish the old gatekeeper stereotypes, and let’s start drawing on QA to foster more progressive, collaborative and effective experiences in our digital endeavours.