Defects are the inevitable part of Software testing as these are the only tangible output of whole testing process. Resolution of these defects helps in improving the overall quality of the application. Defects are always present in the software under test even after completing the testing cycle as even for a small piece of code there can be lot of permutation and combinations of scenarios possible and testing them all are not possible so for testing perspective we need to identify all the basic flows and the other critical areas which must be tested before releasing the application to anybody. Basic flows are the main functionalities without which the application is not of any use so it must be working properly to proceed further for e.g. In a flight reservation system, registering of a flight and a passenger in the system are the basic flows and only once the flight details and passenger details are in system we can reserve a flight for passenger which is the main goal of this application. Critical functionalities are the ones which are very important for day to day operations done through the application for e.g. in above example if this software is to be installed at such a place where majority of people book connecting flights so while searching for flight, there must be a possibility to search only those flights which reaches the destination before the start of next flight.
Now as these defects will always be there even after exhaustive testing so when can we stop the testing. Answer to this lies in the acceptance criteria which is mentioned in the Test Plan and must be agreed with the client. Acceptance criteria must tell what is acceptable to the client and same must be achieved while testing. A general acceptance criterion tells that there must not be any critical and high severity defects and for medium and low severity there must be some agreed plan stating by when these can be closed. With the release we must send a list of all the known Medium and Low severity defects.
While testing many defects will get discovered so we need to have a process to manage these defects so that all the concerned people gets timely updates and plan their tasks accordingly. For this usually all the organization uses some Defect Management Tool. There are many such tools available in the market like Bugzilla, Rational ClearQuest, Star Team etc. All the defect tracking tool work on a workflow which can also be called Defect Life Cycle which states how the defects moves from being discovered in the application to resolved and then closed after testing. These tools also make sure that all the concerned people get relevant alert which speed up the process. Some of the tool also allows customizing the Defect Workflow if the default workflow doesn’t exactly suits the users need. Basic workflow which can be directly used is displayed below
According to above workflow, a defect once discovered in the application is first logged in the defect management tool and then assigned to the concerned developer and at this time most of the tools have the feature that a mail is sent to that developer with a summary of defect so that he comes to know that there is a defect in his name. Status here changes from New to Open. Developer will then check the validity of the defect and if it is invalid then Reject the defect and the status changes from Open to Rejected but if the defect is valid then he will follow the steps mentioned in the defects to replicate the defect and then resolve it. After resolving he will change the status to Fixed and then automatically a mail is sent to the submitter of the defect. Submitter (Tester) will check the fix done for the defect and if the fix is not correct he can re-open the defect which developer needs to resolve again and id the defect is fixed properly then tester will close the defect. Also the defect which was earlier rejected by developer comes back to tester and then he will add more information to it if required and assign it back to the developer and then this also go through the cycle discussed above.
This is Defect Management Process in whole where a defect life cycle is tracked.
Thanks Vikram for posting a quick overview topic on testing.
ReplyDeleteVikram, thank you for the scheme of bug life cycle! It's the simplest scheme that I've ever seen!
ReplyDelete