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:
- Detailed test set-up instructions.
- Detailed test procedure, including all steps or actions.
- 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.
- Documentation standards specify form and content for planning and product documentation and provide consistency throughout a project.
- 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.
- 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.
9.9
RELATED POST
UNIT TESTING PART ONE
UNIT TESTING PART TWO
UNIT TESTING PART THREE
GUI TESTING
WINDOWS COMPLIANCE GUI TESTING PART ONE
WINDOWS COMPLIANCE GUI TESTING PART TWO
WINDOWS COMPLIANCE GUI TESTING PART THREE
WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING
WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING
WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING
CONDITION TESTING
TESTING CONDITIONS PART ONE
TESTING CONDITIONS PART TWO
TESTING CONDITIONS PART THREE
TESTING CONDITIONS PART FOUR
SPECIFIC FIELD TESTING
USABILITY TESTING
INTEGRATION TESTING
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
No comments:
Post a Comment