As testers execute a program during a testing activity, if a failure in the software is witnessed, testers should report the details of the failure in order to identify which defect(s) leads to that failure. The defect log report should contain necessary information, and this information should be detailed enough for the developer to analyze and reproduce the failure order to be able to find the root cause of the failure.
Typically, there are two ways of reporting defects, informal and formal.
Informal Reporting
Informal way of reporting defects simply means communicating the details of the failure with the developers in person, in email or over the phone. It does not involve writing a detailed log report to inform the developers of the issue. This way of informal reporting is normally carried out before the formal testing cycle starts, i.e. the code is still in development, and is common among the developers themselves or during “buddy testing”.
There are certain benefits in the informal way of reporting defects in that the developer’s time can be put more to use in actually fixing the defect, rather than trying to put every detail in a report. i.e. fixing the defect quickly is more important than trying to elaborate the details of the failure.
Formal Reporting
The formal way of reporting defects is normally done by the testing team during the formal testing phase. As soon as the outcome of the test step does not match with the expected result, there is a deviation of the correct workflow and the issue needs to be reported. As testers execute test cases and find defects, they must record every detail of the defect and what steps they performed to find the defect.
Recording every detail accurately helps in reproducing the defect when demonstrating to the fellow developers or to other members of the test team. The details will also help the reviewer to analyze and match the steps against the test script to see if the tester followed the steps according to the test script.
What happens, if a defect would be discovered by chance when just “playing” with the system, or performing exploratory (unscripted) testing? Should we still need to report defects?
At this stage, because we are not following a test script, we may be reporting issues which are not really defects due to the fact that we cannot compare the outcome of the test execution to any expected results. Or we may have not set up the testing environment correctly and that has caused issues with the system under test. We may witness some very obvious failures with the system, i.e. system crashes as you execute a query or we may have doubts in the outcome of the program. In these situations, it is always best to record the steps, and not necessarily the full details, and keep the record for when the expected results of the steps become apparent so we can compare the outcome of the program with the expected results.
Note: There is a distinction between scripted and unscripted exploratory testing. When we explore the system, we generate test cases without much knowledge about the outcome of the test step. Hence, we have not predesigned your test cases which would have had expected results next to them. In exploratory testing, there is no test script; we learn about the system which would then help in designing test cases to reveal defects.
In scripted testing we follow a test script with a set of predesigned test cases based on the requirement and design documents and we have identified expected results for each test step to compare the outcome of the steps with the expected results. If we execute test cases, without a test script, based on our knowledge of the system, the design, the requirements, user’s expectations, and know what the outcome of each step should be, it is no longer exploratory testing, because we knew of the expected results.

Post By (79 Posts)
When to Report Defects In Software