2001-10-01: Adrick Analyzes Bug Fixing
Adrick Analyzes Bug Fixing
Oct 1 2001 5:05PM
This was originally posted to Development at uo.com. [1]
One of my main areas of focus is fixing bugs - especially critical ones that affect the entire service. Since bug fixes comprise a huge percentage of the changes we make to UO, I want to take this opportunity to talk a little bit about what goes into fixing a bug and getting the fix live on all the shards. There are several steps to this process, and I’ll go over each one.
1] Identify the bug. This comes in many forms, including GM reports from support calls, QA testers, and player submissions through email or via our boards. The most important part of this step is information – as in what shard, what time, the specific circumstances, etc. Basically, we need as much information as possible that will allow us to reproduce the bug in a development environment. It’s rather an impossible task to fix a bug we can’t reproduce.
2] Reproduce the bug. Using the information obtained in step 1, a designer or a QA tester will attempt to follow a step-by-step procedure to reproduce the bug, which usually leads to a bit more information. Most often, this is done on our standalone servers, which are sort of like mini UO servers running the code branch of our choice. Sometimes, due to the differences between an areaserver (standalone) and full server set (production shards), we have to work on a test center to get the bug reproduced. If it involves crossing server boundaries, then it requires a test center or a production shard.
3] Prioritize the bug. If it’s a legitimate bug, it either needs to be fixed within our normal development cycle, or if it’s much more serious, it needs to be pushed to the front of the cycle. In order to determine priority, a couple of questions need to be asked. Does it affect a majority of the service? Is it an exploit? Is it a crasher (shard or client)? These types of bugs are always fixed as quickly as possible regardless of what else is on the schedule, and the rest are moved into the normal cycle.
4] Assign and fix the bug. For ASAP bugs, we call a meeting to determine what the fix will be, who will be responsible for the fix, and what the timeline will be in order to get it tested and published. Other bugs are assigned to the team members in charge of those areas. Some bugs are fixed by programmers, others are fixed by designers, and some require both design and programming resources.
5] Test the fix. Once we have fixed the bug, it’s published to a test center and given to QA to see if it passes; they test the systems affected and pass or fail it. If it fails, it’s returned to step 4. Once passed by QA, it moves to step 6.
6] Publish the fix. Sometimes it’s to one shard first; other times it goes to all the shards in their normal maintenance schedule.
7] Monitor feedback. The support staff monitors the shards to make sure no side effects happen and that the bug in question is indeed fixed. Our GMs are one of the best sources for feedback because they take the calls and see firsthand what is going on in the game.
I enjoy fixing bugs because, as a player, it was always a source of frustration for me. It is also challenging, because the unique nature of the game causes the systems to affect each other in what seems to be very strange ways at times. Bug fixes aren’t always the most visible changes, but doing it well involves using problem solving skills and close attention to detail. The reward comes from seeing players being able to play the game and not having it ruined by an exploit, or being able to simply enjoy a system in the game when it works as it was designed to.
Pete "Adrick" Warner Designer - UO Live
References:
