Professional Documents
Culture Documents
Product: Quality:: Project
Product: Quality:: Project
SoftWare Testing:
⇒ Project:
Project is some thing that is developed based on the particular
customers requirements and used by that customer only
⇒Product:
It is some thing that is developed based on the companies specification and used by
the multiple customers
⇒Quality:
Classical definition for quality: - Quality is defined as justification of all the
requirements of customer in a product.
NOTE: Quality is not defined in the product; it is defined in the customers mind
Latest definition for quality: - quality is defined as not only the justification of
requirements but also the presence of value (User friendliness)
⇒ Testing:
Testing is processes, in which the defects are identified, isolated, subjected for
rectification & ensure that the product is defect free. In order to produce the quality
product in the end and hence customer satisfaction.
bandaru7778@gmail.com 1
Page 2
2. Analysis phase
3. Design phase
4. Coding Phase
5. Testing Phase
(a) Tasks: Interaction with the customer and gathering the requirements.
Once the requirement document has come to the company the engagement
manager will check whether the customer gives any extra requirements or confused
requirements. In case of extra requirements he deals the excess cost of the project. In case
of confused requirements he is the responsible for prototype demonstration and gathering
the clear requirements.
⇒Proof: The proof document of this phase is Requirements Document. This is called with
different names in different companies.
5. BD (Business Document)
Some companies may maintain the over all business flow information in one document and
the detailed functional requirement information in the other document
bandaru7778@gmail.com 2
Page 3
⇒Templates: It is a pre defined format, which contains the predefined fields, and used
for preparing a document in an easy, comfort and perfect manner.
⇒Prototype: -Defined as a roughly & Rapidly developed model which is used for
demonstrating to the client, In order to gather the clear requirements and to win the
confidence of a customer.
(a) Tasks:
1.Feasibility Study
2.Tentative planning
1. Technology Selection
2. Requirement Analysis
(b) Roles: System Analyst, Project Manager, and Team Manager.
Process
2. Tentative Planning: In this section the resource planning and the time planning
(scheduling) is done temporarily.
3. Technology Selection: - The list of all the technologies that are required to
accomplish this project. Successfully will be analyzed and listed out in this section.
4. Requirement Analysis: - The list of all the requirements that are required to
accomplish this project. Successfully will be analyzed and listed out here in this
section.
bandaru7778@gmail.com 3
Page 4
Roles: High-level designing is done by the chief Architect & Low level designing is
done by the Technical Lead
Process: The Chief architect will be drawing some diagrams using unified modeling
language in order to divide the whole project in to modules.
The Technical lead will also draw some diagrams in order to divide the modules in
to sub modules.
The technical lead will also develop the PSEUDO code in order to make developers
comfortable while de3veloping the actual code.
Process: Developers will develop the actual code by using the technical design document
as well as following the coding standards like Proper indentation, color coding, proper
commenting and etc..,
V. Testing Phase:
Process:
1. First of all the test engineers will collect the requirements
document and try to understand all the requirements
bandaru7778@gmail.com 4
Page 5
2. While understanding it at all they get any doubts they will list out
all of them in a review report.
3. They will send the review report to the author of the requirements
document for clarifications.
4. Once the clarifications are given and after understanding all the
requirements clearly, they will take the test case template and
writes the test cases.
5. Once the first build is released then they will execute the test cases
6. If at all any defects are found. They will list out all of them in a
defect profile template then
8. Once the next build is released then they re-execute the test cases.
9. If at all any defects are found they will update the profile
document and sent it to the development department and will be
waiting fro the next build to be released .
⇒Test Case: (def) Test case is an idea of a test engineer based on the customer’s
requirements in order to test a particular feature or a function.
Delivery:
(a) Task: - Installing the application in the client’s environment
bandaru7778@gmail.com 5
Page 6
Maintenance:
After delivering the soft wate while using if at all any problem occurs then
that problem becomes a task, based on that problem corresponding rolws will be
appointed, the roles will defined the process and solve that problem.
Some clients may request for the continuous maintenance in such situations a group
of people from the software company will be continuously working on the clients place
and taking care of the soft ware.
************************^^^^^^^^^^^^^^^^^^^************************
1. Un-conventional testing
2. Conventional testing
2.Conventional Testing: It is sort of testing done by the test engineers on the application
in the testing phase of SDLC.
bandaru7778@gmail.com 6
Page 7
(a) Black-Box Testing: If one performs testing only on the functional part of an
application with out having any structural knowledge then that method of testing is
known as Black-Box testing, usually the test engineers perform it.
(c) Grey-Box Testing: If one performs testing on both the functional part as well as
the structural part of an application then that method of testing as known as gray
box testing using the test engineers who have structural knowledge will perform
gray- box testing.
⇒Levels of Testing:
There are five levels of testing
bandaru7778@gmail.com 7
Page 8
The developers may follow one of the following approaches while integrating the
modules.
1.Top-down approach
4.Bigbang approach
1.Top-down approach: - In this approach one will develop the parent modules first and
then integrate them with the related child modules
2.Bottom-up approach: - In this approach one will develop the child modules first and
integrate them to the parent modules
4.Big bang approach:-In this approach one will wait till all the modules are ready and
finally they will integrate all the modules at a time
⇒STUB: - While integrating the modules in top down approach if at all any mandatory
module is missing then that module is replace with a temporary program known as STUB
bandaru7778@gmail.com 8
Page 9
It is a level of testing in which one will install the complete application in to the
environment and then perform testing on it. At this level different types of testing will be
done one among those is system integration testing.
a. Presentation layer
b. Business layer
a. Presentation Logic: The logic that is used for viewing application is known as
presentation logic
b. Business Logic: - The logic that is used for performing the operations on the
application is known as business logic.
c. Data Base Logic: - The logic that is used for sharing and retrieving the data is
known as database logic.
bandaru7778@gmail.com 9
Page 10
In this type of environment all the three layers that is presentation layer,
Business layer& Database layer will be present in al single tier. This type of
environment is suitable for single user application.
One-Tier Architecture
PL
PL+BL DBL
PL+BL
PL+BL
Clients Server
c. Web environment: - In his type of environment three tiers will be there. One is for
client’s the middle one is for application server and the other one is for database
servers. Presentation layer will be present at clients, Business layer will be present in
the application server, and database layer will be present at the database servers. This
type of environment is suitable for the applications that are used all over the world by
limited number users
bandaru7778@gmail.com 1
Page 11
Three-tier Architecture:
PL
DBL
BL
PL
DBL
PL
Web server: -
It is software, which provides web services to the clients.
E.g.: - Internet Information service (IIS).
Example for Application servers: Tom pact, Web logic, web sphere etc..,
d. Distributed environment: -
It is similar to the web environment but the number of application servers
are increased and represented in individual tiers in order to distribute the
business logic so that the logic will be distributed.
N-tier Architecture:
Ws
PL DBL
BL BL BL
PL
bandaru7778@gmail.com 1
Page 12
PL
PL
******************^^^^^^^^^^^^^^^^^^^^^^^********************************
UTR
CODING Implementation Unit test
Int. test
UTR
DEL&MAINT UTR
Delivery to
bandaru7778@gmail.com client 1
Page 13
Advantages:
It is a simple model
Project monitoring & maintenance is very easy
Drawbacks:
Con not accept the new requirements in the middle of the project
H/Wprototype H/Wprototype
Prototype
S/WPrototepe H/Wprototype
Advantages: -
Whenever the customer is not clear with the requirements this is the best suitable
model for gathering the clear requirements.
Drawbacks: -
⇒ It is not a complete model
⇒ Prototype has to be built on companies cost
⇒ User may limit his requirements by sticking to the prototype.
bandaru7778@gmail.com 1
Page 14
Initial Req
User
Application User accept
validation
Appl is Base lined
Y
Advantages: -
Whenever the customer is evolving the requirements this is the best
Suitable model.
Drawbacks: -
• Cannot define the dead lines
• Project monitoring & maintenance is very difficult
• No Transparency (No clear)
Spiral Model: -
Defining the objectives/WA/Constraints
Advantages: -
This is the best suitable for developing the highly risk based project
(scientific projects)
Drawbacks: -
Risk analysis and estimation is not an easy task
It is a costly model
It is a time consuming model
Advantages: -
This is the best suitable for developing the highly risk based project(scientific
projects)
Drawbacks: -
o Time consuming Model
bandaru7778@gmail.com 1
Page 16
Costly model
Verification: -
It is a process of checking conducted on each and every role of the
organization in order to check whether they are working according to the guidelines or
not right from the starting of the process till the ending of the process
Validation: -
It is a process of checking conducted on the developed product in order to
check whether it is working according to the requirements or not.
(D) V-Model: -
Verification Validation
Port Testing
S/W efficiency DRE=A/A+B
Delivery & Maintenance Test S/W changer
bandaru7778@gmail.com 1
Page 17
Advantages; -
AS verification and validation as well as test management process is
done the out come will be a quality product.
Drawbacks: -
o Time consuming mode
o Costly model
bandaru7778@gmail.com 1
Page 18
2.Regression Testing: -
It is a type of testing in which one will perform testing on the already
tested functionalities again and again.
It is usually done in two scenarios.
Note: - Testing the new functionalities for the first time is known as new testing but not
Regression Testing.
3.Re-Testing: -
It is a type of testing in which one will test the same functionality
again and again with different sets of values in order to come to a conclusion whether it is
working or not.
Advantage: - If at all any defects are found then there is a chance of rectifying them
immediately.
5. β -Testing (Beta): -
bandaru7778@gmail.com 1
Page 19
It is a type of user acceptance testing done in the clients place either by the
end-users or by the third party testing experts before actual implementation.
Drawback: If at all any defects are found then there is no chance of rectifying them
immediately.
6. Static Testing: -
It is a type of testing in which one will perform testing on the
application or application related factors with out performing any action.
Eg:- Documentary testing, GUI testing, Code reviews and etc.,
7. Dynamic Testing: -
It is a type of testing in which one will perform in the application or
its related factors by doing some actions
Eg: - Functionality testing.
8.Installation Testing: -
It is a type of testing in which one will install the application in to the
environment by following the guide lines provided in the installation document and if the
installation is successful then he will come a conclusion that the given guide lines are correct
other wise he will come to a conclusion that the given guidelines are not correct.
9.Compatibility Testing: -
It is a type of testing in which one may have to deploy the application
in to the multiple number of environments prepared with different combinations of
environmental components in order to check whether the application is compatible with all
that environments. This type of testing is usually done to products.
11.Usability Testing: -
It is a type of testing in which one will check whether the application is
user friendly or not and it can be comfortably used by the end user or not.
bandaru7778@gmail.com 1
Page 20
14.Port Testing:-
It is a type of testing in which one will deploy the application in to the
clients environment and check whether it is compatible with that environment or not.
15.Reliability Testing: -
It is a type of testing I which one will perform testing on the
application continuously for long period of time in order to check the stability of the
application
16.Security Testing: -
Its is a type of testing in which one will concentrate on the following
areas of the application
a. Authentication Testing
b. Direct URL Testing (Uniform Resource Location)
c. Fire Wall Leakage Testing.
bandaru7778@gmail.com 2
Page 21
It is a type of testing in which one will enter as one level of user and try
to access the other level of unauthorized pages in order to check whether the firewalls are
working properly or not.
They are…
bandaru7778@gmail.com 2
Page 22
• Test Planning
• Test Development
• Test Execution
• Result Analysis
• Bug Tracking
• Reporting
Plan: -
It is a strategic document, which describes how to perform a task in an
effective, efficient and optimized way.
Test Plan: -
It is a strategic document, which describes how to perform testing on an
application in an effective, efficient and optimized way.
Optimization: -
Optimization is a process of utilizing the available input resources to their max and getting
maximum possible out put.
1.0 Introduction
1.1 Objective
1.2 Reference Document
bandaru7778@gmail.com 2
Page 23
Coverage Of Testing
Features To Be Testing
Features Not To Be Testing
Base criteria
4.1 Acceptance criteria
4.2 Suspension criteria
8.0 Scheduling
11.0 Assumptions
bandaru7778@gmail.com 2
Page 24
1.0 Introduction: -
1.1 Objective: -
The Purpose of the document is clearly described here in this section
Test strategy is defined as an organizational level term, which is used for testing all
the projects in the organization.
Test Plan: -
It is defined as a project level term, which is used for testing a particular project in
the organization.
Note: - Test strategy is common for all the projects but the test plan is
specific for a particular project
bandaru7778@gmail.com 2
Page 25
The list of all the types of testing that are followed in that company will be listed out
here in this section.
3.6 Terminology: -
The list of all the terms and the meaning that are used in that company will be listed
out here in this section
bandaru7778@gmail.com 2
Page 26
The list of all the documents that are to be prepared during the testing phase will be
listed out here in this section.
Eg: Test case, defects profile document.
8.0 Scheduling: -
The starting dates and the ending data of the each and every tasks is clearly planned
here in this section.
Example:
Risks:
i. Unable to deliver the soft ware with in dead lines.
ii. Employees may leave the organization in the middle of the
project
iii. Customer may impose the dead lines.
iv. Unable to test all the features with in the time.
v. Lack of expertisation
bandaru7778@gmail.com 2
Page 27
11.0 Assumptions: -
The list of all the assumptions that are to be assumed by the test engineer will be
listed out here in this section.
LLI (Low-level
Information) USE CASES
Screen Shots
Use Cases:
bandaru7778@gmail.com 2
Page 28
i. Screen shot
ii. Functional requirements
iii. Special requirement/Business rules/Validation
iv. Template
i. Screen Shot: -
User name
Password
Connect to
a. Initially whenever the login screen is Invoked Login, clear buttons must be
disabled.
b. Cancels Button must be always enable.
c. Up on entering user name and password the login button must be enabled.
d. Up on entering some information in to any of the fields the clear button must be
enabled
bandaru7778@gmail.com 2
Page 29
e. The Tabbing order must be user name, Password, Connect to, Login, clear,
cancel.
iv. Use Case Template:
Name Of The Use Case :
Brief Description of Use Case :
Actor’s Involved :
Special Requirements :
Pre Condition :
Post-Conditions :
Flow of Events :
1.Explicit Requirements: -
The Requirements that are directly given by the customer are known as
explicit requirement.
2.Implicit Requirement: -
The requirements that are analyzed by the business analyst feeling that they
will add the value (user friendliness) to the application are known as implicit
requirements.
• Initially whenever the login screen is Invoked Login, clear buttons must be
disabled.
• Cancels Button must be always enable.
• Up on entering user name and password the login button must be enabled.
• Up on entering some information in to any of the fields the clear button must
be enabled
bandaru7778@gmail.com 2
Page 30
• The Tabbing order must be user name, Password, Connect to, Login, clear,
cancel.
• Initially whenever the login screen is invoked the cursor must be available in the
user name field
• Upon entering in valid username, valid password and clicking on log in button an
error message should be displayed “Invalid username Please try again”
• Upon entering valid username, In valid password and clicking on login button an
error message should be displayed “Invalid Password Please Try again”
• Upon entering Invalid username, Invalid password and clicking on login button an
error message should be displayed “Invalid user name and password Please try
again”
Post-Conditions: Either home page or admin page for the valid user and error message
for the invalid users
1. Main Flow
2.Alternative Flow
3.Exceptional Flow
1.Main Flow:
Action Response
1.Actor invokes the application. 1.Login Screen is displayed with the following fields
Username, Password, Connect to, Login, Clear&
cancel.
2.Actor enters valid user name, Valid 2.Either home page or admin page is displayed
password and clicks on login button. depending up on the actor entered by authenticating.
3.Actor enters valid user name, valid 3.Authenticates,Either home page or admin page is
password, selects a database option and displayed depending up on the action entered with
clicks on login button. mentioned data base connection.
bandaru7778@gmail.com 3
Page 31
4.Actor enters invalid user name Valid 4.Go to Alternative flow table 1
password and clicks on login button.
5.Actor enters valid user name, Invalid 5.Go to Alternative flow table 2
password and clicks on login button.
Action Response
Actor Clicks on the cancel button. Login screen is close
bandaru7778@gmail.com 3
Page 32
• Identify the functionality of the use case with respect to the total functionality
Authentication
• Identify the functional points and prepare the functional point document.
Functional Point: -
The point where an user can perform some action is known as functional
point.
Testing Process: -
FRS FPD MTCD DTCD 1
DPD
UN-Entry 2
VLD Validate Login 3
PW-Entry
check 4
Login Click
Validate Cancel 5
Cancel Click
Check 6
Clear Click
Validate Clear 7
bandaru7778@gmail.com Check 3
Page 33
8 22 5 5
47
1 1
2 1
3 1
4 2
5 2
6 2
7 2
8 2
DID TCID
1 28
bandaru7778@gmail.com 3
Page 34
2 32
3 65
4 96
5 48
6 52
There are Two types of test cases if we see broadly they are:
1. GUI Test Cases
2. Functional Test Cases
bandaru7778@gmail.com 3
Page 35
(c)Test Procedure: -
DEF: It is a functional level term, which describes how to perform testing on
the functionalities of the application.
The plan for testing the functionalities is briefly described here in this
section
bandaru7778@gmail.com 3
Page 36
TC
ID TYPE Description Expected Value Actual Value Result Severity Priority Reference
Check for the availability All the objects must be All the objects
of all the objects as per available as per the are available as
the Login Obj Tab login obj tab per the login obj
1 GUI tab Pass
All the objects must be
consistent with each All the objects
Check for the constancy other are consistent
2 GUI of all the objects with each other Pass
Check for the spellings of
all the objects as per the All the objects must be All the objects
spelled properly as per
Login obj TabLogin Obj are spelled
the login obj tab
3 GUI Tab.xls properly Pass
Initially login, clear
Check for the enable must be disabled and Login, clear and
property of login, clear cancel button must be cancel buttons
4 GUI and cancel buttons enabled are enabled Fail
Initially the cursor must Initially the
be positioned in the cursor is present
Check for the initial user name field in the username
5 GUI position of the cursor field Pass
Enter some information in
to user name and
Login button must be
password field and check
enabled
for the enabled property of Login button is
6 Positive login button enabled Pass
Enter some info in to any
of the fields and check for Clear button must be
the enabled property of enabled Clear button is
7 Positive clear button enabled Pass
Corresponding
Corresponding page pages are
Enter user name, must be displayed as displayed as per
Password as per the VIT per the VIT valid in puts
8 Positive and click on login button table Pass
Corresponding
Corresponding page
pages are
must be displayed as
Enter username, displayed as per
per the VIT With the
Password as per the VIT the VIT with the
mentioned data base
and select a data base mentioned data
connection
9 Positive option and click on login base connection Pass
All the fields are
All the fields must be
cleared but the
cleared and the Cursor
Enter some information in cursor is not
should be placed in the
to any of the fields and placed in the
user name fields
10 Positive clear button user name field. Fail
bandaru7778@gmail.com 3
Page 37
Tabbing order is
as follows
Tabbing order must be
Username,
as follows User name,
Password,
Password, Connect to,
Connect to
Login, Clear, Cancel
Check for the tabbing Login, clear,
12 Positive order of all the objects Cancel Pass
Corresponding Corresponding
Enter username, messages should be error messages
Password as per the IVIT displayed as per IVIT are not displayed
13 Negative and click on login button as per IVIT Fail
Enter some information
only in to the user name
Login button must be
field and check for the
disabled
enabled property of login Login button is
14 Negative button enabled Fail
Enter some information
only in to the password
Login button must be
field and check for the
disabled
enabled property of login Login button is
15 Negative button enabled Fail
4 Login Button
5 Clear Button
6 Cancel Button
bandaru7778@gmail.com 3
Page 38
1 Suresh1 qtp Invalid User name Plz try again Admin Fail
Invalid User name Plz try
2 Raja2 rani Invalid User name Plz try again again Pass
Invalid password Plz try Invalid password Plz
3 Chiru DADA again try again Pass
Invalid password Plz try Invalid password Plz
4 Praveen TOPI again try again Pass
Invalid user name & Invalid user name &
5 NTR1 illu4 password Plz try again password Plz try again Pass
Invalid user name & Invalid user name &
6 Admin5 Admin6 password Plz try again password Plz try again Pass
In this phase the test engineer will compare the expected values with the actual values and
if both are matched they will document the result as pass other wise they will document the
result as fail.
bandaru7778@gmail.com 3
Page 39
Bug Tracking is a process in which the defects are identified, Isolated and managed
Defect –ID: -
Defect Description: -
What exactly the defect is clearly described here in this section.
Submitter: -
The name of the test engineer who has submitted the defect will be mentioned here in this
section.
Date Submission: -
The date on which the defect is submitted is mentioned here in this section.
Version No: -
Corresponding Version number is mentioned here in this section.
Build No: -
Corresponding build number is mentioned here in this section.
Assigned To: -
The development lead will fill the developers name for whom the defect is assigned.
bandaru7778@gmail.com 3
Page 40
bandaru7778@gmail.com 4
Page 41
1.Enter some
information in to any
Upon Clicking on of the fields
clear button all the 2.Click on clear
fields are cleared button
but the cursor is not3.Observe that the
placed in the user cursor is not placed
name field in the username
fields after clearing
all the fields
2 Sri Balaji 11-Feb-08 1.0.0 1
1.Enter Suresh1 in
to the user name
Upon entering
field 2.Enter
Suresh1 as
qtp in to the
username and qtp
password field
as password and
3.Click on login
clicking on login
button
button admin page
4.Observe admin
is displayed instead
page is displayed
of error message
instead of error
message.
3 Sri Balaji 11-Feb-08 1.0.0 1
1.Enter some
information in to
Up on entering the username field
information only in 2.Check for the
to the user name enabled property of
field login button is login button.
enabled instead of 3.Observe that login
being disabled button is enabled
instead of being
disabled.
4 Sri Balaji 14-Feb-08 1.0.0 1
1.Enter some
information in tho
Upon entering the password field
information only in 2.Check for the
to the password enabled property of
field login button is login button
enabled instead 3.Observe that login
being disabled button to enable
instead of being
disabled
5 Sri Balaji 11-Feb-08 1.0.0 1
bandaru7778@gmail.com 4
Page 42
Defect- Id: -
The list of defect numbers are mentioned here in this section
Defect Description: -
What exactly the defect is clearly described here in this section
Submitter: -
The name of the test engineer who has submitted the defect will be mentioned
here in this section.
Date Of Submission: -
The date on which the defect is submitted is mentioned here in this section.
Version No: -
Corresponding Version number is mentioned here in this section.
Build No: -
Corresponding build number is mentioned here in this section.
Assigned To: -
The development lead will fill the developers name for whomthe defect is
assigned.
Severity: -
How serious the defect is defined in terms of severity, Severity is classified in
to four types:
1.Fatal (Sev1) or S1 or 1
2.Major (Sev2) or S2 or 2
3.Minor (Sev3) or S3 or 3
4.Suggestion (Sev4) or S4 or 4
bandaru7778@gmail.com 4
Page 43
1.Fatal:
If at all the problems are related to the navigational blocks or unavailability of
functionality then such type of defects are treated to be fatal defect.
Val1
Main Menu Val2
Result UN
AVAILABL
ADD
E
Next
Next Next
2.Major: -
If at all the problems are related to the working of major functionalities then
such types of defects are treated to be major defects.
Val1 10
Val2 20
Result -10
ADD
bandaru7778@gmail.com 4
Page 44
3.Minor: -
If at all the problems are related to the Look & Feel of the application then
such type of defects are treated to be minor defects
Val1
Val2
Result
BAD
4.Suggestions: -
If at all the problems are related to the value of the application then such type
defects are treated to be suggestions.
Invalid
Some
+Ve integer Box Entry
alphabets
Plz Try
again
Priority: -
Priority defines the sequence in which the sequence in which defects has to be
rectified. It is classified in to four types
1.Critical (Pri1) or P1 or 1
2.High (Pri2) or P2 or 2
3.Medium (Pri3) or P3 or 3
4.Low (Pri4) or P4 or 4
Usually the Fatal defects are given critical priority, Major defects are given
High priority, Minor defects are given Medium Priority and suggestions are given Low
Priority, But depending up on the situations the priority will be changing.
I - Case:
Low severity-High Priority Case: -
Up on customer visit to the company all the look and feel defects are given
highest priority.
II - Case:
High severity –Low Priority Case: -
bandaru7778@gmail.com 4
Page 45
Testers
error
REQ
As per
design
No
Is it
Reall OP
y EN Rectific
DEV
Defe ation
ct
M1 Fixed for
Build #1 verification
Build #2
TESTING
Yes
If
Ne No
Def STOP TESTING
ect
w
Is
defect Yes
is Clos
RE really ed
ope No verifie
n d
bandaru7778@gmail.com 4
Page 46
Status: -
New: - When ever the defect is found for the first time the test engineer will set the status as
New.
Open: -When ever the developer accepts the raised defect then he will set the status as
open.
Fixed for verification Or Fixed for rectified: - When ever the developer rectifies the raised
defect then he will change the status to fixed.
Re open and Closed: -When ever the defects are rectified, next build is released to the
testing dept then the test engineers will check whether the defects are rectified properly or
not. If the defect is rectified properly then the test engineer will set the status as “Closed”.
If the defect is not rectified properly then the test engineer will set the status as “Re open”.
Hold: - When ever the developer is confused to accept or reject the defect then he will set
the status of the defect as hold.
Testers Error or Testers Mistake Or Rejected: - When ever the developer is confirmed it is
not at all a defect hen he will set the status of the defect as “ Rejected”.
As Per Design: - When ever the test engineer is not aware of new requirements and if he
raises defects related to the new features then the developer will set the status “ As Per
Design”.
Note: This is a rare case not usually Occurs
bandaru7778@gmail.com 4