DZone
DevOps Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > DevOps Zone > The Most Common Mistake in the Bug Life Cycle

The Most Common Mistake in the Bug Life Cycle

Although bugs can never be 100% preventable and software will never be 100% bug-free, there are good practices that teams can adopt so that bugs in software live for only a brief amount of time and never get around to multiplying.

Federico Toledo user avatar by
Federico Toledo
·
Jun. 17, 16 · DevOps Zone · Opinion
Like (4)
Save
Tweet
2.85K Views

Join the DZone community and get the full member experience.

Join For Free

The bug (or creature on Earth for that matter) with one of the shortest life cycles is the Mayfly, who, after transitioning into the adult stage of its lifespan, typically reproduces and then dies within just 30 minutes. What if bugs in software were born and eliminated that quickly and easily! When testers and developers work together effectively, the period of time from a bug’s creation to its elimination in software is minimal. 

Although bugs can never be 100% preventable and software will never be 100% bug-free, there are good practices that teams can adopt so that bugs in software live for only a brief amount of time and never get around to multiplying. A good incident management system helps to ensure that most bugs are found and fixed well before going into production.

Flujo_Ciclo de vida de un bug_new-02Thanks to Giulliana and Ayessa for designing this awesome graphic!

This is a basic sketch that sums up one of the possible ways to represent the bug life cycle that I talked about in my new functional test automation ebook. There could actually be a thousand different variations of the bug life cycle based on the size of the team, the organizational structure, etc. but, for us, this cycle is basically law!

Where Incident Management Can Go Wrong

One of the most typical mistakes in bug management that the team at Abstracta has seen from working with different companies throughout the years across traditional and agile environments happens when a bug is fixed and the developer marks it as closed. After the bug is closed, we must not forget to double check incidents! First, the tester reports it and then the developer fixes it, but the person who should ultimately determine if it has been resolved is the tester that reported it in the first place. What if the developer thinks it’s gone, but upon further testing, it is still there? What if a new bug has been created? A tester should always go back and check that the bug no longer exists in order to minimize risk. 

Variations of the Bug Life Cycle

There are several other valid variations of this scheme. For example, you may have someone who has the responsibility of revising the incidents that come in and deciding which ones to fix and which ones not to. This situation could work within the flow above, whether it be the tester or the developer who marks a bug as “resolved,” “won’t fix,” or through a dialogue (via the tool or a different medium), both the tester and developer could decide together what is the appropriate decision, showing mutual agreement between the two. In another scheme, you may want to add when to re-open an incident and what happens once it is re-opened. Or, an old bug would simply appear as a new one and start the lifecycle all over again.

Incident management is a basic indicator of the efficiency of a development team and it is additionally a key area where you can see if testers and developers feel like they are a part of the same team or not. Both sides need to do their part to work as a team. It’s not just developers who need to work on collaborating with testers, but also testers need to not complain when bugs aren’t resolved and instead share a global vision focused on the objectives of the whole team while understanding that there’s no fixing everything.

I’d love to hear your comments regarding the bug life cycle and if you follow a similar scheme or another that is more useful or appropriate for you, the typical problems you face, etc. 

agile Incident management dev

Published at DZone with permission of Federico Toledo, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • CSS Position: Relative vs Position Absolute
  • How the TypeScript ReturnType Works
  • Functional vs. Non-Functional Requirements: The Full Guide, Definitions, and Technical Examples
  • Cypress: The Future of Test Automation! Advantages and Disadvantages

Comments

DevOps Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo