There’s a popular myth in IT that QA slows things down.
The myth has three variants: thinking that testing slows things down, confusing QA with testing, or thinking that QA slows things down.
Let’s clarify!
Myth variant 1: Testing slows things down
Any production process, be it software or tangible goods, comprises a few parts: deciding what to do, doing what’s decided, checking if it’s being built correctly, and verifying that it operates well (testing).
By definition, testing is an act of checking whether a product satisfies expectations.
In software development, testing is a “dynamic verification that a program provides expected behaviors on a finite set of test cases, suitably selected from the usually infinite execution domain.”
To explain it, let’s take the simplest example from my leathercraft hobby: building a leather wallet.
I decide on the desired look and feel, pick the leather, choose the pattern, cut the leather according to the pattern, stitch the pieces, finish the leather edges, and rivet the snaps. During the process I examine how each part is done: I examine the stitches, open and close the snaps, and check if the edges look nice. I test it all the time, during and after the construction, by using it. I consider the wallet “done” when it satisfies my expectations and meets my quality standards. This means the stitches are solid, the look and feel is aesthetically pleasing, and the snaps work properly.
I can’t call the wallet “done” if the stitching is incomplete or the snaps aren’t riveted. Nor could I consider it done if I haven’t reviewed the quality of the snaps and stitches. Testing does not slow me down — it’s an integral part of the process. Without testing I can’t consider the wallet “done.”
The overall process in software development can be described quite similarly. In simple terms, I decide on the desired functionality, choose the approach of implementation, write the code, and verify if the result provides the desired functionality. I can employ multiple ways of testing — from unit testing to TDD, from automated testing to manual — and I can test before, during, or after the code is written.
Can I call the feature “done” when the backend code hasn’t been written? Of course not. Can I call the feature done if I haven't checked it and verified that it provides the desired functionality? No, because testing is an integral part of the process. Without testing I can’t consider the feature “done.”
If we can’t say that something is done without testing, can we say that testing slows down the production process? I don’t think so. It makes as little sense as saying writing backend code slows things down or stitching the leather slows things down.
Myth variants 2 and 3: QA slows things down or QA is testing
The belief that QA slows things down usually implies the lack of understanding of the very meaning of QA.
Let’s quickly review.
Quality Assurance (QA): All the planned and systematic activities implemented within the quality system that can be demonstrated to provide confidence that a product or service will fulfill requirements for quality.
QA asks: “Are we doing the process right and preventing defects?” It involves preventive activities to design, document, and build quality into processes.
QA measures are systemic and proactive, they all are created and designed to improve the speed and quality of the production process. The speed and quality are tightly coupled: the more defects we have, the slower the process is, due to rework.
A few examples of helpful QA measures would be:
Embrace continuous training
In leathercraft, the better trained I am at stitching, the less defects I make, the less rework occurs, and the faster the process is.
In software development, the better I become at doing system design and architecture, the more flexible the architecture of my software becomes — and the process becomes faster as a result.
Reduce queues and wait time
Imagine in my leathercraft that the cutting and stitching was done by me, but riveting the snaps and finishing the edges was done by another person living somewhere else. In this scenario, I would have to mail each wallet when I finish my part of the work. Each unfinished wallet would then spend time in transit, increasing the overall production time significantly. A QA measure would be to collocate us in a factory so that my colleague could pick up the wallet and proceed immediately after I’m finished with my part. This QA measure would reduce the “wait time” and increase overall production speed.
In software development, parts of work are usually divided between specialists, and quite often unfinished work is waiting for something, such as code review, testing, or integration. A possible QA measure would be to implement ensemble (mob) programming or pair programming, or at least reduce Work-in-progress (WIP) limit to 1, so that more people work on one single feature at a time. This QA measure would make any part of unfinished work wait much less, thus increasing the overall production speed.
Shift testing left
Imagine in my leathercraft that most work was done by me, but the inspection was done by another person only after I’ve completed my part. This means that if a defect occurred during an early part of work, it would only be discovered by the tester much later, when they inspect the whole wallet. A QA measure would be to do inspections throughout the process when each stage of my work is complete. This QA measure would reduce the amount of rework because defects would be found much earlier and the production speed would increase.
In software development, the QA measure of moving testing to the earlier stages in the development lifecycle is called shift-left testing. This QA measure implies we change the way testing is done. This measure significantly reduces rework and speeds up the overall production.
Get rid of KPIs
Imagine that in my leathercraft the inspector would be rewarded for each defect found and logged. This would motivate the inspector to log even the natural leather color variation (which looks gorgeous!) as a defect, and result in unnecessary rework and slowing down of the production process. A QA measure would be to remove the KPI so that the inspector would only be motivated to log actual defects. This QA measure would speed up the production process.
In software development, KPIs are known for increasing turnover, stimulating competition instead of collaboration, and diminishing teamwork. The increased turnover means that new employees are trained to become as fast as those who left. The reduction in collaboration yields loss of quality and speed. The QA measure would be to remove the KPIs so that the people on the teams work better together. This makes the production process faster.
I’ve listed just a few QA measures which will certainly increase production speed and improve quality. You will be able to invent many more if you study TQM, corresponding body of ISO standards (ISO 9000 and ISO 25000) and areas of knowledge needed for QA.
Why is this myth still perpetuated?
We’ve established that QA is not testing (but includes it) and that QA doesn’t slow things down, so why do we still hear about QA being a bottleneck? I believe that it’s not only lack of information, but also that people feel the overall work process is slow.
An engineer might work with a couple of friends on a pet project over the weekend. They choose a feature to create and work as an ensemble (mob). Together they design, code, and test the feature. By Sunday night, the feature is delivered to users.
That very same engineer goes into the office on Monday and is tasked to work with a team on a product feature of similar complexity, but instead of finishing it in a couple of days, the feature is planned for delivery sometime next week.
The manager does not allow the engineer to practice mob or pair programming, so they’ll need a code review stage. This means that both the backend and frontend code will have to wait a day or two for review. Then, if no changes are needed after the code review, the feature will wait for a day to be picked up by testers. Then it will wait to be released the day after — but not on Friday! Friday is a code freeze. I’m not even describing a really bad process here, just an average one.
What can be done very quickly in a well-designed process usually takes ages in an average process. There are studies showing that the more people there are on the team, the slower the overall production process is. The reason is simple: overall poor design of work processes. When more people join the team with poorly designed processes, the overhead grows and the slowness becomes almost tangible.
Then managers start rushing people, imposing deadlines and adding KPIs to motivate people to work harder, but only causing more damage. The proper solution to this mess of problems would be found in the QA toolkit of process improvement.
The end of the myth
Testing is an integral part of production and therefore can’t slow things down, but lack of testing can.
If I sell this wallet with a broken rivet and bad stitching, it will be returned to me. This would mean I wasted leather, accessories, reputation, and time. I would have to redo the wallet from scratch and sell it again, spending more than twice the production time. All of this is due to a lack of testing.
If I had tested the wallet after the production process, I would not sell it in its defective state. Therefore, I would not be spending time and resources on selling, posting, and returning the wallet. I would simply redo the wallet. Testing would save my reputation and time.
With Quality Assurance measures, such as shifting the testing left, I would find the stitching defects much earlier, before even riveting the snap. The amount of rework and wasted time would be much less with this QA measure.
Additionally, if I employed a “continuous learning” QA measure, I would reduce the number of defects in stitching and riveting the snaps. This would save even more time and speed up the overall production process.
While a poorly designed work process can slow things down, neither testing nor QA will do so.
