In many companies, software quality assurance is considered synonymous with software integration and system testing. This is quite erroneous. Although testing is part of the quality assurance process, it is, arguably, one of the less important parts. The philosophical rationale behind this assertion is that quality must be built in to the system and ensured throughout the entire project lifecycle. If done perfectly, there would be no need to test software at the end of the development cycle, since it would have no defects by that stage. Of course, flawless software systems remain more of a dream than a reality. Hence, practically speaking, testing is an indispensable part of the quality assurance process.

The purpose of software quality assurance is to ensure that:

- all project activities are occurring according to plan
- all plans and project activities are consistent with defined processes
- all processes, activities, and software products comply with applicable standards
- software products satisfy the needs of the customer.

Ideally, a software quality assurance organization exists independent of your project. This group represents the interests of executive management and should be double-checking the activities and products associated with your project. This includes checking on your management artifacts as well as your execution of, and adherence to, defined planning and management processes.

When properly implemented, software quality assurance performs a critical support function by helping you detect and resolve problems at the earliest opportunity. Of course, you are detecting and resolving problems as a routine, daily part of your management activities. However, anything that software quality assurance finds is something that has either been undetected by you or something for which your resolution actions have not yet been effective. In either event, this is very important information for you to know.

In the absence of an external, independent quality assurance function, you will need to implement these actions internally on your project. Your approach should be similar to the approach used for software configuration management. That is, the areas you need to address include:

- Who has responsibility for software quality assurance?
- What process will they follow?
- What tools will they use?
- Do they need any additional training?
- Who will double-check their work?

As a project manager, if you decide to perform the software quality assurance activities yourself, by definition, there will be no protection at the management level of the project. No one will be performing the software quality assurance function on the management activities you perform or the plans and other project artifacts you produce. Considering the importance of successful management activities and products, not having a doublecheck process at your level is highly risky.

With regard to who will double-check the quality assurance process, this is the classic problem of who polices the police. Certainly not the software project manager. Anything you do to monitor software quality assurance internal to your project is essentially a routine part of your management tracking and oversight responsibilities. The oversight you do as a manager is the initial checking process, not the doublechecking process. One option is to bring in an external person occasionally to investigate the plans, procedures, and activities associated with software quality assurance.

Additionally, from one perspective, you can think of the software integration and system testing process as part of your double-check on the software quality assurance organization. In principle, effective software quality assurance will translate into comparatively fewer defects found during postdevelopment testing.

Popularity: 29% [?]

Related Content

'

Subscribe to the post comments feeds or Leave a trackback