SQA tools for corrective maintenance

11.4.1 SQA tools for corrective maintenance

Corrective maintenance activities entail primarily (a) user support services

tw

and (b) software corrections (bug repairs). User support services deal with

are quality

cases of software code and documentation failures, incomplete or vague doc- umentation; they may also involve instruction of users who have insufficient knowledge of the software or fail to use the available documentation. Software correction services – bug repairs and documentation corrections – are called for in cases of software failures, and are typically provided during

ss u

the initial period of operation (despite the efforts invested in testing) and

continue to be required, though in lower frequency. As the two types of serv-

ranc

ice are inherently different, distinctive sets of quality assurance tools are used irrespective of the shared focuses on quality of service. Nonetheless, in many

e tool

cases the same team performs both types of corrective maintenance. In addition to infrastructure and management control SQA tools (dis-

cussed later in this section), most bug repair tasks require the use of mini life cycle SQA tools, mainly mini-testing. Mini-testing procedures are required to handle repair patch (small-scale) tasks, characterized by a small number of coding line changes together with intense pressure to complete the correc- tions rapidly. The implications of delayed repair are such that an abridged – mini – form of testing is often employed. However, use of these mini testing tools should be retained to avoid compromise situations of no testing.

In order to assure “mini testing” quality, these guidelines should be adhered to:

Testing is to be performed by a qualified tester, not by the programmer who carried out the repair.

A testing procedure document (in most cases 2–3 pages long) should be prepared. Included in the document are a description of the anticipated effects of the repair, the scope of corrections and a list of test cases to be activated. A re-testing procedure document, similar to the testing proce- dure document, should be also be prepared to handle testing of repairs of errors detected in previous tests.

A test report fully documenting the errors detected in each stage of test- ing and re-testing should be completed.

The head of the testing team is to review the testing documentation for the scope of corrections, the adequacy of the test cases and the testing

266 results. Responsibility for approval of the repaired software for opera- tional (sometimes termed “production”) use rests with the team’s head.

For repairs considered “simple and trivial”, especially for those per-

As

formed at the customer’s site, mini-testing may be avoided.

suring the quality

Subcontracting (outsourcing) maintenance services, especially user support services, has become quite common whenever it is too troublesome or uneco- nomic for the maintenance contractor to directly provide these services. The main tool to assure the quality of the subcontractor’s maintenance services and pave the way for smooth relations is the contractor–subcontractor contract. The SQA tools integrated into the contract focus on:

of

Procedures for handling a specified range of maintenance calls.

sof

Full documentation of the service procedures.

tw

Availability of records documenting professional certification of the sub-

are m

contractor’s maintenance team members, for contractor review.

Authorization for the contractor to carry out periodic review of the main-

ainten

tenance services as well as customer satisfaction surveys.

Quality-related conditions requiring imposition of penalties and termina-

anc

tion of the subcontracting contract in extreme cases.

ec Once maintenance becomes operative, the contractor should regularly con- omponents

duct the agreed-upon reviews of maintenance service and customer satisfaction surveys.

Implementation tip

Many of the bitter failures experienced with software maintenance contracts are due to subcontracting. Failures often result from lax control over the subcontractor’s performance, not from the absence of software quality assurance clauses from the contract. The reasons for subcontracting, such as a shortage of maintenance professionals at the remotely located customer’s site that consumes the subcontracted services, may induce faulty control over the subcontractor’s services. In other words, successful subcontracting requires adequate organization and procedures to implement proper control over performance.

More about subcontracting may be found in Chapter. 12.