When we talk about UX (User Experience) we talk about the dialogues that occur between a given interface and people.
I talk about people because when we design digital products or solutions, we do it for human beings, and I find the term "User" a bit impersonal.
Forgetting that our products and creations will be used by real people is a common mistake. Our software is interacted with by people with different levels of education, age, at various times of the day, with or without accessibility issues, and so on.
While it is common to use "people" in product design, typical users, to encompass the highest possible percentile, it is a custom more used in UX than in programming.
A recurring problem in the industry is to separate development, design, QA, etc. into silos. This leads to a lack of communication or at least a barrier between areas, which must be eradicated. If we do not do this, we may incur in analyzing a product with biased eyes, or reduce it to the sum of its parts. Serious mistake.
Testing how user-friendly a site or app is, not only it's beneficial, but necessary. Apart from the testers having basic notions of UX, complementing it with a real test using a sample of at least five people (Virzi, 1992 and Nielsen, 1993) will allow us to ensure that we cover at least 80% of the usability problems.
It is a matter of taking neutral profiles, outside development, outside design, who look at the product with fresh eyes, providing valuable feedback, which we, in the hustle and bustle of everyday life, and in the frenzy of the projects, can miss.
One tends to associate the role of the tester and QA with code errors, layouts and bugs in development. However, if our software is free of bugs, but does not respond to the problem it was intended to solve, or is not user-friendly, is it really a good product?
The role of QA is to guarantee the correct performance of what has been developed. This includes minimizing the number of existing bugs, either by manual or automated testing, APIs and many other methods.
But it also includes a preventive aspect, for example an instance of prototype review in design, can detect failures or usability improvements before they go to layout and development. It should also be an extra check to ensure that the product design team has not missed something key.
Sometimes it also includes proposing new methodologies and workflows to verify the aesthetic and functional compliance of what has been developed, a role closer to operations.
It is about ensuring the quality of the product in all its forms.
All this brings us back to usability. The latter is often the differential between a good app and a great app.
That QA Testers have notions of UX, and give it importance, is especially vital when you take into consideration that most design teams are shared among several projects simultaneously. As a result, they are often disengaged when the client approves wireframes and high-fidelity prototypes.
Someone has to look after the experience of the people who will interact with the software after this stage. A simple review of usability heuristics can address most interface issues.
People working in engineering and development have a very different view from that of a customer, just as the customer has a very different view from that of the designer. What is achieved or fulfilled for one is not the same as for the other, and this is logical.
Reality is made up of a little of each of these views. Partly a more artistic and flexible one, of how a product should look and feel. Another, more pragmatic and analytical.
All are necessary to create something that fulfills what it proposes to solve, that works optimally, that is friendly, aesthetically pleasing, that is scalable, that is accessible, in short.
We must understand that QA and UX are more holistic concepts. Do not think so much that QA is a tester, that UX is focused purely and exclusively on usability, but understand both disciplines as Quality and Experience.
From Quality Assurance we can assist in the process of improving the final experience, we can test the flows proposed by UX, go through the application and verify the error and success messages, that the system provides feedback on its status, and contribute a lot from our side.
We have to make sure that we give as much help and attention as possible in the early stages of the project life cycle. Each bug detected at this stage is exponentially cheaper to fix than in development (and in production of course).
Ideally, you start by testing prototypes before moving on to development. If QA is not an integral process, it loses a lot of potential, and we are guaranteed to have much more work in later stages.
At this point is where I vindicate manual testing in favor of automated testing. It sounds logical that if our product will be used by people, it should be tested manually by humans as well.
Is it intuitive, are the flows tedious or do they feel right, do I have a lot of avoidable actions in the process, do I have unnecessary clicks, does it fit well on all screen sizes?
Naturally, these are criteria that have subtleties and subjectivities. It is vital that the tester in charge can say:
Whether the testers are skilled or have a trained eye will be especially relevant if the product involves marketing.
In summary, we are at a time when we have to think about usability when talking about quality, and building the experience of our digital products.
For this, it was recommended to eliminate as much as possible the silos, to avoid that each area works as an automaton that receives inputs and delivers results without taking into account the enriching interaction that is left aside by not touching the doors of the UX area.
QA and UX are disciplines that have a lot to contribute to each other. In fact, a collaborative methodology is proposed. Open communication is extremely important, with specific channels designated to facilitate the flow of ideas between both teams.
It can be constant meetings with the developers to see the prototyped interactions, in the corresponding context, and thus establish the expectations in a clear and visual way.
Documentation is critical, defining where, how and a standard for communicating specifications becomes increasingly important as teams grow and projects scale.
The next step is to educate QA on Usability and Design concepts, to train the eye on what to spot and anticipate, which would allow QA to test the entire interface so that elements look and behave as designed.
Performing a demo with developers is a step in the right direction if you are trying to achieve a feedback loop that will serve as constructive criticism and give them context to the tickets they receive.
The last thing would be to define a clear and uniform channel to raise design and usability bugs. Nomenclature, images, labels, priority, etc.
Having said this, it is worth adding that for the future, it is ideal to complement our skillset with skills that cannot be automated, or are almost impossible to replace by a machine, such as the study of interactions. It will become increasingly valuable to be a polyglot QA, who understands complementary disciplines.
