Bug Life Cycle

Mariana Yañez
3 min readJan 4, 2021

Hello readers!!✨👋🏼 I’m an intern in a software development company, and this last week I had an evaluation interview where one of the questions was: “Do you know what a bug life cycle is?” and to be honest I didn’t know. So I decided to research a little about it and share what I found. 🐞

As you can see in some of my posts I was working the last weeks with open-source trying to fix bugs, and it concerned me that I couldn’t answer that question even if I were working with it.

What’s a bug?

A bug is an error in an application that limits the normal flow of an application when the application is doing a different behavior from the expected. The bug occurs when a mistake is made by a developer during the building of an application and the flaw is founded by a tester.

What does each step means?

Photo by Guru 99
  • New: When a new flaw/bug is recorded for the first time is set as NEW.
  • Assigned: Once the tester posts the bug, they wait for the approval and assignment to a developer.
  • Open: The dev starts analyzing and working on the bug fix.
  • Fixed: The status changes when the dev changes the necessary code and verifies it.
  • Pending retest: This is when the testings from the tester are pending.
  • Retest: The testers check if the defect is fixed or not and change the status to “Re-test.”
  • Verified: It changes to “verified” after the “re-test” and when the changes necessary are done.
  • Reopen: If the bug persists after the fix, the tester changes the status to “reopen.” Once again the bug goes through the life cycle.
  • Closed: it’s closed when the tester not longer exists.
  • Duplicate: When the bug is repeated or it has the same concept the bug is label as duplicated.
  • Rejected: if is not an authentic bug is rejected.
  • Deferred: It is not a priority and it might be fixed in the next release.
  • Not a bug: Is considered a bug when it affects the functionality.

Conclusion:

When I read what a bug life cycle is and the steps or phases that it has. I realized that it was what i was looking into when looking for issues in open-source. I knew what most of the labels in the repo mean, but knowing this it would of make things a little bit easier at the moment of choosing one, and it would of save me some time, maybe not a lot, but still valuable time that I could of focus on something more important.

Sometimes re-studying or going through basics again is not a sign of weakness, in the end, it can give you more than you think.

--

--