Improving the consistency, quality, and relevance of decision making in test
Abstract
Certification needs to ensure that decision-making is accurate and consistent, while ensuring that the team invests time only in issues that offer true value.Introduction
The Certification team makes thousands of decisions every year to determine the seriousness and noncompliance of issues. Making consistent decisions is a challenge in a business that’s both cross-regional and home to several layers of internal assessment, from testers on the floor up through leads, managers, and software engineers. FMA offers a strict framework to enable all who are involved to make key decisions quickly and consistently while saving a significant amount of time by flagging those issues deemed too minor to be fully documented.Overview
FMA provides a framework for assigning three different scores to each issue: severity, probability, and repeatability. The sum of these scores determines the issue type as one of the following types.- Condition for Resubmission (CFR): These issues are serious enough that the title can’t be shipped until the developer fixes the issue in a resubmission, or the issue can be fixed through a Content Update delivered in a specific time frame, often by day one of end-user interaction.
- Standard Reporting Issue (SRI): These issues are serious, but they aren’t severe enough to stop the submission from being published.
- Issue of Note (ION): These SRI issues can’t be mapped directly to an existing test case.
- Severity: Six potential outcomes
- Probability: Six potential outcomes
- Repeatability: Six potential outcomes
The first building block of FMA: Severity
Severity enables you to define how serious an issue is without considering anything outside of the event. FMA analysis breaks down the varying levels of severity into a user-friendly stack. Focusing on Certification’s needs, the following severity warning was produced.
These six potential categories define each issue, from no impact to very high impact. An overall rating exercise created weighted ratings for each category.
The ratings make for a robust part of the framework because it’s relatively straightforward to consistently assign issues to the correct category across multiple individuals. Instead of settling for this approach, we chose to modify the steps per test case to create a system that’s highly user-friendly and able to reflect the idiosyncrasies of specific test cases.
An example is Headset State Change (HSC).
Figure 1. HSC example.

The second building block of FMA: Probability
Definition: Probability enables us to assess how likely an end user is to be potentially exposed to a given issue. We use a similar grid to the one that’s used for Severity but with modifications.
Examples:
- The issue occurs when launching the title. Probability = 8.
- The issue occurs when joining an online session. Probability = 4.
- The issue occurs in one specific submenu within one game mode and doesn’t occur anywhere else. Probability = -3.
The third building block of FMA: Repeatability
Definition: Repeatability shows how likely an end user is to experience a given problem again after the original manifestation. We’ve covered how two values relate to the severity and probability of the problem. You now need to identify the repeatability of the problem. Use a similar grid to the ones that are used for severity and probability but with modifications.
As with Probability, use the frequency values from the test outcome, such as the following values:
Frequency:
Console 1: 5/5
Console 2: 4/5
To calculate the value, sum up the successful reproduction attempts (the first numbers) and divide by the sum of the total number of attempts (the second numbers). Multiply this number by 6 to give the final value. In the example, the calculation looks like this: 9 ÷ 10 x 6 = 5.4, meaning that the final repeatability value is 5.
