Normally we talk about Tester and Quality Assurance (QA) as if they were the same professional profile. However, they are two very different roles. Resembling both profiles is like saying that a developer and an analyst are exactly the same. Or that a painter and a carpenter perform the same functions because they work in the same place.
Testing is an activity. Anybody can test. Sometimes testing is just using a product, while QA uses testing strategically, after planning how and what to test.
Imagine that you're good at cooking and that you can prepare tasty meals. Given that you cook for your family and friends, does that make you capable to run a restaurant? Could you plan and design the menus, source the supplies, monitor the food and the service, train your staff, set up a cooking line, etc? The individual ability to cook or test something is a small but also an essential part of a larger process that is complex, dynamic, and full of pressure, and that requires strategic view and tactical execution.
Let's call things by their name
Somewhere I read a phrase that caught my attention:
"A Tester is responsible for finding failures, but a QA not only finds them but helps to prevent them."
Without going deeply into the tasks performed by each of them, this may be the best definition I have found today to differentiate them. After analyzing several definitions that I found on the Internet, I can say that these can be quick descriptions of each profile:
Tester: a person in charge of testing software during its development phase in order to detect bugs and report them.
Quality Assurance Specialist: a person who performs a set of activities in order to ensure the quality of software during all its phases.
The key difference is that the QA is interested in the process while the Tester is interested in the product.
The evolution of Tester to QA
In many cases, a QA performs the tasks of a Tester, but we can not say that a Tester performs the tasks of a QA. I would say that Quality Assurance is a tester that has evolved due to the fact that more tasks have been assigned to him/her. The tasks are varied, but they have something in common: they all contribute to the quality of the project which means the quality of the product, that is the main objective. The tasks performed by a QA are increasingly more and I would need to write at least another post, but we will focus on the most common:
Collaborates in defining the product, assisting the product owner to define or he himself defines the acceptance criteria. This role is very important for two reasons:
1. The QA is usually the one that has a more horizontal view of the product and therefore is usually the one that can contribute the most when defining certain requirements.
2. Well-defined requirements avoid misunderstandings on the part of the developer and thereby help prevent defects.
From the definition of the steps of continuous integration to the configuration of tools, through the creation of jobs, we can say that the QA is an important factor in this part of the project. A good continuous integration, accompanied by good automatic tests, contributes a lot to the quality of a project. Not only increases the speed with which we have new code in production, but it helps to detect and avoid defects.
Every time there are more cases in which the QA does tasks that were previously seen as system tasks. These tasks are necessary so that the QA can perform his work correctly and as quickly and as possible. These tasks can be the creation and configuration of environments, installation, and configuration of tools, etc.
Until now, both profiles are complementary in a project. None of them is better than another. But, in the very near future, probably the number of positions of tester will decline because people who work with software quality should have a more technical profile and have knowledge of the tools, languages, and frameworks that are used in the project.