Rajnish Mehta writes that test teams need to have a scientific way to support the business need of shipping a product out the door. Risk-based testing is a practical approach for test teams to utilize as it allows them to think from a business perspective.
Web analytics can help you deduce, reduce, and prioritize your testing efforts. Learn how to gather and use qualitative and quantitative information about your users and the risks that can threaten your software's success.
Whether you are involved in a traditional V-model environment or applying agile development methodologies, setting testing priorities is always an issue. From practical experience in various domains (e.g., embedded, medical, automotive, banking, and logistics), Erik shares ten essential lessons learned regarding risk-based testing.
Software testing is often motivated by risk. If you accept this premise, you might well wonder how the term "risk-based testing" is not merely redundant. However, conducting a heuristic risk analysis by employing a checklist of open-ended questions, suggestions, or guidewords is a proven approach to help you find the most important risks for developing your testing plans.
Ensuring the effectiveness of software testing efforts can require expert assessment and management. In this interview, George Wilkinson uses his more than twenty years of experience in the QA and testing fields to explain how risk-based testing can increase effectiveness, focus, and communication.
Faced with the reality of tight deadlines and limited resources, many software delivery teams turn to risk-based test planning to ensure that the most critical components of the software are production ready. Although this strategy can prove effective, it is only as good as your underlying risk analysis. Unfortunately, understanding where risk lies within a product is difficult with the analysis often resulting in little more than an “educated guess.” These risk-based testing exercises can lead to uneven test coverage and the uneasy feeling that the team has neglected to test what is really important. Dan Craig describes how to employ system usage patterns and production defect reports to identify the real risks in a system.
Testing information systems should be based on the business risks to the organization using these information systems. In practice, test managers often take an intuitive approach to test coverage for risks. In this double-track presentation, discover how a "stepwise" definition of test strategy can be used for any test level as well as the overall strategy-providing better insight and a sound basis for negotiating testing depth.
Anne Campbell provides insight into how a risk analysis grid was effectively implemented at IDX as a device to gauge QA team performance and as a communication tool to the development team. This valuable tool listed functionality and the risk associated with it, helping IDX focus their testing in higher risk areas. Discover how a risk analysis matrix can be used to plan your testing efforts and increase the quality of your software project.
It's impossible to test everything-even in the most trivial of systems. Tight time schedules and shortages of trained testing personnel exacerbate this problem; so do changing priorities, feature creep, and loss of resources. In many companies, test professionals either begin their work on whichever components they encounter first, or the parts they're most familiar with. Unfortunately, these approaches may result in the delivery of a system where the most critical components remain untested. Or, at the very least, critical components are tested later in the lifecycle when there may not be time to fix the problems found. All of this adds to the risk of a project. One way to overcome every one of these challenges is to employ the use of risk analysis. Rick Craig demonstrates the basics of a usable process for assigning testing priorities based on relative risk.