Software Quality Assurance matters because without it we face a world of buggy software and systems that will often fail in ways that are harmful or incur some form of cost that we would rather not pay. You only need to follow thedailywtf to see bad and often embarrassing software failures. Software Quality Assurance focuses on improving the quality of the end product delivered to customers by working to assure quality throughout the entire lifecycle. Testing processes represent only part of that entire lifecycle, as such QA encompasses test but also goes beyond. Quality Assurance to me is as much about defect prevention as it is about defect detection.
It might help if first I explain my definition or interpretation of Quality Assurance as opposed to Test.
- My definition of software testing – goalkeeping, the last defence between buggy code and the customer
- My definition of software quality assurance – a focus on quality practices and processes across the entire development lifecycle
So, expanding on those definitions;
Testing is the art of exposing information (where that information is often a defect), and is typically performed by dedicated engineers on a built software product. (Yes, I realise I am painting a picture with very broad brush strokes here but my intention at this moment is simply to use the common interpretation or perception of test to illustrate the difference between this and quality assurance). Testing tends to be focused on the design of tests and how they will be executed. Often with metrics around numbers of test cases, defects found, functional areas covered etc. All of which are important in some way, but represent only part of the quality picture.
QA however typically focuses on the processes and practices used throughout the entire development lifecycle, with the intention of assuring that these facilitate the delivery of a quality product. Thus quality assurance is as much about defect prevention as it is about defect detection, in other words taking steps to prevent defects being coded as well as trying to ensure any defects in the code are detected as early and efficiently (and thus cheaply) as possible. In terms of prevention I am often heard to say “the cheapest defect to fix is the one that never gets coded”. (I will talk about some of the approaches and techniques I use to help prevent defects being coded in future posts).
QA really starts at the beginning of the development lifecycle, typically with the idea, concept or requirement analysis phase. The focus at this stage being less about ensuring we have tests designed to cover each requirement, but more that the whole team fully understands the requirements; how they will benefit the customer, what sort of changes they will require to the existing product, what could go wrong etc. The aim being to avoid coding the wrong thing, (TDD or BDD anyone?), and to ensure no bad assumptions are being made, (assumptions are at the root of many defects), whilst also preparing ourselves to test the delivery of the requirement throughout all the development lifecycle phases, ensuring the fastest feedback possible should we detect any failures.
QA also continues after the product has been shipped, analysing any customer exposed defects. (I will talk about the approach I take for this in a future post). Taking steps to learn from those escaped defects and applying those lessons to the appropriate phases and processes in development lifecycle. As an example, learning that we missed a defect because we did not have the means to unit test a particular type of code interface. Using that knowledge to make a change, (re-factor the code), to enable a mock to be built which in turn enabled full unit testing of that interface, and thus ensured the future quality of that code in the cheapest and most efficient way. Another example where we learned we missed a defect was because we did not fully understand how the customer was utilising a part of the product. Applying what we learnt to the requirements analysis process to ensure we include that understanding into future changes in that area of the product, whilst also ensuring we added tests that used the product in the same way as the customer to guard against future regressions. (I will talk about my method for learning from escaped defects as well as metrics around those in future posts).
References: