Defect/Bug Life Cycle in Flutter
Hi everyone! today we explore the Defect / Bug life cycle In Flutter. The Defect Life Cycle, also known as the Bug Life Cycle, is a cycle of defects that it goes through covering the different states in its entire life. This starts as soon as any new defect is found by a tester and comes to an end when a tester closes that defect assuring that it won’t get reproduced again.
If you’re looking for the best Flutter app development company for your mobile application then feel free to contact us at — support@flutterdevs.com.
Table Of Contents::
Tips to write a good bug report!
What is Defect/Bug?
A defect is an error or a bug, in the application which is created. A programmer while designing and building the software can make mistakes or errors. These mistakes or errors mean that there are flaws in the software. These are called defects.
What is Defect Life Cycle?
Defect Life Cycle or Bug Life Cycle in software testing is the specific set of states that a defect or bug goes through in its entire life. The purpose of the Defect life cycle is to easily coordinate and communicate the current status of defects which changes to various assignees and makes the defect fixing process systematic and efficient.
Defect Status:
Defect Status or Bug Status in the defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or progress of a fault or bug to better track and understand the actual progress of the defect life cycle.
The number of states that a defect goes through varies from project to project. Below lifecycle diagram, covers all possible states
- New: When a new defect is logged and posted for the first time. It is assigned a status as NEW.
- Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the bug to the developer team
- Open: The developer starts analyzing and works on the defect fix
- Fixed: When a developer makes a necessary code change and verifies the change, he or she can make the bug status “Fixed.”
- Pending retest: Once the defect is fixed the developer gives a particular code for retesting the code to the tester. Since the software testing remains pending from the tester’s end, the status assigned is “pending retest.”
- Retest: The tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and changes the status to “Re-test.”
- Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is “verified.”
- Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to “reopened”. Once again the bug goes through the life cycle.
- Closed: If the bug no longer exists then the tester assigns the status “Closed.”
- Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate.”
- Rejected: If the developer feels the defect is not genuine then it changes the defect to “rejected.”
- Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then the status “Deferred” is assigned to such bugs
- Not a bug: If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.
Defect Life Cycle Explained:
- Tester finds the defect
- The status assigned to defect- New
- A defect is forwarded to the Project Manager for analyze
- The project Manager decides whether a defect is valid
- Here the defect is not valid- a status is given as “Rejected.”
- So, the project manager assigns a status rejected. If the defect is not rejected then the next step is to check whether it is in scope. Suppose we have another function- email functionality for the same application, and you find a problem with that. But it is not a part of the current release when such defects are assigned as a postponed or deferred status.
- Next, the manager verifies whether a similar defect was raised earlier. If yes defect is assigned a status duplicate.
- If no the defect is assigned to the developer who starts fixing the code. During this stage, the defect is assigned a status in progress.
- Once the code is fixed. A defect is assigned a status fixed
- Next, the tester will re-test the code. In case, the test case passes the defect is closed. The defect is re-opened and assigned to the developer if the test cases fail again.
- Consider a situation where during the 1st release of Flight Reservation a defect was found in the Fax order that was fixed and assigned a status closed. During the second upgrade release, the same defect again resurfaced. In such cases, a closed defect will be re-opened.
Tips to write a good bug report!:
One of the most important skills that you need to have in your tester’s toolbox is the ability to write a good bug report. Finding defects is only part of the job because if developers can’t reproduce the bugs you find, they will have a very tough time fixing them. Your bug tracking software should include several mandatory fields to ensure that testers give a complete account of the defect they encountered. And testers should hone their descriptive skills.
Good bug reports contain:
- > Descriptive Title — Everything starts with a title. It must be clear and descriptive so that you get an idea of what it is about at a glance.
- > Concise Description — Try to remain clear and concise in your description. Describing something accurately and concisely is a skill that develops with practice. Remember that the person reading your description has not seen the bug and try not to make assumptions.
- > Expected Results — You have to make it clear what you expected to happen and how the defect diverged from that expectation. This field helps to prevent any misunderstandings, and it gives the developer a clear idea of what went wrong.
- > Details about the project and version — It’s not unusual for testers to work on multiple projects at the same time, and sometimes they’ll share a database, so ensuring that your bug is listed in the correct project, and section within that project, is vital. You also need to get the software version right. Sometimes a bug will be fixed when a different defect is addressed, or simply by some change in the newest version of the software. If the version is wrong, developers may be embarking on a wild goose chase.
- > Platform Details — Any background information you can provide about your environment will help developers track that bug down. What device were you using? What operating system was it running? What model was it? What browser did you use? Every detail you can give about the platform will help.
For Example Device Type, Model, Browser Version, and OS Version.
- > Defect Type and Severity — These fields go hand-in-hand. A functional bug will generally be treated more seriously than a suggestion. Developers also need to know how severe the bug is. No product ships with zero defects, so having bugs categorized correctly in terms of type and severity helps the decision-making process about what gets fixed and what doesn’t. So it is always better to mention the Priority and Severity of the Bugs.
- > Steps to Reproduce (this is very important!) — You want to give a step-by-step account of exactly what you did to find any defect. Sometimes you can use software tools that catch your keystrokes, or record screenshots or video files as you test, other times you will be writing from memory, so take notes as you go. Make sure that you test your steps again before submitting the bug.
Indicate reproducibility as well. Sometimes you’ll be confident about your steps, but upon repeating them the bug won’t necessarily occur. If it happens every time, at random, or only once, then the developer needs to know that.
- > Visual Attachment — Supporting material is always gratefully received by those tasked with fixing defects. Usually, these will be screenshots, but they can include audio and video files. Keep in mind this is often what developers look at first, before reading the text you provided. If you can convey the issue in a single screenshot, you’re helping save precious time!
- > Tags & Links — It can be a good idea to use descriptive tags that enable you to filter the database and find groups of related bugs. Sometimes you’ll want to include another bug ID or a link within your defect report to something that you feel is strongly related or similar, but not similar enough to be a duplicate.
- > Assignee — It’s usually going to be up to the lead developer or management to assign bugs, but on occasion, you might receive instructions about who to assign them to. Leaving unassigned or wrongly assigned bugs in the database is a dangerous thing because they can potentially slip through the cracks. Make sure you’re clear on the expectations for assigning.
- Put it all together — Bring all of this together and you should have a good bug report. If you’re uncertain about the quality of your bug reports ask for feedback. A quick chat with the developers can help you understand what they need.
Conclusion:
This is all about the Defect Life Cycle and Management. We hope you must have gained immense knowledge about the life cycle of a defect. This Blog will, in turn, help you while working with the defects in the future in an easy manner.
❤ ❤ Thanks for reading this article ❤❤
If I got something wrong? Let me know in the comments. I would love to improve.
Clap 👏 If this article helps you.
Feel free to connect with us:
And read more articles from FlutterDevs.com.
FlutterDevs team of Flutter developers to build high-quality and functionally-rich apps. Hire a flutter developer for your cross-platform Flutter mobile app project on an hourly or full-time basis as per your requirement! For any flutter-related queries, you can connect with us on Facebook, GitHub, Twitter, and LinkedIn.
We welcome feedback and hope that you share what you’re working on using #FlutterDevs. We truly enjoy seeing how you use Flutter to build beautiful, interactive web experiences.
