Database Reference
In-Depth Information
Easy bugs are usually caused by a coding error or a programmer's misunderstanding
of a requirement. The symptoms are obvious, the root cause is simple to find, and the
fix is almost trivial: for example, changing a plus sign to a minus sign or reorganizing
an
IF
statement in the code. Easy bugs are usually found early in the product's devel-
opment cycle and are, in general, caught by the programmers or testers. However, easy
bugs must be recorded and reported so that improvements can be made to the coding
process; a large number of easy bugs can turn out to be surprisingly expensive.
Hard bugs are, well, hard. They can be caused by design flaws anywhere in the sys-
tem, subtle interactions between software systems, subtle interactions between software
and hardware, and awkward interactions between users and the GUI. Hard bugs can
have their own lifecycle, and the fix might be spread over several product releases.
Team Development's Bugs and To Dos modules can be used together to track a hard
bug's resolution, even when it spans several product releases.
The Bugs module highlights how you can take advantage of Team Development's
simplicity, extensibility, and flexibility. Simplicity makes tracking easy bugs almost
trivial. A bug is found, and everything about the bug is recorded in Team Develop-
ment's Bugs module, including the
what
,
who
, and
when
data. Easy bugs can stand on
their own, or you can associate them with a to-do depending on how you organize your
Team Development environment.
Extensibility and flexibility come into play when you deal with hard bugs that may
take an extended time to fix and possibly require effort from several developers or
teams. Team Development can handle this situation by linking a hard bug to a to-do
(see
Figure 15-17
). The linked to-do is then set up as the parent of several child to-dos
that are used to track the tasks required for the fix.
Figure 15-17.
Linking a hard bug to a parent to-do
Feedback
Team Development's Feedback module is an APEX “sweet spot.” Even if your team
chooses not to use Team Development to manage its software development efforts, you
