Answer
# 4 |
5. Test Reporting:
During level ?1 & level ?2,
test execution, test engineers are reporting miss matches in
between test case expected values and build actual values as
defect report to development team.
In this test reporting, development people are receiving
defect report from testing team in a standard format. This
format followed by every test engineer in test execution to
report defects.
IEEE-829 Defect Report Format:
1. Defect ID: Unique no./name for future reference.
2. Description: Summary about defect.
3. Build Version: The version no. of current build, in this
build test engineers detected this defect.
4. Feature: The name of module / function, in that area test
engineers found this defect.
5. Test Case Name: The name of failed test case, in that
case execution test engineer found this defect.
6. Status: New reporting first time, Re-open Re-reporting.
7. Re-producible: Yes Defect appears every time in test
case execution, No Defect appears rarely in test case
execution.
8. If Yes: Attach test procedure.
9. If No: Attach snapshot and strong reasons.
10. Severity: The seriousness of defect in terms of
functionality.
High  Not able to continue testing
with out resolving this defect (show stopper)
Medium  Able to continue remaining
testing, but mandatory resolve.
Low  Able to continue remaining testing and May
/ May not to resolve.
11. Priority: Importance of defect to resolve in terms of
customer (High, Medium, Low)
12. Detected by: Name of test engineer.
13. Assigned To: The name of responsible person at
development side to receive this defect report.
14. Suggested Fix (Optional): Reasons to accept and resolve
this defect.
Resolution Type:
After receiving defect report from testing team, the
responsible development people are conducting review meeting
and sending resolution type to the responsible testing team.
There are 12 types of resolutions, they are
1. Enhancement: The reported defect is rejected, because
this defect related to future requirements of the customer.
2. Duplicate: The reported defect is rejected, because this
defect raised due to limitations of hardware devices.
3. Hardware Limitations: The reported defect is rejected,
because this defect raised due to limitations of hardware
devices.
4. Software Limitations: The reported defect is rejected,
because this defect is raised due to limitations Software
Technologies (Ms-Access).
5. Not Applicable: The reported defect is rejected because
these defects have improper meaning.
6. Functions as Designed: The reported defect is rejected,
because the coding is correct w.r.p.t design documents.
7. Need More Information: The reported defect is not
accepted / not rejected but the developers are requiring
more information about the defect to understand.
8. Not Re-producible: The reported defect is not accepted &
not rejected, but the developers are requiring correct
procedure to reproduce that defect.
9. No Plan To Fix It: The reported defect is not accepted &
not rejected, but the development people are requiring some
extra time.
10. Open: The reported defect is accepted & the development
people are ready to resolve through changes in coding.
11. Deferred: The reported defect is accepted, but postponed
to future release, due to low severity & low priority.
12. User Direction: The reported defect is accepted, but
developers are providing some valid information about that
defect to customer site people, through our application
build screens.
|
| Nag
|
Site Map
