Do you remember those Hanes commercials, where the underwear was inspected by inspector 12?
The point of those commercials was that before those underwear protected your man package, someone decided that they met some established standard of quality to bear the Hanes seal.
If a thread were out of place, if the sticking was off, if the color was wrong, that pair would have been rejected.
Hanes was giving its customers a glimpse into the world of quality control.
The world has changed a lot since then, but the concept of quality control has not.
It has actually made the leap from physical good to digital ones.
If you’ve every built a website, mobile site, mobile application, micro site or kiosk, then invariably part of the process involved subjecting the product being developed to some form of testing.
In the digital space, we refer to this testing as quality assurance testing or QA.
QA is a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers.
During QA, the developers ensure that the product that they’ve developed meets all the criteria established at he beginning of the development cycle.
Essentially, you’re running your website, mobile site, app, kiosk – your product, through it’s paces, confirming that it performs correctly, logging defects and passing those defects to the development team for remediation.
Typically QA testing involves making sure that at a threshold level, all the component parts are there: home page, navigation buttons, header, footer, menu, shopping cart, etc. and then making sure everything works the way it’s supposed to.
So during QA, testers run through test cases or test scripts to make sure your product behaves properly following the “happy path” as well as when users do something completely unintended.
If they encounter something anomalous, they test again, to see if they can replicate the error they’ve just observed – and if the can, they log the defect by providing the exact steps to reproduce the error, so that the developers know what to look for.
Logging a defect involves detailing the starting point, the exact steps the tester followed to trigger the error, the expected and actual results.
Often that defect log will include a snapshot (or snapshots) of the actual observed error.
Once the developers review the defect, confirm that the issue is not just a one-off caused by a poor network connection, tester error, a source issue (for example a mobile site generating the same issue as the full site) or something wholly unrelated to the product being tested, they get to work on resolving the defect.
When the problem has been solved, they’ll pass it back to the QA team for validation of the fix. If everything checks out – the fix passes. If not, they’ll send it back to the developer with additional notes about what they’ve observed.
This process continues until the issue is resolved (or until the developers determine what blockers must be removed in order for the issue to be resolved – because sometimes the issue may lie elsewhere).
If there’s a ‘green light’ the fix (or fixes) is/are passed from the development environment (QA) to the client (for user acceptance testing) or live (depending on the severity of the defect in question and internal protocols for resolving live defects).
No one cares if your website or app looks great if it crashes.
In fact, there’s a whole world of QA testing which is devoted to trying to break your website or app.
Because people aren’t always as smart as we give them credit for being.
And websites or apps don’t always perform the way they’re supposed to.
So QA ensures that you don’t put out anything that you would want to put your seal of approval on.
Stephen Chukumba 