Basics of software Defects/Bugs

Basics of software Defects/Bugs -

In this post, I am sharing my understanding as to what a software bug is , what should be done when we find one and their overall lifecycle and related content.

A defect OR bug in a software systems is a state/scenario where a software system is functioning OR acting in a different manner from what has been specified in requirement. In simple words , it is deviation of software from the specified requirements. It is the state of software when it behaves in some unexpected manner. Software Testers main job is to find out these defects OR bugs in any software system. Now when a defect is found it has to be recorded carefully. Most of the organizations use some software tools for recording and tracking of these bugs and many of them use standard WORD /EXCEL formats to record these bugs. Whatever be the way most important part is that these bugs should be recorded however recording these bugs in software tool is much convenient as tracking is made easy by using these tools. There are many bug tracking software available in the market both freeware and license tools.

As soon as a tester finds then before logging / recording a bug the first part is to reproduce it again so as to get the reproducibility rate. In case it is an obvious deviation from the requirements then we should not waste time in reproducing it and it should be logged then and there. now once we are confirmed that there is a bug in current system next step is to log it in bug tracking tool / standard template used in organization. The reason why we log is so that we bring this in attention of the developer. Sometimes , higher management / client also wants detailed defects reports / number of bugs in the system etc..

Recording a bug requires some skills, there are some mandatory OR standard information given with every bug/defect. Regardless of what tool/template you use in your organization, every bug should have following information –

Short description – A shots and concise description of what the defect is , in which module it occurred.

Steps to reproduce – Detailed steps to reproduce the defect with test data. Test data is optional part, it the defect is there with some specific data set then it has to communicated.

Actual Results – what is exactly happening after performing the above mentioned steps.

Expected Results – what should happen as per the requirement specification.

Environment – details of the environment in the defect is occurring.

Severity – the impact of the defect on other parts of application.

Priority – how soon the defect has to be fixed.

Version – version of the application in which the defect occurred.

Assignee – Every defect is assigned to somebody so that this person can start working on / take any immediate action on the defect.

Apart from the above we can include some additional information like reproducibility rate and other environmental details. Thumb rule while writing a defect report is there should be enough information required to reproduce the defect at the developers end. Information must be to the point not much not less as both these situations are dangerous. Excess information confuses the developer and with less information developers will keep revolving around your chair J

Now a defect also has a lifecycle. When a tester finds a defects and logs it into the specified system it is in state NEW. From this the defect enters into OPEN state when the lead assigns it to any developer for working on it. As the developer starts working on it, the defect is in WORKING state and when the defect has been resolved by the developer then it enters into RESOLVED state. This is the state when it comes back to the tester for verifying. Now when the tester verifies it and found that it is fixed then the tester closes the defect and the state is CLOSED. If in case it is not fixed then tester reopens it with state REOPEN and again the normal cycle goes on till it get closed. This is very general bug life cycle with no variations. But I wish this could be the stats as it is J. From the state NEW a defect can move onto DEFERRED in case the development people feels that this defect can be ignored right now and can be fixed in later release. A defect with NEW state can also move on to NOT A DEFECT/ NOT REPRODICIBLE depending on what the current state of requirements OR information provided in the defect report. In both these cases, it again comes back to the tester and now tester has to close it OR provide more information to the developer and further reopen it.


That’s the end of the post and as always comments/suggestions are welcome for improvement. I would also like to discuss and correct my understanding (if wrong) through this post/blog.



Thanks & Regards,
Amit