Test plan is a statagic document which describes how to perform the testing on a application in

an effective, effecient and optimisation way.

contents of test plans :
1. Introduction
objectives
reference document
2. Coverage of Testing

Features to be tested
Features not to be tested

3. Test Stategy

leves of testing
types of testing

test design techniqes

configaration management

test maticx

terminology

automation plan

list of automation tools

4. Base Criteria

acceptance criteria
suspension criteria

5. test deliveribles
6. test envirolment
7. scheduling
8. staffing and trining
9. risks and solution plan
10. assumtions

11. approval information

System Test Entrance/Exit Criteria

Entrance Criteria
The Entrance Criteria specified by the system test controller, should be fulfilled before
System Test can commence. In the event, that any criterion has not been achieved, the
System Test may commence if Business Team and Test Controller are in full agreement that
the risk is manageable.

All developed code must be unit tested. Unit and Link Testing must be completed
and signed off by development team.

System Test plans must be signed off by Business Analyst and Test Controller.

All human resources must be assigned and in place.

All test hardware and environments must be in place, and free for System test use.

The Acceptance Tests must be completed, with a pass rate of not less than 80%.

Acceptance Tests:
25 test cases will be performed for the acceptance tests. To achieve the acceptance criteria
20 of the 25 cases should be completed successfully - i.e. a pass rate of 80% must be
achieved before the software will be accepted for System Test proper to start. This means
that any errors found during acceptance testing should not prevent the completion of 80%
of the acceptance test applications.
Note: These tests are not intended to perform in depth testing of the software.
[For details of the acceptance tests to be performed see
X:\Testing\Phase_1\Testcond\Criteria.doc]
Resumption Criteria

In the event that system testing is suspended resumption criteria will be

specified and testing will not re-commence until the software reaches these
criteria.

Exit Criteria
The Exit Criteria detailed below must be achieved before the Phase 1 software can be
recommended for promotion to Operations Acceptance status. Furthermore, I recommend
that there be a minimum 2 days effort Final Integration testing AFTER the final fix/change
has been retested. [See section 9.3]

All High Priority errors from System Test must be fixed and tested

If any medium or low-priority errors are outstanding - the implementation risk must
be signed off as acceptable by Business Analyst and Business Expert

Project Integration Test must be signed off by Test Controller and Business Analyst.

Business Acceptance Test must be signed off by Business Expert.

Defect Management
1. What is Defect Tracking?
Monitoring defects from the time of logging until it has been resolved.
2 What is a defect?
Variance between expected and actual output.
3. What are the different kinds of status u assign.
Open, Close, Deferred, Fixed, Reopen, Accept, Assign,
4. What are the different kinds of severity and priority?
Severity: Critical, Major, Medium, Minor, And Cosmetic
Priority: High, medium, low
5. Who decided the severity?
Test Engineer (testing team)/ Project Manager
6. Who assigns the priority?
Project Lead/ Manager
7. Define and Difference between Severity and Priority.
Severity: Criticality of the business requirement of the application
Priority: Criticality of the business release of the application
Priority depends on the Release, whereas severity depends on the criticality.
However critical it is, if it not going into current releaseit is ignored
8. How many high severity defects did u find in your project and how do u decide?
10 15 it is effecting on the functionality of the application
(It could be any where between 2 to 15. depending on the project )
9. How many high priority bugs did u find in your current project and how do u
decide?

5. Decided by the development team.

(It could be any where between 2 to 15...depending on the project)
10. Can u name a defect with high priority and low severity in your current project?
Ex: In job seeker registration, filling in the details and clicking on "Save " button, the
page is not getting navigated to the next page.
(Depends on the project)

11. Can u name a defect with high severity and low priority in your current project?
After a job seeker is registered, he has to get e-mail with subject he is registered. But he
is not getting the mail to the e-mail ID that he has provided at the time of registration.
(Depends on the project)
12. Tell me the defect report life cycle followed in your project.
Raise the defect with reproducible steps.
Review it internally (Peer- Peer, Peer- Lead, Peer- Manger)
Submit the defect to the development team (severity of the defect should be mentioned)open state
Developer may accept/Reject/Postpone
Developer Fix the Defect
Developer will resolve the Defect and sends to the testing team with status fixed.
Retesting is done and status is assigned as Close/Reopen.
13. How r u reporting the defects in your company? Using any tools.
Defect Sheet Template/ Bug tracking tools/ Test management tools.
Ex: Bugzilla, Test director, Rational clear quest,
14. How do you react, incase, the bug raised by you is not resolved.
Escalation Process and meeting with the development Team.

15. Format of the defect report sheet in case if they are using Excel sheet.
Defect No./Id.
Description
Origin TC id
Severity
a. Critical
b. Major
c. Medium
d. Minor

e. Cosmetic
Priority
f. High
g. Medium
h. Low
Status
16. What is the average age of a Bug? (Age = Defect Resolved date - Defect Open date)
Where it will be mentioned?
Depends on the Nature of the bug, Functional flow and dependencies.
(Defect rose on 20th Jan and closed on Feb 14th Therefore age = Feb 14th Jan 20th = 24
days). It is mentioned in the project management review report.
17. What is the naming convention for a defect followed in your project?
Example: DF_TC_001
18. Once the bug status is deferred, what is the further process to resolve this issue?
Call for a team meeting, share the bug reports and compare with requirement.
This will help us in understanding the fault. It might be true that updated requirement
documents are not given to either testing or development team.
19. Where do you mention the defect metrics in case you want to go ahead with the
next cycle?
Defect Summary reports and Test plan
20. On an average, how many defects do you find in a day?
Ex: 2-3 defects. It varies on the functionality and project.
21. What do you mean by defect density?
Defect density = (Defects found / Size) * 100
22. What is review efficiency?
Defects found per hour is termed as review efficiency.
(No of defects / Review Time)
23. What is defect Removal Efficiency?
Defect Removal Efficiency is the measure of the defects removed prior to delver of the
software to the customer, expressed as a percentage of the sum of all defects detected to
date.

(Defects detected during development of application)/ (Defects detected during

production) * 100
24. Define Correction Efficiency
Defect correction efficiency is a measure of the quality of corrective work.
DCE = (B/A) * 100 where,
B = Total number of defects introduced due to the above A defect fixes.
A = Total number of defects corrected.
25. What is severity Index?
Severity Index is computed based on the severity of the found defects. The Index is determined
by weighted numbers of defects per Severity level.