When I think about the beginning of our experience with QA, it seems similar to the early stages of the automotive industry. I wasn’t around before Henry Ford introduced the assembly line, but I can imagine what it was like when a person built a single vehicle at a time. I can just imagine a car builder getting half-way through assembling a car and realizing he has no idea if he put the bolts on properly, or getting to the paint stage and realizing that the doors are not flush with the body. It couldn’t have been fun.
In the beginning of our QA timeline, the development staff was responsible for performing their own testing much like that early car builder. Sure, there might be others around who could lend a hand, but they might not have the time or proper skills to test correctly. Each programmer was essentially responsible for assembling the entire task together, mimicking their counterpart at the factory.
What if the factory builder decided to skip a step or relax on some of the guidelines? Who would notice? Who would care?
What if the developer decided to skip a step or relax on some of the guidelines? Who would notice? Who would care?
Obviously, the automotive industry decided this was not an efficient manner to build cars, and the same logic applies to the development industry.
When a development team is expected to move at an accelerated rate, especially during a ramp-up to production, the flow of changes requires everyone to move at the same pace – product, development, QA, etc. By moving more toward a true Kanban style of issue management, this can all be controlled without everyone getting lost or stalled. The issues to be worked are put at the top of the heap, they are taken off by the development staff, worked through to completion, cycled through the QA department, and deployed (or sent back if they do not meet specs); all while keeping the product assembly line humming along.
The benefit of getting the QA department right into the thick of this Kanban style of production is to eliminate the extra time needed at the back-end (the final stop on the assembly line) and to minimizes the delivery of a buggy product to customers. There no longer needs to be a substantial amount of time after development is complete to put everything through the final QA sign-offs; the testing is completed along the way.