Testify to Others

As much as you may become attached to the defects you find, you may have very little to say directly about whether or not they get fixed. Your precious defects will likely be in the hands of a merciless Change Control Board (CCB). This might go by some other name in your company or project team, but the purpose of this group is to prioritize, supervise, and drive the completion of the most necessary defects to create the best shipping game possible when the project deadline arrives. This implies that defects are easier to get fixed when they are found early in the project than when they are found later. The threat of messing up the rest of the game and missing the shipping deadline will scare many teams away from fixing difficult defects near the end of the project. This is why you want to find the big stuff early!

The CCB generally includes representatives from development, testing, and project management. On a small game team, everyone might get together to go over the bugs. On larger productions , the leads from various groups within the project will meet, along with the project manager and the configuration manager ‚ the person responsible for doing the builds and making sure the game code files are labeled and stored properly in the project folder or other form of code repository. Your defects will be competing with others for the attention of the CCB. The defect type and priority play an important role in this competition. Also, if you were diligent in providing details about how to reproduce the bug and why it is important to fix, your bugs will get more attention.

Different strategies for determining the "final" priority of a defect can produce different results for the same defect. If only a single individual, like the head of the CCB, gets to decide on the priority, then the tendency will be for defects to have a lower average priority (meaning less "severe") than if people with different perspectives, such as producers , designers, developers, and testers, each give a score and the average score is used.

Also keep in mind that if your project has a particular goal or threshold for which kind of defects are allowed to be released in the game, then anything you submit will be under pressure to get de-prioritized below that threshold. This is where amplifying the defect helps you make a stronger case for why something should be considered high priority versus medium, for example.

One of the difficulties some testers have is balancing "ownership" of the defect with knowing when to "let go." You are expected to find stuff and report it. Other people on the project are usually designated to take responsibility for properly processing and repairing the defect. Don't take it personally if your defect doesn't get fixed first, or other people don't get as excited about it as you do.