Professional Documents
Culture Documents
1.
2.
3.
4.
Why
Who
Stuf
Communication skills
Confidence
Dynamism
Project:
Product:
It is some thing that is developed based on the companies specification and
used by the multiple customers (e.g.: Thirupathi laddu)
Quality:
bandaru7778@gmail.com
Page 2
Software Development Life Cycle (SDLC):SDLC contains six phases they are
1. Initial phase or requirements phase.
2. Analysis phase
3. Design phase
4. Coding Phase
5. Testing Phase
6. Delivery & Maintenance Phase.
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.
II.
Analysis Phase:
(a) Tasks:
1.Feasibilty Study
2.Tentative planning
3. Technology Selection
(b) Roles:
4. Requirement Analysis
System Analyst, Project Manager, and Team Manager.
Process
1. Feasibility Study: - It is detailed study of the requirements in order to
check weather the requirements are possible or not.
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.
SRC- System requirement specification
Roles: High-level designing is done by the chief Architect & Low level
designing is done by the Technical Lead
bandaru7778@gmail.com
Page 4
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.
V.
Testing Phase:
(a) Task: Testing
(b) Roles: Test engineers
Process:
1. First of all the test engineers will collect the requirements
document and try to understand all the requirements
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
bandaru7778@gmail.com
Page 5
6. If at all any defects are found. They will list out all of them
in a defect profile template then
7. They will sent the defect profile document to the
development department and then will be waiting for the
next build to be released.
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 .
10. This process continuous till the product is defect free.
Proof: The proof of the testing phase is Quality Product.
Test Case: (def) Test case is an idea of a test engineer based on the customers
requirements in order to test a particular feature or a function.
Delivery:
(a) Task: - Installing the application in the clients environment
(b) Rolls: -Deployment engineer or Senior test engineers.
Process: - The senior test engineer or deployment engineer will be going to the
clients place and install the application in their environment with the help of the
guidelines provide in the deployment document.
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.
bandaru7778@gmail.com
Page 6
************************^^^^^^^^^^^^^^^^^^^************************
Where exactly the testing comes in to picture?
Which sort of testing you are expecting?
How many sorts of testing are there?
There are two sorts of testing.
1. Un-conventional testing
2. Conventional testing
1.Un-conventional Testing: -Unconventional testing is a sort of testing done by
the quality assurance people, in which they test each and every out come document
right from initial phase of the SDLC (Soft ware development life cycle)
2.Conventional Testing: It is sort of testing done by the test engineers on the
application in the testing phase of SDLC.
Testing
(a) Black-Box Testing: If one performs testing only on the functional part of
an application with out having any structural knowledge then tat method of
testing is known as Black-Box testing, usually the test engineers perform it.
(b) White-Box Testing: If one performs testing on the structural part of an
application then that method of testing is known as white box testing, usually
the developers or white box testers 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.
bandaru7778@gmail.com
Page 7
Levels of Testing:
There are five levels of testing
1. Unit Level Testing
2. Module Level Testing
3. Integration Level Testing
4. System Level Testing
5. User Acceptance Testing (U.A.B)
1.Unit Level Testing: It is a level of testing in which one will perform testing on the units. It is a
white box testing and usually developers or white box testers will perform.
2.Module Level Testing: Module: Module is defined as a group of related functionalities to perform a major
task
It is a level of tasting in which one will perform testing on the modules. It is a black
box testing and usually test engineers perform it.
3.Integration Level Testing: It is a level of testing in which the developers will develop some interfaces to
integrate the modules and test whether the interfaces are working fine or not. It is a
white box testing usually developers or white box tasters perform.
The developers may follow one of the following approaches while integrating
the modules.
1.Top-down approach
2.Bottom up approach
3.Hybrid or Sandwich 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
bandaru7778@gmail.com
Page 8
3.Hybrid approach Or Sandwich approach:- This is a mixed approach of
both the top down and bottom up approaches
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
5.System integration Testing: It is a type of testing in which once the complete application is developed one
will perform an action at one module and checks for the reflections at the
corresponding modules. It is a black box testing and usually test engineers
perform.
6.User- Acceptance Testing: It is the level of testing in which one will perform the same system testing in
the presence of the user in order to make him accept the application. It is a black
box testing and usually Test engineer performs it.
Environment: - Environment is a combination of three layers (e.g.: Yahoo)
a. Presentation layer
b. Business layer
c. Data base Layer
bandaru7778@gmail.com
Page 9
ACTIVIT
OUTCO
Req.gathering
BRS
ANALYSIS
Sys.design
SRS
DESIGN
S/w design
TDD, GUI
UTR
CODING
TESTING
DEL&MAINT
Implementation
Unit test
Int. test
UTR
Mod Test
Sys.Test.
UAT
UTR
UTR
UTR
Delivery to
client
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
(b) Prototype Model: Unclear Req
Prototype
SRS Doc
Base lined
Client environment
confirmation
H/Wprototype
H/Wprototype
S/WPrototepe
H/Wprototype
REQ.are
BRS DOC
Refined
Baseclear
Lined
Whenever the customer is not
with the requirements this is the best
Advantages: -
Page 10
Evolutionary Model:
Initial Req
N
Dev.
Application
User
validation
User
accept
Advantages: Whenever the customer is evolving the requirements this is the best
Suitable model.
Drawbacks:
Refining &
Planning for the
next cycle
Advantages: -
Implementation
This is the best suitable for developing the highly risk based project
(scientific projects)
10
bandaru7778@gmail.com
Page 11
Drawbacks:
(C)
Req. Gathering
Design
Delivery &
Maintenance
Coding
Sys testing
SRS
BRS Review
SRS Review
HLD
LLD
SCD
TDD Review
Black
White box
testing
Box
testing
Test S/W
Changes
Advantages: This is the best suitable for developing the highly risk based project(scientific projects)
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.
Validation
11
Page 12
BRS
SRS
Design &
coding
Test
TDD
SCD
S/W Build
Testing
System testing
Test management Process
User acceptance testing
Port Testing
S/W efficiency
DRE=A/A+B
2.Regression Testing: It is a type of testing in which one will perform testing on the already tested
functionalities again and again.
bandaru7778@gmail.com
12
Page 13
It is usually done in two scenarios.
1. Whenever the testers has raised the defects, rectified by the developers and next
build is released to the testing department then the test engineers will test the
defect functionality as well as the related functionality once again.
2. When ever some new features are incorporated by the developers, next build is
released to the testing department then the test engineers will once again test the
related functionalities of the new features in order to confirm that they are
working same as previous.
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.
4.
- Testing (Alpha Testing): It is a type of user acceptance testing in which the test engineers will test the
application in our company, in the presence of the customer.
Advantage: - If at all any defects are found then there is a chance of rectifying them
immediately.
5. -Testing (Beta): It is a type of user acceptance testing done in the clients place either by the endusers 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.
bandaru7778@gmail.com
13
Page 14
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.
10. Monkey Testing: It is a type of testing in which one will perform abnormal action on the application
intentionally in order to check the stability of the application.
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.
12. Exploratory Testing: It is a type of testing in which one will (Domain Experts) will perform testing on the
application with out having the knowledge of requirements but by exploring the
functionality.
13.End-To- End Testing: It is a type of testing in which one will perform testing on all the end- to-end
scenarios of the application.
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
bandaru7778@gmail.com
14
Page 15
b. Direct URL Testing (Uniform Resource Location)
c. Fire Wall Leakage Testing.
Test Planning
Test Development
Test Execution
Result Analysis
Bug Tracking
Reporting
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.
15
Page 16
1.1 Objective: The Purpose of the document is clearly described here in this section
1.2 Reference Document: The list of all the documents that are refereed to prepare the test plan will be
listed out her in the section.
2.0 Coverage Of Testing: 2.1 Features to be tested: The list of all the features that are to be tested in this phase will be clearly
mentioned here in this section.
2.2 Features not to be tested: The list of all the features that are not planned for testing based on the
following criteria will be listed out here in this section
a. Out of scope features
b. Low risk features
c. The functionalities that are planned to be incorporated in future
d. The features that are to be skipped based on the time constraints.
3.0 Test Strategy: 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
3.1 Levels of Testing: The list of all the levels of testing that are followed by that company are listed
out here in this section
3.2 Types of Testing: The list of all the types of testing that are followed in that company will be
listed out here in this section.
3.3 Test Design Techniques: Technique: Technique is some thing i.e., used for accomplishing a complex task in an
easy manner.
A list of all the techniques that are used by that company while developing
the test cases will be listed out here in this section.
bandaru7778@gmail.com
16
Page 17
Eg: - BVA (Banded value analysis)
ECP (Equivalence Class Partition)
3.4
3.5 Test Metrics: The list of all the metrics that are maintained 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
3.7 Automation Plan: The list of all the areas that are plan for automation in that company will be
listed out here in this section.
3.8 List Of Automated Tools: The list of all the automated tools that are used in that company will be listed
out here in this section.
4.0 Base Criteria: 4.1 Acceptance Criteria: When to stop testing feeling that enough testing has been done on the
application is clearly described here in this section.
4.1 Suspension Criteria: When to suspend testing suddenly (abruptly) will be clearly mentioned here
in this section.
5.0 Test Deliverable: 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.
6.0 Test Environment: The customer specified environment would be clearly described here in this
section. The same environment will be simulated in the company and will be used
for testing purpose.
7.0 Resource Planning: Who has to do what is clearly described here in this section.
17
Page 18
The starting dates and the ending data of the each and every tasks is clearly
planned here in this section.
9.0 Staffing& Training: How much staff is to be recruited and what kind of training is to be provided
is clearly described here in this section.
10.0 Risks & contingencies (Solution Plans): The list of all the potential risks and the corresponding solution plans will be
listed out 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
dead lines.
iv. Severity & Priority based testing.
v. Proper Training needs to be provided.
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.
12.0 Approval Information: Who has to approve what is clearly described here in this section.
18
Page 19
USE CASES
Use Cases:
Use case is a description of functionality of certain features of an application
in terms of actors, actions& responses
Input information required for preparing the use case Document: i.
ii.
iii.
iv.
i.
Screen shot
Functional requirements
Special requirement/Business rules/Validation
Template
Login
Clear
Cancel
ii. Functional Requirements: a. Login screen should contain username, password, Connects To fields
and login, clear, cancel buttons.
b. Connect to is not a mandatory field but when ever user requires it
should allow him to select a data base option.
c. Up on entering valid username, valid password and clicking on login
button corresponding page must be displayed.
d. Up on clicking on the clear button the information present in all the
fields must be cleared and the cursor must be available in the user
name field
e. Up on clicking on the cancel button login screen must be closed.
bandaru7778@gmail.com
19
Page 20
a.
b.
c.
d.
e.
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
The Tabbing order must be user name, Password, Connect to, Login,
clear, cancel.
:
:
:
:
:
:
:
Actors Involved:
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.
bandaru7778@gmail.com
20
Page 21
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
1. Main Flow
2.Alternative Flow
3.Exceptional Flow
1.Main Flow:
bandaru7778@gmail.com
21
Page 22
Action
Response
Response
Response
bandaru7778@gmail.com
Response
All the fields are cleared and cursor is
placed in the user name fields
22
Page 23
Response
Login screen is close
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.
bandaru7778@gmail.com
23
Page 24
Test Objective: The main purpose of the document is described here in this section
(b)
Test Scenarios: -
bandaru7778@gmail.com
24
Page 25
The list of all the scenarios that are to be tested will be listed out here
in this section.
(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
(d)
Test Data: The date that is required for testing is made available here in this
section
(e)
Test Cases: -
TYPE
GUI
GUI
GUI
Description
Expected Value
Actual Value
bandaru7778@gmail.com
Pass
Pass
25
Page 26
GUI
10
11
12
13
14
15
GUI
Login button is
enabled
Clear button is
enabled
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
Positive and click on login button
table
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
Positive option and click on login
base connection
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
Positive clear button
user name field.
Pass
Pass
Pass
Pass
Fail
bandaru7778@gmail.com
Corresponding
messages should be
displayed as per IVIT
Corresponding
error messages
are not displayed
Fail
as per IVIT
Login button is
enabled
Fail
Login button is
enabled
Fail
26
Page 27
Obj Name
Type
1 User name
Text Box
2 Password
Text Box
3 Connect To
Combo box
4 Login
Button
5 Clear
Button
6 Cancel
Button
Password
Expected Page
Actual value
Result
Suresh
qtp
Admin
Admin
Pass
Raja
rani
Home page
Home page
Pass
Chiru
mbbs
Home page
Home page
Pass
Praveen
puppy
Home page
Home page
Pass
NTR
illu
Home page
Home page
Pass
Admin
Admin
Admin
Admin
Pass
Actual value
Result
Suresh1
qtp
Admin
Fail
Raja2
rani
Pass
Chiru
DADA
Praveen
TOPI
NTR1
illu4
Admin5
Admin6
bandaru7778@gmail.com
Pass
Pass
Pass
Pass
27
Page 28
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.
Bug Tracking is a process in which the defects are identified, Isolated and managed
Defect ID: -
28
Page 29
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.
Defect Id
Defect
Description
Steps for
Date Of
Version Build
Reproducibility Submitter Submission NO No
Assign
to
SeverityPriority Status
Not Applicable
Sri Balaji
11-Feb-08
1.0.0 1
Sri Balaji
11-Feb-08
1.0.0 1
Sri Balaji
11-Feb-08
1.0.0 1
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 not 3.Observe that the
placed in the user cursor is not placed
name field
in the username
fields after clearing
all the fields
2
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.
bandaru7778@gmail.com
29
Page 30
Up on entering the
information only in
to the user name
field login button is
enabled instead of
being disabled
4
1.Enter some
information in to
username field
2.Check for the
enabled property of
login button.
3.Observe that login
button is enabled
instead of being
disabled.
1.Enter some
information in tho
password field
2.Check for the
enabled property of
login button
3.Observe that login
button to enable
instead of being
disabled
Sri Balaji
14-Feb-08
1.0.0 1
Sri Balaji
11-Feb-08
1.0.0 1
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
Steps for reproducibility: The list of all the steps that are followed by the test engineer to identify
the defect will be listed out 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.
bandaru7778@gmail.com
30
Page 31
Severity: How serious the defect is defined in terms of severity, Severity is
classified in to four types:
1.Fatal
2.Major
3.Minor
4.Suggestion
(Sev1) or S1 or 1
(Sev2) or S2 or 2
(Sev3) or S3 or 3
(Sev4) or S4 or 4
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
Val2
Main Menu
Result
UN
AVAILABL
E
ADD
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
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
bandaru7778@gmail.com
BAD
31
Page 32
4.Suggestions: If at all the problems are related to the value of the application then such
type defects are treated to be suggestions.
+Ve integer Box
Some
alphabets
Invalid
Entry
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: When ever 80% of the application is released to testing department as
20% is missing the test engineers will treat them as Fatal defect but the development
lead will give least priority for those defects as features are under development.
bandaru7778@gmail.com
32
Page 33
REQ
As per
design
No
Is it
Reall
y
Defe
ct
DEV
OP
EN
Rectific
ation
M1
Build #1
RE
ope
bandaru7778@gmail.com
Nen
Is
defect
is
TESTING
really
If
verifie
Defect
d
Fixed for
verification
Build #2
Clos
STOP TESTING
ed
33
Page 34
Yes
No
Yes
No
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.
bandaru7778@gmail.com
34
Page 35
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
35