Risk driven software testing

Skip to main content. Home Risk-Driven Software Testing. Before You Go! Risk-Driven Software Testing. Full Description and Outline. Call to Schedule Call to Schedule. Virtual Classroom. Contact Us. Select a learning mode button Public, Live Virtual, etc.

Related Courses Mobile Application Testing. BDD for Leaders. Performance, Load, and Stress Testing. Apparently not. One of the difficulties or challenges in using Risk-based Testing or Risk-driven Testing is that these terms are both being used already and neither seems to be being used consistently or well.

But Risk-based Testing was the more common term used. This one sounds like how I was describing Risk-based Testing above. Risk-based Testing can be part of the answer if one employs it as it is meant to be. This last definition seems to combine my outlines of both Risk-Based Testing and Risk-driven Testing plus a bit more.

I had not remembered to include the risk-based test lobbying ideas in the above table, though I certainly do this in practice. Looks like a winner of a definition. By changing one word, we can change the underlying meaning that is understood by others, for better or for worse. Will we cause understanding and clarity? Will we cause disagreement or confusion? Who does it help? Will it be just a word of difference or a whole world of difference? I have been previously familiar with these definitions from Cem Kaner and James Bach and this exercise has served to remind me of them.

But because I often see that Risk-based Testing is weakly implemented, I think mostly I use it to better remind myself, and my teams, that we are supposed to be using risk as the impetus for our test activities. This feels like the crux of my real issue: using risk.

Risk identification can be done through risk workshops, checklists, brainstorming, interviewing, Delphi technique, cause and effect diagrams, lessons learnt from previous projects, root cause analysis, contacting domain experts and subject matter experts. Risk Register is a spreadsheet which has a list of identified risks, potential responses, and root causes. It is used to monitor and track the risks both threats and opportunities throughout the life of the project. Risk response strategies can be used to manage positive and negative risks.

Risk breakdown structure plays an important role in risk planning. The Risk Breakdown structure would help in identifying the risk prone areas and helps in effective evaluation and risk monitoring over the course of the project. It helps in providing sufficient time and resources for risk management activities. It also helps in categorizing many sources from which the project risks may arise. Once the list of potential risks has been identified, the next step is to analyze them and to filter the risk based on the significance.

One of the qualitative risk analysis technique is using Risk Matrix covered in the next section. This technique is used to determine the probability and impact of the risk. Based on the analysis, we can decide if the risks require a response. For example, some risks will require a response in the project plan while some require a response in the project monitoring, and some will not require any response at all.

The risk owner is responsible for identifying options to reduce the probability and impact of the assigned risks. Risk mitigation is a risk response method used to lessen the adverse impacts of possible threats.

This can be done by eliminating the risks or reducing them to an acceptable level. Contingency can be described as a possibility of an uncertain event, but the impact is unknown or unpredictable. Risk can appear at any time. QA testers must consequently be able to handle risk in an efficient and timely manner. Tight development schedules not only demand quick attention to risk, but also require timely risk management that ensures effectively-executed solutions to unanticipated issues, preventing a dethroned or delayed project.

For QA, some of the most critical issues may spring from test execution while undertaking a software testing process. The right risk management tools allow QA teams to better prepare for unforeseen circumstances and consequences. Test management tools , often help testers prioritize risks and issues while ensuring that other members are continually aware of the testing situation.

Spreadsheets and charts are insufficient to reduce redundancies, or to specify risk in detail. Risk management specifications can include:. Using test management tools, testers can better handle these risks through collaboration that brings about actionable solutions. Risk mitigation can often be collaborative, with an entire team devoted to creating the list before a project is launched. These risks may also need to be adjusted as the software testing project progresses.

Flexibility here will be essential to ensuring that QA teams can meet and appropriately respond to any situation that may arise for more expedient risk mitigation and limited downtime.

On the other hand, it involves all means available for humans, or in particular, for a risk management entity person, staff and organization. QA teams must in addition handle unanticipated risk. These are most commonly reduced into two issues — the Anticipated Unknowns and the Unanticipated Unknowns. Anticipated unknown risks are circumstances of which the QA team is generally aware, but unaware as to whether the risk will show up in a specific test project or procedure.

This lack of knowledge may be due to ineffective communication with clients and stakeholders. Unanticipated unknown risks are those of which the organization has no awareness. Unanticipated unknown risks commonly occur when new technologies with which the QA team has no experience are introduced into a project.

Software risk planning is crucial to the success of QA testing and the resulting deployment. Set up a testing plan that highlights workflow procedures that contribute towards risk mitigation.

Image Source: Tutorials Point. Success in mitigating software risk stems directly from upfront assessment of project challenges:.