ESSENTIAL MANAGEMENT UNDERSTANDINGS

Notes taken from Boris Beizer books:

As a prerequisite to reviewing these understandings please read Classis Testing Mistakes by Brian Marick.
Independence:
Make a clear identification of what constitutes a unit, program, subsystems, system, and any other meaningful levels
in between
At each element level, define who (QA or project) designs the structural tests, who designs the functional tests, who
witnesses what tests, what paperwork must be produced fro that level, and who sees to it that all quality assurance
measures appropriate to that level have been accomplished.
Define QA's role as arbitrator between the buyer and the builder. Define just how far QA can go in taking the buyer's
side. To what extent can QA "blow the whistle" to the buyer without fear of losing job and livelihood?
Define the channels to be used to overrule or force changes in software for every level element from unit to system.
Define the channels of appeal. This is to be complemented with equivalent channels on the project side. The project
leader needs a mechanism to overrule QA, to appeal, and so forth. It must be a two-way street with equal power on
both sides.
Budget:
QA can't live off the dregs. At present, proper software QA takes approximately 20% of the project cost; it will go up
in the future. The money's got to come from someplace. In some applications, that figure could go much higher (e.g.
in nuclear reactor controls) and must be figured as part of the cost. There can be no independent quality assurance
without an independent budget.
Staff and facilities:
QA is staffed much like a programming project except that it requires a higher chare of clerical help because there's
much more documentation to handle. Facilities are similar to programming facilities but may require more
bookcases, files, and conference rooms. Staffing tends to be more senior than programming, and office facilities
should be adjusted accordingly.
Computer Time and Test Facilities:
Just as budget must be allocated, so must computer time and other test facilities. QA needs a fair share, including
good shifts and bad shifts. Typical computer facility usage ranges from 10 to 25% of that used by the programming
staff.
Capital Budget:
Capital expenditures run higher for QA than for a programming group of comparable size. You can't expect an
individual project to pay for generalized test tools - hardware or software. If such tools must be bought or developed
for a specific project, then it's likely that the tool will be useful only on that project or not acquired at all. QA needs a
capital budget to acquire existing test tools, to modify test tools, to create new test tools, or to adapt test tools
developed by a project for more general use. Capital requirement or computer time is also needed for computers to
host cross-reference generators, to maintain test data bases, and so on.
Interaction:
QA's effectiveness and costs are at the mercy of the project to which it is applied. If the software's rotten, then QA's
costs and schedules will escalate. Conversely, don't be surprised if management hears the same story from the
project side(i.e. budget and schedule were destroyed by QA's meddling).