Test Log Document and Test Incident reports

Test Log Document:

According to IEEE 829 -1998, The test log document is a chronological record of relevant details about the execution of test cases. The purpose of the test log is to share information among testers, users developers and others to facilitate the replication of a situation encountered during testing.  It is simply a document which is used to share and refer about the execution on test cases among testers, developers, users.

Contents of the Test log consists of

• Test log Identifier
• Description
• Activity and Event entries

Test Incident report: 

An incident report provides a formal mechanism for recording software incidents , defects, enhancements and their status.

Now what are these incidents ?

Incident: While executing a test, we might observe that the actual results vary from expected results. When the actual result is different from the expected result then it is called as incidents, bugs, defects, problems or issues. To be specific, we sometimes make difference between incidents and the defects or bugs. An incident is basically any situation where the system exhibits questionable behavior, but very often we refer an incident as a defect only when the root cause itself is some problem in the item which we are testing. Other causes of incidents include misconfiguration or failure of the test environment, corrupted test data, bad tests, invalid expected results and tester mistakes.

Test  Incident report Contents:

The test incident report has a template , and all the incidents are reported systematically in this format only.

• Incident Summary report Identifier
• Incident Summary
• Incident Description

Incident summary Report Identifier:

It is a unique company generated number to identify an incident report, its level and the level of software that particular incident report related to. The number may also identify at what level of testing the incident occurred and all the details. This is to assist in coordinating software and testware versions within configuration management and also to assist in the process of elimination of incidents through process improvement. 

Incident Summary:

This is a summarization or description of the actual incident.  Provide enough details to enable others to understand how the incident was discovered and any relevant supporting information such as: 

• References to
• Test Procedure used to discover the incident
• Test Case Specifications that will provide the information to repeat the incident
• Test logs showing the actual execution of the test cases and procedures
• Any other supporting materials, trace logs, memory dumps/maps etc.  

Incident Description:

Incident Description provides as much details on the incident as possible. Especially if there are no other references to describe the incident.  It includes all the relevant information that has not been included in the incident summary information or any additional supporting information which includes details like

• Inputs
• Expected results
• Actual results
• Date and Time
• Procedure step
• Environment
• Observers
• Impact
• Investigation
• Matrices

Impact: It describes the actual or potential damage caused by the incident.  This can include either the Severity of the incident and the Priority to fix the incident or both. Severity and Priority need to

Severity:  

The potential impact to the system. It indicates the impact of the defect on the business.

• Blocker or show Stopper:  An application will not function or system fails. It will not allow the testers to proceed until and unless this is rectified. There is no possible work around.
• Critical: Severe problems but possible to work around . Test can be continued but it has to be rectified. But is quite difficult to work
• Major: It  does not impact the functionality or usability of the production but it has to be fixed befor getting released into the market and there is a possibility to work around more easily when compared to critical.
• Minor: The functionality is nice to have in production but it is not necessary to be fixed prior to get released.

Priority:  The order in which the incidents are to be addressed

• High:  Must be fixed as soon as possible
• Medium:  System is usable but incident must be fixed prior to next level of test or shipment
• Low:  Defect can be left in if necessary doe to time or costs