Wednesday, November 21, 2007

QA ACTIVITIES



Planning

Tailoring Quality Assurance

Specific project characteristics and risks influence Quality Assurance needs, and every Quality Assurance plan should be tailored to its project Characteristics that should be considered include mission criticality of the project, schedule and budget, size and complexity of the product to be produced, and size and organizational complexity of the development staff.

The relationship of criticality to QA functions is, as one would expect: the more critical the project, the more significant and formal the Quality Assurance effort must be. However, the relationship of schedule and budget is not as intuitive: the tighter the budget and schedule, the more critical it is to have a well-planned and effective Quality Assurance effort. This does not mean that projects with more resources can afford to be lax, it just means that tight resources increase risks that should be offset by a strong Quality Assurance program.

The projected size of the end product influences the level of Quality Assurance required. A large project requires explicit and detailed standards for all of the products in order to get at least a minimum standard of quality from the varied ideas and experience of many different programmers. In addition, a large project requires significant efforts in testing and other verification activities, which must be established in the QA plan For such a project, a significant and formal Quality Assurance program must be established or risks of poor quality products must be accepted.

On the other hand, a small project may require little formal Quality Assurance, and on a very small one, the Quality Assurance efforts may be left to the programmer involved if adequate informal planning is completed with guidance from the QA department.

Creating the Quality Assurance Plan

The purpose of creating a Quality Assurance plan is to document and specify the activities that will comprise Quality Assurance for a specific project. Using information about the project and a knowledge of the available Quality Assurance resources, the Quality Assurance project lead develops a plan tailored to the project.

An effective Quality Assurance program requires planning and follow-through A Quality Assurance plan cannot simply evolve along with the project. Adequate Quality Assurance planning ensures that all Quality Assurance activities are focused on the unique requirements and risks associated with the project.

The QA project lead should consider the following guidelines when creating a QA Plan:

v Plan QA in conjunction with management and engineering planning, ie, during the project concept and initiation phase

v Phase QA activities properly For example, design standards must be produced well before design is to be done

v Complete tool development or procurement before the tools are needed Especially important are the test tools and test data sources

Creating Test Cases

A test case is a document that describes an input, action, or event and an expected response. A QA engineer or other tester performs the test case scenario to determine if a specific feature of an application is working correctly.

The process of developing test cases can help find problems in the requirements or design of an application since test case development requires thinking through the complete operation of the application. For this reason, it is useful to prepare test cases early in the development cycle.

A test case contains:

v Detailed test set-up instructions

v Detailed test procedure, including all steps or actions

v Expected results and pass/fail criteria

Establishing Standard and Procedures

Establishing standards and procedures for software development is critical, since these provide the framework from which the software evolves Standards, the established criteria to which the software products are compared, and procedures, the established criteria to which the development and control processes are compared, provide the prescribed methods for developing software. The role of QA is to ensure existence and adequacy of standards and procedures.

Proper documentation of standards and procedures is necessary since the QA activities of process monitoring, product evaluation and auditing rely upon unequivocal definitions by which to measure project compliance

v Documentation standards specify form and content for planning and product documentation and provide consistency throughout a project

v Design standards specify the form and content of the design product They provide rules and methods for translating the software requirements into the software design and for representing it in the design documentation

v Documented procedures are explicit steps to be followed in carrying out a process Examples of processes for which procedures are needed are configuration management, nonconformance reporting and corrective action, testing, and formal inspections

Establishing Completion Criteria

Because of the nature of software, it is difficult to ascertain the status of a development or maintenance activity. It is important, therefore, to define criteria for the completion of specific development stages. During the implementation phase, one has to complete the lowest level (most detailed) design of small program elements, code the elements, and unit test them. When a significant number of program elements are involved, it is difficult for anyone to ascertain the status of the units without specific completion criteria. For example, if there is a criterion that detailed design is complete only after the rework that follows a design inspection, then the design can be said to be either complete or incomplete depending on the status of the rework.

The establishment of completion criteria is a management activity, but the audit of status records is an important QA activity. Audits determine the accuracy of the reported status.

Auditing Against Standards and Procedures

A fundamental QA technique is the audit, which looks at a process or a product in depth and compares it to established procedures and standards. Audits are used to review management, technical, and QA processes to provide an indication of the quality and status of the software product.

The purpose of a QA audit is to assure that proper control procedures are being followed, that required documentation is maintained, and that the developer's status reports accurately reflect the status of the activity. The QA deliverable is an audit report to management consisting of findings and recommendations to bring the development into conformance with standards and/or procedures

Monitoring Products and Processes

Product evaluation and process monitoring assure that the software development and control processes described in the project's management plan are correctly carried out and that the project's procedures and standards are followed. Products are monitored for conformance to standards, and processes are monitored for conformance to procedures. Audits are a key technique used to perform product evaluation and process monitoring. Review of the management plan should ensure that appropriate QA approval points are built into these processes.

Ideally, the first products monitored by QA should be the project's standards and procedures. QA assures that clear and achievable standards exist and then evaluates compliance of the software product to the established standards Functional and technical document evaluations follow this assures that the software product reflects the requirements and standards as identified in the management plan.

Verification and Validation Monitoring

QA assures Verification and Validation (V&V) activities by monitoring and participating in product reviews, inspections, and walk-throughs. A review looks at the overall picture of the product being developed to see if it satisfies its requirements. In formal reviews, actual work done is compared with established standards. Reviews are part of the development process, and they should be conducted at the end of each phase of the lifecycle to identify problems and determine whether the interim product meets all applicable requirements. The results of the review should provide a ready/not-ready decision to begin the next phase. Although the decision to proceed is a management decision, QA is responsible for advising management and participating in the decision.