NO Quality Assurance, NO ACCEPTANCE!

Let’s Move Quality Assurance Engineer’s work to the beginning

It’s common practice that the project manager, product owner, scrum master would sit (well definitely not stand because of the hours involved) with the product team, head of engineering, risk department and any other departments to discuss the product features, draw a roadmap, process flow and document acceptance criteria.

Based on my years of experience, I have seen that, while we may capture a number of scenarios and a number of use cases, we tend to have several iterations at the end of the development cycle. The quality assurance engineer would run tests and send feedback to the board for the development team to pick up again thus continuing the cycle. It might go on for two or three cycles before it finally passes to be released to either a staging or production environment.

What I have come to realise is that because a QA engineer has expertise in coming up with different scenarios from positive to negative to edge cases, he/she tends to cover a wider breadth than a product manager or scrum master would. This is why I believe that we should develop our product with testing in mind.

What exactly is the product meant to achieve? Yes, that is what we focus on but there are other things like; what other scenarios can probably occur that would make us go back to the drawing board? It would prevent the number of hours that we spend in the iteration cycle.

Also, I have come to observe that the more iterations we have, the more bugs we tend to drop in the code, the more wary and the less enthusiastic the developer becomes to complete the ticket. At some point the tester may just pass the ticket and say, “You know what?, I’ve stressed this person a lot, so lets move to the next stage.“

Sadly, the usual practice is that one QA is assigned to a team and this QA engineer is usually over-worked such that he/she doesn’t have time to review a new ticket because there is a backlog of tickets from the development cycle. However, the QA should be one of the key people that tests and runs through the acceptance criteria before a developer picks a ticket. it would be best practice in my opinion to allot a work item — “Review of acceptance criteria by QA” popularly termed Test Driven Development (TDD)

There is something called the DEFINITION OF READY. We only practice the definition of DONE. But the definition of ready is to ensure that a ticket is ready, clear and concise for the developer to pick up, run with it and implement the product feature we desire.

So QA reviewing the acceptance criteria should be included as one of the activities before a ticket is considered ready for development work.

Written by @natty_nnor.