What QA Really Means?

Today we will cover a big and important question: what is the real meaning of QA? If you google it you will find different meanings but all of them (or the majority of them) will say that QA is, more or less, testing but it isn’t.

“Sometimes, you only have to sit and look at it from a different angle.”

It simply depends on the point of view:  some people might think it is only testing, testing with Continuous Integration, certifications…but what is it really? For us, a matter of QA is a matter of project success.

To get that project success we defined 7 simple rules:

  • Commitment: The entire team is committed to excellence.

  • Continuous process: If QA is not only testing, it cannot be involved only at the end of a phase/iteration. QA is a continuous process that should be done from the first minute that the project starts until the last minute it ends.

  • Definition: Definition matters and it is the base of the whole process:

    • Definition of Ready:  A functionality is ready to be done if we can answer the following question: Can be a functionality covered by the developer team?

    • Definition of Done: We can say that a functionality is done when it was ready to be covered, it is ended by the developer team and it is validated. So, we will be able to deliver it.

    • Workflow:  Even if we use agile or non agile approaches, the workflow should be defined and followed by the entire team. It is strongly recommended not to reinvent the wheel: investigate the existing ones and if you don’t like any of them, edit the one you most liked.

  • Standards: If the quality starts in the bases, following the standards is really important. For example: ensuring all the code we develop (UI, back-end, Testing…) follows a proper code style is crucial but, who does define it? The team(developers & QA members).

  • Testing: We have been saying that QA is not only testing but it is necessary to ensure the quality of the product and that it is free of bugs.

  • Delivering:  Delivering and integrating the software periodically will help us to keep QA as a continuous process and also we will be able to test and validate it as soon as possible. On the other hand, it will help us to simulate the move to production (MTP), because we should deliver it in the same way as when we deploy it in production, so we will be also ensuring a clean and safe move to production.

  • Validation: Validating a product is not only testing,  it is ensuring we have done what we had to (what the customer wanted).


Those rules are not so difficult to follow and remember: that the greatest level of quality you have ensured for your product, the more customer satisfaction you receive. Seeing this you can think “Ok, so let’s do QA!” but it is not so easy: you cannot do QA, you must feel QA.

"If you follow the process by doing QA, you may succeed. If you follow the process by feeling QA, you surely will."

Emergya QA Team

QA as part of the team

When we talk about QA we are used to seeing Developers and testers but you should change that idea: there is no Dev and QA team, there is a team and it is the beginning of the commitment.  Being a team, we start sharing workflows – so QA is part of the development flow – and we have a team that is dedicated to excellence.

Here we would like to highlight that working with an agile approach helps a lot with the QA adoption. Why? Because before a feature or User Story goes into development, it would be Ready to be Done (the QA members along with others discussed what exactly should be on a story card, so the functionality is really defined). From this discussion, not only is the functionality defined, but the test plan is started.


If we analyze  Scrum, we can highlight were QA becomes important:

  • Product backlog: The normal scope when we work with the product backlog is the responsibility of the product owner (usually, the customer) but, what about QA? QA should be in this phase because QA should know and love the product as much as the customer.

  • Sprint planning:  The sprint should be planned taking into account QA time boxes. Why? Because QA will be in the workflow, so they will say how difficult the testing and validation of a US are, so we will plan the sprint depending not only on the development point of view: we will plan taking into account developers and QA.

  • Sprint review: A Sprint Review is held at the end of the Sprint to inspect the increment and adapt the Product Backlog if needed, so the feedback of the QA lead really matters – remember that QA should know and love the product as much as the customer.

"Quality means doing it right even when no one is looking."

Henry Ford

So, the team will not be focused only in the development:  now the team is focused to customer satisfaction.

Here you have a brief about what we understand about QA and, as you can see, for us it is much more than testing. We will post more related entries talking about how adopting QA in your workflow focusing on types of tests, code repository usage, tools, environments and much more! Just stay tuned and, remember, feel QA!

About the author

Let’s have a coffee and talk about your project


Let’s have a coffee and talk about your project


We use cookies to ensure you get the best experience on our website. More info.