End to End Technology Solutions
“Good software is like a wine, it takes time”. We know that during the development of any software product the development teams follow the Software Development Life Cycle (SDLC) processes. But its development process is not so easy.
During the development process when a product is being developed different types of defects or bugs arise with the product. So these defects are identified and resolved throughout the development process because we know that a good quality software product is to be delivered at last. So in this blog, we will discuss these bugs in the software development process and how we identify them during software testing and how these are resolved.
What is a BUG?
It is defined as a variance between expected and actual. In other words when there are several troubles with the software products, with its external behaviour or with its internal features. It is the deviation of the customer requirement.
Bug/Defect life cycle:
In simple words Bug or Defect life cycle is a cycle in which a defect goes through during its lifetime. The cycle starts when the tester finds a defect and it ends when a defect is closed, after testing the reproducibility of that defect.
It will be easier for us to understand the whole cycle by a diagram:
- New: After testing when a defect is logged and posted for the first time then its state is given as new.
- Assigned: After the bug is posted, the lead of the tester approves that the bug is genuine or not then he assigns the bug to the corresponding developer and the development team. It’s the state given as assigned.
- Open: At this stage, the developer starts analyzing and working on the defect fix.
- Fixed: When a developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and then the bug is passed to the testing team.
- Pending retest: After fixing the defect the developer has given that particular code for retesting to the tester. Hence its status is pending retest.
- Retest: At this stage, the tester does the retesting of the changed code which the developer has given to him to check whether the defect got fixed or not.
- Verified: The tester tests the bug again after it got fixed by the developer. If he finds that the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”.
- Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. After that, the bug cycle starts again.
- Closed: Once the bug is fixed, it is tested by the tester and the tester finds that the bug no longer exists in the software, he changes the status of the bug to “closed”. In the closed state, the bug is fixed, tested and approved.
- Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one of the bug’s status is changed to “duplicate“.
- Rejected: If the developer feels that the bug is not genuine, he rejects the bug and the status of the bug is changed to “rejected”.
- Deferred: In this state, the bug is expected to be fixed in the next releases. The reasons for changing the bug to this state have various factors. Some of them are the priority of the bug may be low, lack of time for the release or the bug may not have a major effect on the software.
- Not a bug: This state is given when there is no change in the functionality of the application. For example: If a customer asks for some change in the look and feel like changing the colour of some text in the application then it is not a bug it is just simply changing the look of the application.
Our main aim should be to deliver a good quality product to clients & remember one thing “All code is guilty, until proven innocent”.