-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy patha-bugs-life.html
175 lines (170 loc) · 15 KB
/
a-bugs-life.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head lang="en">
<title>UnrealWiki: A Bug's Life</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" type="text/css" media="screen, print"
href="shared/stylebase.structural.css">
<link rel="stylesheet" type="text/css" media="screen"
href="shared/template-default.css">
<link rel="stylesheet" type="text/css" media="screen"
href="shared/styles.chblue.css">
<link rel="stylesheet" type="text/css" media="print"
href="shared/template-default-print.css">
<!--[if IE 6]>
<style>
/* dirty hack for IE6. */
#quickbar {
position: absolute;
}
</style>
<![endif]-->
<link rel="start" href="http://wiki.beyondunreal.com/">
<link rel="glossary" href="http://wiki.beyondunreal.com/wiki/Terminology">
<link rel="help" href="http://wiki.beyondunreal.com/wiki/Using_The_Wiki">
<script type="text/javascript" src="shared/dhtml.js"></script>
<script type="text/javascript" src="shared/dhtml-menu.js"></script>
<style type="text/css">#dhtml-menu { background: #eee; padding: 5px 0px; margin-right: -20px; border: 1px solid #888; border-left: 1px solid #ccc; border-top: 1px solid #ccc; border-right: 1px solid #888; border-bottom: 1px solid #888 }
#dhtml-menu td { color: #000; font-family: Arial,Helvetica,sans-serif; font-size: 9pt; line-height: 13pt; padding: 1px 10px; cursor: default }
#dhtml-menu a { color: #000; font-family: Arial,Helvetica,sans-serif; font-size: 9pt; line-height: 13pt; text-decoration: none }
#dhtml-menu tt { font-family: monospace; font-size: 9pt }
#dhtml-menu-separator { height: 1px; background: red }
#dhtml-menu-anchor { cursor: default }
</style>
<script type="text/javascript" src="shared/expandable.js"></script>
</head>
<body onLoad="menuInit(); document.cookie='page=A_Bug's_Life; path=/'" class="default">
<div id="scrolling"><!-- contains all except the fixed sidebar -->
<div id="topbar" class="bar">
<div class="righthalf">
<form class="inline" method="post" action="/wiki" enctype="application/x-www-form-urlencoded"><input type="text" name="search" size="20" /> <input type="submit" name="search" value="search" /></form>
</div>
<div class="lefthalf">
<script type="text/javascript"><!--
menuAlignRight = false;
//--></script>
<span><script type="text/javascript"><!--
menuWriteAnchor("Quick Navigation") //--></script></span> | <a href="(start).html">Home Page</a> | <a href="recent-changes.html">Recent Changes</a> | <a href="http://wiki.beyondunreal.com/wiki?action=editprefs">Preferences</a>
</div>
</div>
<div id="content"><!-- contains the title and article -->
<h1 class='pagetitle'><a href="http://wiki.beyondunreal.com/wiki?back=A Bug's Life">A Bug's Life</a></h1>
<div class="wiki"><blockquote><p><em class="em1">I originally posted this article in our internal Jailbreak testing forums and moved it on the Wiki at a second thought. It's generically phrased, so it should apply to almost every project that's in development.</em></p>
<p><em class="em1">For another and rather entertaining look on the same subject, have a look at <a href="http://www.joelonsoftware.com/articles/fog0000000029.html">[Painless Bug Tracking]</a> by Joel Spolsky. One of the most important things Joel has to teach to us techies is that you have to make documents </em>fun to read<em class="em1"> to get people to actually read them.</em></p>
</blockquote><p>Instead of listing a set of rules how bug reports should be posted, I'm going to describe <em class="em2">A Bug's Life</em> here. After all, all rules I could possibly post boil down to a certain understanding of which information is necessary (and why) in order to squish a bug.</p>
<h2><a name="0.1"></a>What's a Bug?</h2>
<p>First off, whether something is a bug is a mere matter of definition. That fragged players get respawned in jail is a distinct feature of Jailbreak, but for common Deathmatch it'd be a bug. (Yes, that's a bit far-fetched, but you get the idea.) Generally speaking, <em class="em2">if a program behaves in a way the developer intended it not to, that's a bug.</em></p>
<p>There are a number of things where you can safely assume that a developer did not intend them to happen:</p>
<ul><li><em class="em2">Crashes.</em></li>
<li>Things that <em class="em2">obviously disagree with existing documentation.</em> – That could just as well be an error in the documentation, but that'd be a bug in its own right.</li>
<li>Things that are <em class="em2">needlessly inconvenient</em> for the user. – On the other hand, they could also be <em class="em1">necessarily</em> inconvenient for the user, but then that should be made obvious to prevent frustration on the users' part. Have a look at the <a href="mychaeel-modding-etiquette.html">Modding Etiquette</a> about that.</li>
</ul>
<p>If you find such a thing, post a bug report. If you find something where you're not sure whether it's a bug or intentional behavior, ask the developer; chances are that it is a bug anyway, and if it's not it should at least be changed to make that clear.</p>
<h2><a name="0.2"></a>A Bug's Life Phases</h2>
<p>After this short intro to what a bug is, let's have a look at the bug's life.</p>
<ol><li><em class="em2">A bug is born</em> somewhere on the way between the developer's brain and the fingers typing the code.<ul><li>Sometimes a bug's cause is as simple as a typo in the code (when the coder lacks coffee, or sleep, or both, or had too much coffee, or something like that).</li>
<li>Sometimes a coder <em class="em1">thought</em> she'd understood a particular piece of code, and how she could get her own code to work with it effectively. Unfortunately she is subtly mistaken (which could even be due to another bug in that existing code which naturally isn't documented anywhere).</li>
<li>Sometimes one part of her own code puts the program in a state some other part of her own code doesn't expect and handle; that's the most annoying and most avoidable kind of bug for a decent programmer.</li>
</ul>
</li>
<li>Now that the bug has crept into the code, it stays there until <em class="em2">it is discovered</em> by chance by somebody. More often than not that's in the middle of a complex situation that is impossible to reproduce in every detail, and the next time the program is executed and the situation is slightly different, the bug manages to hide again.</li>
<li>But the bug's days are numbered since its existence has been given away already. Of course, just like with real-life bugs, the coder needs to <em class="em2">see the bug in order to fix it.</em> So the bug hunter tries to recall as much as possible of the situation that caused the bug to appear the first time and the events preceding it and then successively <em class="em2">strips it of everything unnecessary.</em> Ideally the bug hunter ends this process with a short and simple list of steps that reliably lead to the bug showing itself.</li>
<li>Now it's the coder's turn to <em class="em2">squish the bug.</em> She traces the program's execution from the start until she finds the point where a piece of code doesn't change the program's state as she meant it to. Then she tries to trace the program's flow <em class="em1">back</em> to the cause of that behavior. She changes it, and the bug is <em class="em2">fixed.</em></li>
</ol>
<h2><a name="0.3"></a>Bug Hunters</h2>
<p>You, as bug hunters, are responsible for the <em class="em2">second and third phase</em> in a bug's hopefully short lifespan.</p>
<p>Just discovering the bug by chance is not enough; given that there are more bug hunters than developers working on a project, leaving the third step up to the developers is a big waste of project time.</p>
<p>Imagine a small project with one coder and three testers. For the sake of the argument, let's assume that the third phase (reproduction) takes one hour per bug, and the fourth phase (fixing) half an hour (which may or may not be way off in either direction depending on the bug). Let's also assume that every tester discovers a single distinct bug.</p>
<ul><li>If all testers stop working at the second phase (discovery) and let the developer handle the third and fourth phase (reproduction and fixing), we have: a single coder working one and a half hours on each of three bugs, resulting in <em class="em2">four and a half hours of work.</em></li>
<li>If all testers continue working until the third phase is completed (discovery and reproduction) and then let the developer fix the bug, we have: three bug hunters working in parallel on three bugs for one hour, then the developer fixing each of the three bugs for half an hour each, resulting in <em class="em2">two and a half hours of work.</em></li>
</ul>
<p>Do you notice how the second way to do it actually saves two hours of development time in this example?</p>
<h2><a name="0.4"></a>Reporting Bugs</h2>
<p>When you report a bug, include all information that's necessary for the developers to reliably reproduce it. And just as important: Leave unnecessary information away.</p>
<p>Things every bug report should contain in some way or another:</p>
<ul><li>A brief, but descriptive <em class="em2">bug report subject</em> (a thread subject if you post it in a forum, for instance) for your bug report that clearly summarizes the reported bug. As a rule of thumb, a descriptive subject always <em class="em2">contains at a verb.</em> The program <em class="em1">does</em> something wrong after all.</li>
<li>A thorough, but to-the-point <em class="em2">description of the buggy behavior,</em> including a short description of how you <em class="em1">expect</em> the program to behave instead. Screenshots, logs and the like <em class="em1">can</em> be helpful there.</li>
<li>A thorough, but to-the-point <em class="em2">description of how to reproduce the buggy behavior</em> which you worked out in the third phase of a bug's life as described above.</li>
<li>The <em class="em2">revision of the program</em> you're reporting the bug for.</li>
<li>An up-to-date <em class="em2">description of your system</em> (hardware, operating system version and patch level, drivers, and so on). You don't have to repeat the same information over and over again, of course, but the developers should always be able to look it up if they need to. (For example, the developers could ask all testers to submit their system specs at the start of the testing period.)</li>
</ul>
<h2><a name="0.5"></a>Comments</h2>
<p><em class="em2">Mychaeel:</em> I originally posted that in the internal "Jailbreak Testing" forum, but knowing the Wiki as a great sounding board for articles like this one I decided to move it here and link it from our testing forum instead. Comments are appreciated.</p>
<p><em class="em2">EntropicLqd:</em> Nice article. Is it worth mentioning that the number of bugs in any software system generally decays exponentially? How about adding a suggested set of minimum information that should be submitted with a bug report (game version, mod version, log files, screen shots if applicable etc).</p>
<p><em class="em2">Mychaeel:</em> I expressly did not want to give a minimum set of information to post with a bug report in terms of "map name, log, screen shots" and so on. It only leads people to ticking those points off one by one without thinking about whether they're actually giving the developers helpful information or not.</p>
<p><em class="em2">Tarquin:</em> That's sort of ... zen <img alt=":D" src="emoticons/biggrin.gif" align="middle"> </p>
<p><em class="em2">Piglet:</em> Hmm. Good and intresting section, however you have seemed to have neglected the 'immediatly obvious' type of bug. Which are generally more common (at least in the programming that i do). Not a big complaint, just a minor point.</p>
<p><em class="em2">Mychaeel:</em> Hmm. The really obvious things should actually never get into testing; and I would rather not tempt testers to skip bug research by simply claiming that it's "obvious." My stance is that, if a bug was obvious, it wouldn't be there for others to find in the first place. I assume that programmers do a minimum amount of testing themselves before releasing a piece of software to anyone.</p>
<script type="text/javascript"><!--
menuItemAdd("What's a Bug?", "#0.1");
menuItemAdd("A Bug's Life Phases", "#0.2");
menuItemAdd("Bug Hunters", "#0.3");
menuItemAdd("Reporting Bugs", "#0.4");
menuItemAdd("Comments", "#0.5");
menuWrite() //--></script></div>
</div>
<div id="footer" class="bar">
<p><form method="post" action="http://wiki.beyondunreal.com/wiki" enctype="application/x-www-form-urlencoded">
<a href="(start).html">Home Page</a> | <a href="recent-changes.html">Recent Changes</a> | <a href="http://wiki.beyondunreal.com/wiki?action=editprefs">Preferences</a><br>
<a href="http://wiki.beyondunreal.com/wiki?action=edit&id=A_Bug's_Life">Edit text of this page</a> | <a href="http://wiki.beyondunreal.com/wiki?action=history&id=A_Bug's_Life">View other revisions</a><br>Last edited July 6, 2006 19:36 <a href="http://wiki.beyondunreal.com/wiki?action=browse&diff=1&id=A_Bug's_Life">(diff)</a><br>Search: <input type="text" name="search" size="20" /><input type="hidden" name="dosearch" value="1" /><br><br><small><a href="http://wiki.beyondunreal.com/wiki/A_Bug's_Life">Original page</a> – copy created Sat, Jun 23, 2007</small><div></div>
</form>
</p>
<p>I don't need to test my programs. I have an error-correcting modem.
</p>
</div>
</div><!-- close of "scrolling" div -->
<div id="quickbar">
<div id="logo"><a href="http://wiki.beyondunreal.com/"><img src="shared/wikilogo.jpg" width="143" height="100" border="0"></a>
</div>
<div class="qbsitename">
<p>The Unreal Engine Documentation Site</p>
</div>
<div class="qbsection">
<p><a href="metatopics.html">Wiki Community</a></p>
<p><a href="category-category.html">Topic Categories</a></p>
<p><a href="/cgi-bin/imageupload.cgi/wiki-ext/imageupload.htt" target="_blank ">Image Uploads</a></p>
<p><a href="http://wiki.beyondunreal.com/wiki?action=random">Random Page</a></p>
<p><a href="recent-changes.html">Recent Changes</a></p>
<p><a href="offline-wiki.html">Offline Wiki</a></p>
</div><div class="qbsection">
<p><a href="unreal-engine.html">Unreal Engine</a></p>
<p><a href="console-commands.html">Console Commands</a></p>
<p><a href="terminology.html">Terminology</a></p>
<p><a href="category-faq.html">FAQs</a></p>
<p><a href="help-desk.html">Help Desk</a></p>
</div><div class="qbsection">
<p><a href="topics-on-mapping.html">Mapping Topics</a></p>
<p><a href="mapping-lessons.html">Mapping Lessons</a></p>
<p><a href="unrealed-3.html">UnrealEd Interface</a></p>
</div><div class="qbsection">
<p><a href="unrealscript.html">UnrealScript Topics</a></p>
<p><a href="unrealscript-lessons.html">UnrealScript Lessons</a></p>
<p><a href="making-mods.html">Making Mods</a></p>
<p><a href="class-tree.html">Class Tree</a></p>
</div><div class="qbsection">
<p><a href="topics-on-modeling.html">Modeling Topics</a></p>
</div><div class="qbsection">
<p><a href="chongqing-page.html">Chongqing Page</a></p>
<p><a href="log-in.html">Log In</a></p></div>
</div>
</body></html>