A project has never had unlimited time and money to develop. PRA is a vital tool to help testers allocate limited resources. It starts with the risks involved in a particular project or change. We want to do the most testing where the risk is maximum. Product Risk Analysis assists in identifying and estimating those risks. It may consider the system being tested with different ideas, e.g., from a business viewpoint: how does the system fit in the business processes, which features are most valuable, but also from an IT/technical viewpoint: how stable is an installed source code base?
Product Risk Analysis
PRA is valuable for testing all phases of sequential or agile system development. Although interest in PRA is declining, more and more testers are participating in presentations and workshops on PRA and its role in testing IT systems. It shows that PRA is still alive! PRA is dying because PRA results are not used in a project, so it is not valuable to have PRA. To refute this view, we should introduce different applications of PRA, elevating them from the project level to the domain level.
How To Perform a Product Risk Analysis?
The test manager derives the elements suitable for the product risk analysis, such as requirements, designs, or similar documents, from the current information to ensure a good start for the product risk analysis. The elements related to performing a product risk analysis are.
- Process: (The (business) processes and sub-processes supported by the test object.
- Product Requirements: Customer requirements for test objects. If the test subject does not (no longer) support these requirements, there is damage. The organization decides how and at what level of detail product requirements should be developed. Organizations driven by ICT typically adopt user requirements. An organization with a high level of user engagement generally determines the critical success factors.
- Properties: Characteristics that can be evaluated for a product by testing, for example, functionality, performance, and user-friendliness. According to preference, these are in the form of quality characteristics, as it is relatively easy to establish a specific test method. If the concept of quality characteristics is difficult for the participant, the test manager may also use other terms that closely match the participant’s perception.
How Can We Count Damaged Elements?
To understand the damage elements, the test manager creates an overview of each of the procedures and sub-procedures supported by the test object. It results in a structure that the participants can recognize, and the product requirements can be associated with. Product requirements are subdividing processes and sub-processes until all counts are associated with each feature and the correct location of a process or sub-process. An indication of damage (high, medium, low) may be established for each product requirement.
How Can We Count Chances of Failure Elements?
The test manager establishes an overview of the object part for each characteristic to determine the opportunity for failure. These object components together represent the entire test object through their interrelationships. It results in a recognizable structure for the participants, allowing the chance of failure to be determined for each combination of feature and object parts. The segmentation of the object portion continues to a level at which the opportunity for failure (high, medium, low) can be determined.
Verdict
The value and utility of the PRA depend significantly on the participation and commitment of various stakeholders. Testers require a solid understanding of test coverage and testing techniques to translate risk levels into appropriate test designs. Without this information, the PRA output adds a small amount to the effectiveness of the test. The purpose of product risk analysis is to identify high-risk, high profitability, or the most widely used components of a measuring system so that testing resources are allocated appropriately.