Quality Assurance. A job title that you see more and more on top of the paycheques. Also called a tester or technical tester. Or just QA. Just like all other job titles, the word itself does not really say what the job implies. Let alone what the importance is of a QA within a project. So it is time to dive into this.

The job title itself already says a lot about what the job implies: Quality Assurance. Loosely translated, this means the assurance of the quality of the product. But let’s not do too much of the sales pitches.

In my experience, a QA is much more than the loose translation from the job title. Being a QA requires a certain way of thinking, a certain way of doing, a certain way of helping. Depending on the person behind the job title, the QA can be stronger in one of those skills than the other.

People with autism are, because of the way their brain works, very good in some specific thing. Especially the ability to focus on one thing and trying to know everything about that thing is something that a QA can learn a lot from. To make yourself an expert of new functionality or design, to then point out all the errors and bugs, is the ultimate level for a QA. With that, the main goal is, of course, to make the project better, little by little, for the user.

As a QA, I am expected to pay attention to all the small details of the implementation. Of course, the happy flows of the new functionality needs to work properly. But the added value of a QA is with checking the edge cases. In order to properly check those edge cases, you as a QA really need to know every detail of the added feature. In other words, you need to make yourself an expert in the new feature. Figure out how it really should work and don’t let it go before you are convinced that the user will be happy with the end result.

We all know this within the development team: after giving a lot of blood, sweat and tears the new feature is finally there, crashes the application on a different place in the application. This is not always something that we can prevent from happening. Because we use elements and parts of the code on different places in the applications, it can happen that changing those part of the code breaks stuff on some pages.

This is also something that the QA a helps out with. As kind of a goalkeeper of the team, the QA is there to track down the errors and crashes due to code changes. Most of the times these errors and crashes are found during the regression test. During the regression test, the QA goes through the whole application. In theory. Because there are some limitations to what the QA can do. Depending on the size of the application, technical limitations and the time that the QA has got for the regression test, the QA can check only parts of the application. To keep the comparison with sports: how bigger the goal is and how smaller the goalkeeper, the more ball will end up in the goal.

Just like everything else are our lives, the work activities of a QA is also subject to trends. Thé trend of today is test automation. It looks like it is the magic word nowadays within the field of testing. It is fast, accurate and ensures a better quality of the product. If this is always the case, is something for a different blog. But this does not alter the fact that for some projects, test automation can improve the quality of the product.

And this brings a new aspect of being a QA, namely being a developer. Not a developer of the product itself, but a developer for the quality of the product.

Within my work, I notice that one of thé main characteristics of a QA is to be a good communicator. Almost my whole day I am in contact with the developers, the project managers, other QA’s, the designers and the customers. And don’t forget making sure that there is communication between those different roles.

This is one of the biggest added value of the QA. Not the communication itself, but especially asking a lot of question. What is changed? How should it work? Is it correct if I see this? By asking these kinds of questions, the purpose of a new feature will be more clear to everyone involved.

With this, it is really important that the QA is clear about what he or she means. Clear in what he or she sees, but also clear in what kind of information he or she expects to receive. This requires a certain skill set. Communicating with a developer is mostly on a different technical level then communicating with a designer or with a customer.

In my experience, a QA has become an essential part of the development team. Not only for maintaining the quality of testing the new features, but also all the steps before and after the implementation of new features. The whole process can sometimes use a different point of view or some extra questions. The QA is the person who should naturally be good at this.

Of course, not all the QA’s are the same. One QA will be more focused on the structure of the application, while another QA will give more attention to the communication. Nothing is right or wrong with this. It is up to the Project Manager or the supervisor to see the qualities of his or her QA and to anticipate this. Just like he or she needs to do with all the other people within the team. As long as there is at least someone who keeps an eye on product quality. Because that should be the main goal. Not that there is a product on the market, but that the quality of that product is good.