What Bug Reports Should Include

Một phần của tài liệu Game Development for iOS with Unity3D 2012 (Trang 44 - 49)

Try to keep in the back of your mind that QA testers play an important part in mak- ing a better end product. If they don’t find the issues, your customers almost certainly will—and I know which one I would rather have. Thanks, QA guys!

1.21 What Bug Reports Should Include

To be a good tester or QA Lead, you must be sure to log bugs that are reproducible and include steps to reproduce the bug reliably. Often when a bug is logged without repro steps (steps to reproducibility), the developers will either have to spend a great deal of time trying to make it happen again (wasting precious development time) or choose to ignore it. Since development time is often limited, the latter is usually the case. Bug re- ports containing statements such as “It’s broken,” “It crashed,” or “This doesn’t work” are completely useless and frustrating for anyone working on the project. They don’t help and they don’t make anyone feel good about it. Repro steps need to include as much detail as possible as to how to repeat the issue not just what it is, for example:

Start the game normally.

Walk to the end of level 1, near the level exit.

Walk to the vending machine on the right.

Try to push the vending machine towards a wall.

Notice that the vending machine goes through the wall a little.

It is helpful to include a little write up as to what the expected behavior should be, for example:

Expected Behavior

The vending machine should not clip through the walls.

If it proves difficult to explain with text, a screenshot or a video clip can often speak a thousand words. Additional media is particularly helpful when dealing with graphical or collision issues. Describing a location within an environment can sometimes be diffi- cult to do with words, and in those situations, the tester should provide video or images.

1.21.1 Organizing Your Bug Reports

On smaller projects, you may be able to get by by simply emailing bug descriptions to the project manager or lead developer. If this is the case for you, I would recommend at the very least copying reports out of the emails and into some kind of task list, or at least into a separate document so that you can monitor them and keep tabs on what has been fixed. It is easy to lose track of or miss emails, so keep a close eye on your bug list and be sure to remove fixed items as you go.

Emailed bug reports can easily get out of control. When you receive multiple re- ports of the same issue, or when a single email contains five or more reports in one, it

becomes easier to lose track. If you anticipate a situation like this or you find yourself beginning to slip, then it may be time to look at some of the tools of the professionals.

Professional issue- or bug-tracking software such as Mantis (Figure 1.3) or Bugzilla of- fer more than just the ability to store and retrieve information about bugs. Categoriza- tion, tester communication, regression, and task assignment management are just some of the features you would find in a typical bug tracker.

1.21.2 Categorizing and Prioritizing Bug Reports

Setting up categories for your bugs will be an important aspect of your testing cycles.

For a start, bug categories may often be used as a pointer for a particular department or developer to pick up on. For example, perhaps your project has an audio category that is handled by a specific audio engineer.

As the team searches through the bug database looking for the next bug to fix, what they spend their time on will also usually be dictated by the category of bug they are looking for. Effective testing not only means finding and describing faults, but catego- rizing and prioritizing them in a way that is in the best interest of the project, saving as much time as possible.

With the exception of bugs that cause the game to crash completely, many of the problems that seem important to the testers may be trivial to the actual success of the project. Consider a tester who sees a minor collision fault that causes a visual prob- lem, such as two 3D models clipping into each other. To a tester who is more focused on the visuals, it may be vitally important that an issue like this gets fixed. In the eyes of the programmers, on the other hand, a bug that freezes the game will be of a much higher priority and will be more likely to get fixed before any visual problems (and rightly so).

Figure 1.3. Mantis bug tracker.

1.21. What Bug Reports Should Include 29

You should try to keep categorizations down to as few choices as possible. If you have dedicated programmers, 2D designers, 3D designers, and sound engineers, you should base categorizations around those departments and the most common tasks within them (such as 3D modeling, GUI, HUD, music, sound effects, etc.). Project workers coming into the bug tracker will be able to quickly see which bugs are related to their work without having to read through individual reports.

Prioritization is always tricky, depending on your project lead. It’s especially tricky if you have a client who is actively involved in the production process, as everyone on the team will have their own particular bias or requirements based on their skill sets and their own interests. For example, a client may be obsessed with problems with the visual aspect of a sponsor’s logo, whereas a sound engineer may be biased toward the way the music fades out. That is why it is so important to try and set out solid rules for QA early on that are based on the overall interests of the project (rather than any of the individual disciplines that go to make it).

Here is an example of prioritizations:

y Crash (level 1—the highest level of bug). Crash bugs trump any other type of problem. All other bugs are considered secondary until the crash bug is elimi- nated.

y Freeze (level 1). Freezes are as problematic as crash bugs because they impede any further progress through the game. A freeze is generally caused by some- thing different to a crash, so they should be categorized differently to help pro- grammers understand the issue and get to it quicker. If you are going to be gen- erating reports based on types of bugs at the end of the project, it is important to separate the two types.

1.21.3 Other Game Breakers (Level 1)

Major game breakers are at the highest level of priority. This includes anything that truly stops the project from launching, such as a failing control system, a screen black- out, unacceptable loading times, or anything that would mean that Apple would reject the game during the review phase.

1.21.4 Sticky Collision Faults (Level 2)

Sticky bugs are where the character becomes stuck in the environment and cannot move. This is usually caused by collision problems that, in many cases, may be an issue for 3D artists when they provide collision meshes within the model files. Since this im- pedes further progress for the user, it has to be highly prioritized.

There is no set time for when testing starts, and there are strong arguments for starting to test both early and late in the production cycle.

1.21.5 Collision Problems (Levels 3+)

Collision problems may often be as trivial as some minor clipping between 3D models, or as devastating as dropping the character through the environment to its untimely death.

1.21.6 Audio, Visual, or Other Problems (Levels 3+)

Aesthetics are important in making a good game, but they are secondary to finishing a game. Get all of the game breakers out of the way before looking at anything else.

C h A P T E R 2

Getting Set Up for iOS Development

T he best part about iOS development is the relatively low cost of entry versus the potential returns. You have to bear in mind, however, that you will need some specific hardware and software to begin with. If you are used to PC development, it’s time to get used to the command key and some funky mouse action—iOS is a strictly non-PC zone. Apple has made it so that you must use a Mac for iOS development. That doesn’t mean you can’t develop games in Unity and then transfer them over to a Mac for publishing, but you will need a Mac to build to the device, test with the device, or publish to the iTunes Store.

For many, this may mean the purchase of a Mac. Prior to building iOS games, I had only ever used a Mac during the early 1990s for desktop publishing, and the thought of shelling out my hard-earned cash for something I had little or no understanding of was quite daunting, to say the least. Having suffered a lay off from a job in the games indus- try, I wasn’t exactly down with the idea of spending a huge chunk of cash on a gamble for iOS, so I opted for the cheap and cheerful route (a low-end, used system) until I actually started making enough money to buy something more powerful.

The great news is that you don’t need a brand new Mac to be able to develop for iOS. A three- or four-year-old system, as long as it is Intel-based, will in most cases be powerful enough to accomplish what we need, as iOS (in terms of processing power or graphical complexity) is still quite limited compared to what we are used to seeing on our desktop computers. As long as your Intel-based Mac graphics card is capable of rendering 3D, and as long as you meet Unity iOS minimum specs, the nature of iOS development is such that you don’t need to spend a fortune. One hiccup may be the operating system, however. Make sure that you can do everything you need on the OS

Một phần của tài liệu Game Development for iOS with Unity3D 2012 (Trang 44 - 49)

Tải bản đầy đủ (PDF)

(278 trang)