UX and QA
QA is a bit like UX in a sense that although we have some professionals and roles in the development process that are meant to be solely focused on it, when in fact it has to be a concern of everyone that is involved in the process.
This is not really what happens most of the time, typically we will see a QA analyst entering the process after a development iteration, going through a list of all the developed features that have been finished and then writing descriptions about the steps and conclusions of the failed tests. In the most advanced teams and processes we get to see unit tests around the most important parts of the logic of the system, or automated end to end testing scripts that mimic the users behaviour.
It’s the goal of these procedures to catch the errors before the actual end users, this preventive model impacts in many ways the UX of the end user because not only will the system be released will less bugs and consequently less frustration for the user, but it will also have secondary effects of optimizations and different inputs when there’s a human analyst just clicking around or trying to break the flow, basically acting as a user with multiple personality disorder.
Trying to break the system is the fundamental purpose of QA, because if you break under controlled circumstances you can handle the issues that led to the actual break. But we could easily say in a different way, more focused on UX: trying to catch all frustrations the users may experience while using a system is the fundamental purpose of QA. It will still be a very on point definition of QA and it makes it clear how much UX is dependent on good QA, although the idea here is not to rewrite the definition of QA, just expose it’s close relationship with UX.
So it’s safe to say that QA is a complementary part of UX in many perspectives, it is the expression of the intention in the development process to strive for the best possible user experience, letting go of the pride or arrogance of the mentality that we get it right and simply assume we get it wrong, so let’s just improve the process so that the user doesn’t get affected by it.
This is the last post of the series, the first post in the series:
UX and the requirements gathering phase
How requirements gathering and UX seem like the same first steps to building a new software
Previous post in the series:
UX and documentation
Documentation is of extreme importance to end users and not what developers like the most to do.
This is part of a series of posts listed here: