Economic theory suggest that people are rational – the reality is, however, that they are not, which is probably why economists are so often wrong. In fact, people are predictably irrational, following thought processes and actions that can usually only be understood by another human being, albeit an empathetic one.

Traditional software testing processes have often fundamentally misunderstood people and the needs of testing. By approaching it as a tick-box exercise that follows repetitive and set user paths, they assume a level of rational predictability that is rarely present in human behaviour. Technical tests, especially those that are automated, don’t replicate the desire of users to click where they’re not supposed to, and can’t accommodate irrational human behaviours. In other words, the more structured and logical we are, the more likely it is that we will miss the opportunity to improve usability and remove the bugs that actually impact real users.

Of course, technical testing should be used as a hygiene factor during product development, but it needs to be supplemented by an empathetic and realistic approach to the user experience. In other words, Quality Assurance, and a QA expert to act as a user champion by injecting some irrational realism into the development process.

That might sound blindingly obvious, but it is often missing in development processes. What follows here are some of the ways we think about the differences between testing and the more powerful QA:

Being Conscious Of The Irrational

Testing treats users as a single, homogenous group but QA adopts different user personas in its process.

Users are varied and have differing needs and demands. A robust QA process will use a variety of user personas and groups but a mechanical, logic-driven process is incapable of doing so.

Starting QA At The Beginning

Testing is the last step in the development process, whereas QA runs throughout it.

Here at Made by Many QA involvement in the first stages of concept development means it can create expectations of what the user will experience. This also means it can act as the voice of the user in the design process and keep the work grounded.

Being Realistic About Innovation

Testing checks if functionality works, whereas QA measures whether functionality delivers.

Sometimes creative, innovative solutions make perfect sense in the design process but can be confusing to an end user. Testing has no opinion on this matter – it merely checks whether technical requirements have been met. But QA has a holistic view on usability and can help intercept confusing product features before they get to user testing.

Challenging With Empathy

Testing is an audit report, QA is a supportive conversation.

Submitting a long list of fixes at the end of a sprint feels like a process designed to punish developers by highlighting mistakes and errors. A better idea is to work alongside developers as they code to highlight user-improvements so that QA becomes an integrated part of an agile process.

Making Marginal Improvements

Testing has no view on the impact or importance of a bug. QA prioritises legacy fixes into a list ordered to maximise the user-benefit.

Development time and resource is limited. Therefore the focus is on getting the best return on that effort by focusing fixes on what will have the biggest impact for the user. Testing is communist – it treats all bugs equally and has no concept of return.

None of this is to say that we don’t use automated testing: executing pre-scripted tests on the system. We do – but some of the techniques we use alongside it include exploratory testing.

A simple definition of this is test design and test execution at the same time. Unlike scripted tests, exploratory tests are not defined in advance and carried out according to any particular plan. This is a more human, hands-on approach whereby our QA team vigorously test the system under examination using actual devices and browsers, thinking more like a user to uncover bugs and usability issues.

Above all, exploratory testers take the view that writing down test scripts and following them tends to disrupt the intellectual processes that make testers able to find important problems quickly. The more we can make testing intellectually rich and fluid, the more likely we will be to hit upon the right tests at the right time. That's where the power of exploratory testing comes in: the richness of this process is only limited by the breadth and depth of our imagination and our emerging insights into the nature of the product under test. It serves as a complement to automated testing in helping to establish greater confidence in the software by ensuring more defects are found early in development.

That’s an overview of how we see the differences between testing and QA here in the studio, and how we deploy testing.

Get in touch if you’ve got a further interesting perspective to add.