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.
- 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 ?
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
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.
- 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
No comments:
Post a Comment