Lately all the bees have been talking about a popular buzzword: QA. As you may know, “QA” is the acronym for Quality Assurance. (Every good buzzword needs an acronym, right?) It’s also commonly known as, or related to, Quality Management.
Defining QA by the Textbook
A Google search for “QA” will provide millions of search results, as well as many different definitions. A few include:
- “A program for the systematic monitoring and evaluation of the various aspects of a project, service or facility to ensure that standards of quality are being met” (Merriam-Webster)
- “A way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers” (Wikipedia)
- “The process of verifying whether a product meets required specifications and customer expectations” (TechTarget)
There are plenty of articles, blogs and documents to define QA best practices, along with a plethora of QA softwares and services on the market.
Defining QA in the “Real World”
I have a beautiful daydream in which all technical development work undergoes agonizing scrutiny to test all the possible things in all the possible scenarios for all the possible users and profiles. It’s a grand idea built on ambitious goals, but in the classic Agile world, it will most likely always remain a dream.
Agile means quick sprints for big projects with short deadlines. And because historically the QA player has been the one standing on the sidelines during the last few minutes of the game waving two hands in the air, shouting “Put me in, coach!”, testing is often the first thing to get cut when deadlines close in and budgets are looming. Real-world QA is quick and dirty, often inconsistent, and something most people would like to avoid rather than dig into.
Interestingly enough, even though there may be a general lack of passion regarding QA in our industry, there simultaneously exists a need that’s widely acknowledged. Recently, I’ve found myself involved in many conversations with partners, peers and other industry peeps, in which the importance of QA is the focus. The consensus seems to be that while QA is desirable and needed, few have the QA practices that they “should” in place, and developing standards within organizations is a daunting undertaking.
Why QA Anyway?
Even though a lot of people loathe writing test cases and running functional tests, documenting QA practices is incredibly important to providing working, sustainable, quality developments. Years ago when the Agile methodology was first introduced in the Manifesto for Agile Software Development, documentation was regarded as secondary to responding to changing requirements and delivering working software. While that stance remains true for rigid Agile environments, in recent years, we’ve seen industry trends put more emphasis on documentation because clients are asking for it.
Is This a Test?
One of the most effective ways to measure quality is to test, test, test. But what does that mean exactly?
QA testing is NOT:
- Isolated – QA should be collaborative work.
- Subjective – The evaluator should identify an issue without analyzing its importance.
- Scantron sheets and #2 pencils
- A Facebook quiz titled “Which kind of princess are you?”
- Undocumented – Documentation is critical for repeat testing and transparency.
QA testing IS:
- Functionality tests – These tests verify the capabilities of development.
- Writing test cases and test scripts – Again, documentation is critical for repeat testing and transparency.
- Design document comparisons – Verify that development matches the design.
- Regression testing – Re-run tests to ensure new developments do not interfere or inadvertently impact previous developments.
- Browser and mobile platform testing – Test developments across multiple browsers and platforms to ensure user experience consistency.
- More of all of the above – QA nerds like me geek out over trying new developments, trying to break new developments, documenting the process and collaborating with developers to resolve discoveries.
Beyond the Buzzword
Agile typically means that the responsibility of quality assurance and testing is shared by a team. However, as with any task, there are those who l-o-v-e it and those who gloss over at the mere mention. While responsibility is shared, a QA “owner” is the best case scenario. Furthermore, though testing is traditionally thought of as an action at the end of development, today’s best practices encourage forward thinking about testing and quality management.
To illustrate a progressive approach to QA, here are some examples (certainly not an exhaustive list!) of what QA and testing can look like throughout the duration of a project:
We’re not only rooting for our QA players. We’re relying on them to help deliver the best solutions and make our clients heroes.
Have questions about how to simplify or strengthen your own QA? Reach out to our experts anytime. We’d love to help!
