RISK ANALYSIS OF VARIOUS PRODUCTS

Abstract

Projects should follow an integral testing and quality policy, for quality is a mindset, not a feature. Quality as such ought to be an integral part of project management. Looking at project governance, several aspects, among others, play an important role: costs, risks, time and benefits (also referred to as results or - business - value). Although all of these aspects are important, it is worth emphasizing the aspect of risk, especially product risk, since this may help as a steering mechanism. It may help to find the balance between ‘building the right thing’, ‘building the thing right’, and ‘building it fast’. Many projects don’t have unlimited time, money and resources for evaluating the quality of the product. Such constraints in terms of time, money and resources represent constraints on the result to be achieved and therefore often reduced evaluation possibilities of the product risks. As such, it is important to achieve a well considered balance between the investment in money and time on the one hand, and the results to be achieved and the risks covered on the other. The result of the product risk analysis provides the justification for this balance. Based on the insight resulting from the product risk analysis, high risk products can be evaluated more intensively than those representing a lower risk. Be aware that risks and how to cover these risks are directly related tot the acceptance criteria. These acceptance criteria are available in various forms. As a section in a test plan, in the confirmation part of a story card, in a definition of done, etc. There are many approaches on how to determine risks. However in general one could say: these approaches involve analyzing the product to be evaluated with the aim of achieving a joint view - for and with all stakeholders - of (the properties of) the product to be evaluated that represent higher and lower risk levels, such that corresponding measures can be assigned to this view. What measures can be taken in order to cover these analyzed risks is decided when determining the quality strategy. Remember, quality is designed and built in, not tested in! Meaning, from the beginning of the project, everyone should embrace risk and quality thinking. When for instance a requirement is described (e.g. User story, use case) start thinking about possible risks at stake and how to cover these, for instance by executing a fagan inspection. Or when the system architecture is (being) defined, again think about possible risks and how to cover these, for instance by means of a proof of concept. A last example of risk coverage is assigning specific test design techniques in order to cover identified (product) risks. Read more about risk coverage as part of the quality strategy in building block ‘quality strategy’. Too often product risks are seen as important for testing. Nothing could be further from the truth. Product risks deal with the risk for the organisation when the product does not have the expected quality. And organizations are still plagued by projects getting out of hand in terms of both budget and time, owing to software defects during the operation of the developed information systems. (better) testing contributes to the prevention of those kind of defects, but the general idea that the key lies with testing is a persistent misconception. Many analyses of defects show that testers certainly don’t find everything. But even more: it turns out that the cause of defects lies within the development, design and requirements.