In Part 1 of the text QA > Tests we discussed a little about how things worked in the development process of a system using the Waterfall model and that, in this model, there was a stage before delivery which was the Testing stage, and it was in this moment that Quality Assurance acted validating if what had been developed was what had actually been requested. We also saw a little bit of how this same development process happens when we use agile models, which was when “Quality Assurance” became “Quality Analyst” and stopped working in an exclusive testing stage and started to analyze quality as a whole and point out improvements in all the processes. But since in the agile model there is not a single step for testing, how does the QA role fit in?

At this moment we bring the concept of the Testing Manifesto. A concept created by Karen Greaves and Samantha Laing which is similar to the Agile Manifesto, but is a test-oriented manifesto.

Let’s explain each of the items:

Testing throughout OVER Testing at the end

• According to the authors of the manifest, testing should not be a step in its flow, but an activity like any other dev activity. The test must be an activity within this flow
• It’s also about implementing automated tests in the pipeline and having the QA person help to analyze the developed tests, it’s actually being inside the development process and not just acting when it’s already developed

How this can be done?

• QA can participate in Code Reviews
• QA can help write tests, either in pair programming, or in an area of the system that is not covered yet.
• Do a Deskcheck, which is a quick meeting to ensure that what was developed was really what was expected before sending it to the client to test

Preventing bugs OVER Finding bugs

“The greatest victory is that which requires no battle” – Sun Tzu

• The main idea is to prevent and avoid bugs during the development process before they reach the end user.
• QAs can even find bugs, but it’s important to try to prevent them.

How this can be done?

• Having the QA help the PO in writing and understanding the story. This helps the QA clear up doubts, think about what needs to be checked later, in addition to being another look at what will be delivered, a look beyond the business, but which will also think about the quality of what will be delivered. This can even help define clearer acceptance criteria.
• Pair programming with the developer, which helps to understand and also give suggestions on what is being developed

Testing understanding OVER Checking functionality

• It’s not about validating that what was done is in accordance with what was written, it’s about being the user’s advocate. It’s understanding what needs to be tested, understanding the business and checking if that really solves the user’s problem

How this can be done?

• Having the QA person in the writing part of the stories helps at this point too
• Have a Kickoff before the start of each of the stories. A quick chat with everyone who will be working on this story to see if everyone understands what needs to be done. In that conversation, the QA person can find other testing scenarios that can be done and can help the developer think about the automated tests he needs to do.

Building the best system OVER Breaking the system

• Prioritize the tests that really need to be done and test real scenarios that can happen

How this can be done?

• Helping the PO in the validation with the client

Team responsibility for quality OVER Tester’s responsibility

• The quality of the system is everyone’s responsibility
• QA’s role is to ensure quality and point out where it can be improved.

How this can be done?

• Have the QA person point out process improvements for all stages of development

With this, we can understand that QA is different from Testing.

When we look at the responsibilities of a QA, we see that part of this person’s job is actually testing, but he must also be present at all stages of development, from writing the story, to delivering the product, pointing out improvements in all processes. and he has some of the responsibilities of each of the other roles on the team. For example: we know that one of the roles on the team is that of the PO, and the QA also does a little bit of that when it helps ensure quality and also helps with writing the stories. In addition, the QA also has a joint role with the Business Analyst, which is to have a real understanding of the business and help improve the team’s processes. The UX part is no different, the QA also helps in understanding the user’s needs and also challenging the requirements, when a requirement turns out to be bad for the user. And finally, QA can also collaborate with DEV in writing tests and that’s why QA is much bigger than tests!