The document argues that the term "quality assurance" (QA) no longer accurately describes the role of testers in an Agile development process. QA implies monitoring and assuring quality from the outside, whereas testers are part of the development team. "Quality assistance" is also problematic as it implies assisting others rather than creating value. The document proposes using "quality intelligence" instead, which better captures how testers acquire and transform product data into useful information for stakeholders. Adopting this new term would help testing roles fully transition to an Agile paradigm.
2. Introduction
• “Quality assurance (QA) is a way of preventing mistakes
or defects in manufactured products and avoiding
problems when delivering solutions or services to
customers” [1]
• With the Agile paradigm shift it is time to put this old
acronym to rest, as it no longer accurately describes what
we do or how we relate to our environment
• In this presentation I will explore why we should not use
the QA acronym when talking about testers and test
organizations anymore, and what we should use instead
3. Quality Assurance
• “Software quality assurance (SQA) consists of a means of
monitoring the software engineering processes and
methods used to ensure quality.” [3]
• This definitely does not describe what a tester or a test organization
does
• And even if we disregard all the official definitions of
SQA/QA and just talk about what it has historically meant,
it still does not make sense
• Testers do not assure quality
• Testers are not monitoring the developers’ work
• Testers do not own quality on their own
• Testers are not defenders of quality
• Testers cannot assure quality directly in any way
4. Quality Assistance
• Quality Assistance [2] is a way to make the QA acronym fit
better into an Agile environment
• But just like if you try to adapt waterfall to an Agile environment,
you are just trying to prevent the paradigm shift from happening
• So what is wrong with Quality Assistance in Agile?
• A tester is a part of the development team – they are not an outside
entity that assists the development team
• Quality Assistance does not highlight what value the tester actually
creates – it puts the tester firmly in the passenger seat, only there to
allow someone else to create value
• Quality Assistance allows the tester to feel less ownership as they are
only assisting someone else, and are somehow not accountable
together with the rest of the development team for the final product
5. Business Intelligence
• “Business intelligence (BI) can be described as "a set of
techniques and tools for the acquisition and
transformation of raw data into meaningful and useful
information for business analysis purposes”” [4]
• BI is not called Business Assurance or Business
Assistance for a reason
6. Quality Intelligence
• Quality intelligence (QI) can be described as "a set of
techniques and tools for the acquisition and
transformation of raw product data into meaningful and
useful information for quality analysis purposes
• Why not?
• Isn’t this what testers and test organizations actually do?
Acquire and transform product data into useful information
for our stakeholders?
7. Conclusion
• Quality Assurance is a part of the Waterfall development
process, and if you do not working according to that
process, then you should not call it Quality Assurance
• Quality Assistance is just a way to adapt the acronym to
an Agile environment, and this only hinders us in making
the paradigm shift
• Quality Intelligence much more accurately describes what
we do, and allows us to really start thinking in an Agile
way