The user must assign the criteria the software must meet to be deemed acceptable. Ideally, this is included in the software requirement specifications.
In preparation for developing the acceptance criteria, the user should:
1) Acquire full knowledge of the application for which the system is intended
2) Become fully acquainted with the application as it is currently implemented by the user’s organization
3) Understand the risks and benefits of the development methodology that is to be used in correcting the software system
4) Fully understand the consequences of adding new functions to enhance the system.
Acceptance requirements that a system must meet can be divided into following four categories:
1) Functionality Requirements: These requirements relate to the business rules that the system must execute.
2) Performance Requirements: These requirements relate to operational aspects, such as time or resource constraints.
3) Interface Quality Requirements: These requirements relate to connections from one component to another component of processing (e.g., human-machine, machine-module).
4) Overall Software Quality Requirements: These requirements specify limits for factors or attributes such as reliability, testability, correctness, and usability.
The criterion that a requirements document may have no more than five statements with missing information is an example of quantifying the quality factor of completeness. Assessing the criticality of a system is important in determining quantitative acceptance criteria. The user should determine the degree of criticality of the requirements by the above acceptance requirements categories.
By definition, all safety criteria are critical; and by law, certain security requirements are critical.
Some typical factors affecting criticality are:
a) Importance of the system to organization or industry
b) Consequence of failure
c) Complexity of the project
d) Technology risk
e) Complexity of the user environment
Products or pieces of products with critical requirements do not qualify for acceptance if they do not satisfy their acceptance criteria. A product with failed non-critical requirements may qualify for acceptance, depending upon quantitative acceptance criteria for quality factors. Clearly, if a product fails a substantial number of non-critical requirements, the quality of the product is questionable.
The user has the responsibility of ensuring that acceptance criteria contain pass or fail criteria. The acceptance tester should approach testing assuming that the least acceptable corrections have been made; while the developer believes the corrected system is fully acceptable. Similarly, a contract with what could be interpreted as a range of acceptable values could result in a corrected system that might never satisfy the user’s interpretation of the acceptance criteria.
For specific software systems, users must examine their projects’ characteristics and criticality in order to develop expanded lists of acceptance criteria for those software systems. Some of the criteria may change according to the phase of correction for which criteria are being defined. For example, for requirements, the “testability” quality may mean that test cases can be developed automatically.
The user must also establish acceptance criteria for individual elements of a product. These criteria should be the acceptable numeric values or ranges of values. The buyer should compare the established acceptable values against the number of problems presented at acceptance time. For example, if the number of inconsistent requirements exceeds the acceptance criteria, then the requirements document should be rejected. At that time, the established procedures for iteration and change control go into effect.
Acceptance Criteria related Information Required to be Documented by the users:
It should be prepared for each hardware or software project within the overall project, where the acceptance criteria requirements should be listed and uniquely numbered for control purposes.
Criteria - 1: Hardware / Software Project:
Information to be documented: The name of the project being acceptance-tested. This is the name the user or customer calls the project.
Criteria - 2: Number:
Information to be documented: A sequential number identifying acceptance criteria.
Criteria - 3: Acceptance Requirement:
Information to be documented: A user requirement that will be used to determine whether the corrected hardware/software is acceptable.
Criteria - 4: Critical / Non-Critical:
Information to be documented: Indicate whether the acceptance requirement is critical, meaning that it must be met, or non-critical, meaning that it is desirable but not essential.
Criteria - 5: Test Result:
Information to be documented: Indicates after acceptance testing whether the requirement is acceptable or not acceptable, meaning that the project is rejected because it does not meet the requirement.
Criteria - 6: Comments:
Information to be documented: Clarify the criticality of the requirement; or indicate the meaning of the test result rejection. For example: The software cannot be run; or management will make a judgment after acceptance testing as to whether the project can be run.
After defining the acceptance criteria, determine whether meeting the criteria is critical to the success of the system.
Tags: User Acceptance Testing, Software Testing, Quality Assurance
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment