The term software assurance is used to describe the belief that testing software is to assure software is production...
ready or to assure that software is in good working form. The question then becomes, how can we assure software is ready? Risk assessments are one technique.
Risk assessments are a technique where you and perhaps a team of people outline potential issues. Once you identify potential issues, the next step is to build a mitigation plan to address those potential issues. Mitigations might include having tech support ready or building information into a help system to walk customers through the issue. Mitigations don't have to be software solutions. The key behind risk assessments and mitigation plans is anticipating and planning.
Let me use an example because definitions can be hard to follow without some type of context. Let's suppose you're testing a contact management system that includes a feature that allows users to import contacts from Microsoft Outlook. Imagine that Office 2007 has been released to the market for over a year or some extended period of time and your company decides to stop supporting the import of contacts from Office 2003. Imagine too that somehow the older version of the software has different field mappings and that by not supporting the older version, customers will not be able to use the import feature.
A risk assessment might determine customers are still importing contact data from the older version of Microsoft Outlook. You might determine a mitigation strategy to provide customers with several hours of free tech support to help them through an alternate import path for their data. In other words, you anticipate the risk; you determine that since only a few customers have not upgraded their software that it might not be worth the labor to address the problem by extending your contact management software to handle the older version, so instead you mitigate the risk by providing customers with an alternate import strategy. Additionally, your company could contact these customers in advance of the software release and ease the problem by anticipating the issue and reaching out to their customer base. Mitigation is about planning an array of solutions to address anticipated problems. In this example, an alternate import strategy might be built. Formalized risk assessment and mitigation planning might be addressed through a process known as an FMEA. FMEA is an abbreviation of Failure Mode and Effects Analysis.
FMEAs can be quite fun to participate in because a whole team may be pulled together to brainstorm ideas and plan. The concept of bringing multiple people from a team from different backgrounds such as database administrators, developers, project managers, software testers, and network administrators to discuss potential failures can be enlightening as you gain perspectives from different disciplines. As a software tester it can be educational and comforting to feel that your team has brainstormed together and is prepared to support the software in production.
Dig Deeper on Topics Archive
Related Q&A from Karen N. Johnson
User acceptance testing and system integration testing differ in one key way: the person who does the testing. Learn when to apply UAT vs. SIT. Continue Reading
Database testing can refer to any backend or data-related testing such as data migrations and data integrity. In this expert response, Karen Johnson ... Continue Reading
Understanding the nuances between different types of test efforts can be a challenge. In this expert response, Karen Johnson explains what is meant ... Continue Reading