Have you ever had the doubt about, what does it means deliver a quality product? or, what does it means to work based on quality? Well, this questions have an easy but tricky answer, because quality depends on the perception of each person, so, based on this, let me show you what is my perception of quality. In general Quality means deliver a functional product that achieves the expectations of our stakeholders (yeah based on software delivery of course), but, for me, Quality also means, that the team is proud with the product that we are presenting to the stakeholders (insert emotional music here).
Ok, now that we understand the most common definition of Quality (we don't use the one that says "Quality means absence of errors" because, based on Quality Principles, Absence of error are a Fallacy) we need to understand from where this Quality comes from, as I mention before, in my perception of Quality, the whole team is responsible of achieving the best Quality level possible for the product, most of the people tends to asume, that the Quality Assurance person or the Tester are the only one responsible of doing this, that is true (in some way) because we should always have a Quality Champion (QC) on our team, who is in charge of negotiate with everyone to define the best practices that will adapt to the project Quality Strategy (QS) but, at the end, this will always be a team responsibility to understand, practice and improve what everyone defined on it.
My main purpose here is, make people understand that Quality is not a person or department, quality is a commitment that a team uses to define the best practices that can be applied to their specific project (there is not a common path or a typical Quality Strategy for all the teams).
To finish this post, I’ll let you know some desired activities that I get from my stakeholders on the QA activities that I performed on a team:
- Define with the team and maintain the QS.
- Guide the team on keeping track of what we defined on the QS.
- Perform testing activities like static and dynamic testing (manual and automated testing).
- Be aware in the coming activities and the actual activities that the team is performing to raise flags when needed.
- Give the QA perspective in the team activities like deployments, pipelines, developments, business activities, etc.
I can type a complete book about this topic but I’ll leave it here for the moment, this is my first post and I’ll try to continue giving the expertise that I get from my daily activities and I hope that I can guide the people in understanding QA inside the development industry.
Top comments (0)