Answer / nag

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.

Answer / namrata

Praveen you are forgetting three important fields Status,
priority and severity of the defect.

Answer / lakshmi vardhani. b

We should draft the bug in such a way that by looking at
those steps a developer should understand easily what is
the bug exactly and where is it appeared.

And the steps to Reproduce should be in such a manner that
when developer performs those steps then he should be able
to reproduce it easily.

The steps should be:

1) Product
2) Module
3) Sub module
4) Version
5) OS
6) Browser
7) Platform
8) Severity
9) Priority
10)Assaigned to
11)Status
12)Summary
13) URL of the particular screen
14)Description
Under Description "Steps to Reproduce"
15)Error Noticed
16)Expected Result
17)Testers notes
18)Assigned by

Along with this snap shots should be attached with better
reference.

If we draft the bug in this way then the developers job
will be easy.

this will improve productivity.

If any additions are there pls let me know.

Answer / abu

Defect templates n excel sheet


defect id
defect description
defect procedure
test data
expected result
actual result
defect status
defect severity
defect priority
date and time of defect
defect by whom
whom to be refered


defect by whom
whom to be refered

Answer / praveen

To report the defect using excel sheet

Mention : The Feture that been effected.

mention : Test Case ID (Which fail you can even
mention any other which are dependency on
this bug)

Mention : Actual Behavior

Mention : Expected Behavior as mentioned in Test Case
or EFS or EBS or SRS document with section

Mention : Your Test Setup used during Testing

Mention : Steps to Re-Produce the bug

Mention : Additional Info

Mention : Attach a Screen Shot if it is a GUI bug

Mention : Which other features it is blocking
because of this bug that you are unable to
execute the test cases.

Mention : How much time you took to execute that test
case or follow that specific test case
which leaded to bug.

Answer / mukesh sharma

Bug List in excel sheet contains mentioned fields:

Bug ID : Unique no./name for future reference.
Description : Summary about bug/defect/error.
Raised in Build/ Release/ Version/ Sprint : The version no. of current build, in this build test engineers detected the bug.
Feature : The name of module / function / feature, in that area test engineers found the bug.
Test Case Name : The name of failed test case, in that case execution test engineer found this bug.
Status : Life cycle of the bug.
New : A new bug detected by a tester
Open : A bug that has been reviewed and verified as a true bug
Rejected : A bug that has been found not to be a bug
Assigned : A bug that has been verified by development and is now assigned to developers for fixing
Fixed : A bug that has been fixed and is ready for retesting
ReTest : A bug that has been fixed by developers, which is once again tested to be closed
ReOpen : A bug that has failed testing during ReTest
Closed : A bug that has successfully passed retesting
Deferred : A bug that has been mutually agreed to move to the next release or later releases.
Duplicate : If the bug is repeated twice or the two bugs mention the same concept of the bug, then the recent/latest bug status is changed to “duplicate“.
Not A Bug : If there is no change in the functionality of the application. Work as expected.
Severity : The seriousness of bug in terms of functionality.
High : Not able to continue testing with out resolving this bug (show stopper)
Medium : Able to continue remaining testing, but mandatory resolve.
Low : Able to continue remaining testing and may / may not to resolve.
Priority : Importance of bug to resolve in terms of customer (High, Medium, Low)
Detected By : Name of test engineer.
Assigned To : The name of responsible person at development side to receive this bug report.
Open Date : Date of bug found.
Closed Date : Date of bug fixed.
Verified in Build/ Release/ Version/ Sprint : The version no. of current build, in this build test engineers tested and verified the bug.
Testers Comments : Comments related to Bug Status, Severity, Priority, Suggestion to fix etc. Comments by testers.
Developers Comments : Comments by developers
Attachment : Screenshot or video Link.

Answer / satyajeet

defect id
summary
severity
priority
author name
status
date
description
attachments
-----------------------------------------------------------
Sample of writing defect report in excel
-----------------------------------------------------------
Defect Id :did_login_01
Summary :Login Module
First Name & Last Name
address
pin code
Telephone No
User ID & Password
User ID & Password
Severity :Medium
Priority :Medium
Author Name:Tester
Status :new
new
new
new
new
new
Date :
Description:First Name > 10 characters
Address > 50 characters
Pin code < 6 Digit
Telephone No > 10 Digit
User Id & Password did not match with the
requirement as per client data
User Id & Password did not match with the
requirement as per client data

Attachments

Phases of Software Testing Life Cycle?

11 Answers  

in case of web application what kind of areas we r tested and one more in case of database testing what we are testing tell me in brief.

1 Answers   HCL,

What is the client-server, standalone, web-based application. Post the correct answer.

1 Answers  

what is system testing?

6 Answers  

what is the Test completion Criteria?

4 Answers   Mind Tree,

This is a interview question i faced? Suppose your client doesnt have any idea abt software or the technology ?then how

3 Answers  

Tell me abuot your daily activities as a test engineer.

6 Answers   InterSoft,

Anybody Explain me Bug Life Cycle..?

14 Answers  

What is the difference between Usability testing and Exploratory Testing?

7 Answers   Religare,

Explain the difference between severity and priority.

0 Answers  

what is data base testing, explain with example

1 Answers   Crea,

What is the role of QA in a company that produces software?

1 Answers