Scalability Rules (Pioneer Panel's Library) by Martin L. Abbott & Michael T. Fisher

Author:Martin L. Abbott & Michael T. Fisher
Language: eng
Format: epub
Publisher: Addison-Wesley Professional
Published: 2011-03-25T16:00:00+00:00

* * *

Rule 28 has an ugly and slightly misleading and controversial title meant to provoke thought and discussion. Of course it makes sense to have a team responsible for testing products to identify defects. The issue is that you shouldn’t rely solely on these teams to identify all your defects anymore than airlines rely on flight attendants for safe landings of their planes. At the heart of this view is one simple fact: You can’t test quality into your system. Testing only identifies issues that you created during development, and as a result it is an identification of value that you destroyed and can recapture. Testing typically only finds mistakes, which often requires rework that in turn increases the marginal cost per unit of work (functionality) delivered. It is rare that testing, or the group that performs it, identifies untapped opportunities that might create additional value.

Don’t get us wrong—QA definitely has an important role in an engineering organization. It is a role that is even more important when companies are growing at an incredibly fast rate and needing to scale their systems. The primary role of QA is to help identify product problems at a lower cost than having engineers perform the same task. Two important derived benefits from this role are to increase engineering velocity and to increase the rate of defect detection.

These benefits are achieved similarly to the fashion in which the industrial revolution reduced the cost of manufacturing and increased the number of units produced. By pipelining the process of engineering and allowing engineers to focus primarily on building products (and of course unit testing them), less time is spent per engineer in the setup and teardown of the testing process. Engineers now have more time per day to focus on building applications for the business. Typically we see both output per hour and output per day increase as a result of this. Cost per unit drops as a result of higher velocity at static cost. Additionally, the headcount cost of a great QA organization typically is lower on a per-head basis than the cost of an engineering organization, which further reduces cost. Finally, as the testing organization is focused and incented to identify defects, they don’t have any psychological conflicts with finding problems within their own code (as many engineers do) or the code of a good engineering friend who sits next to them.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.