Testing Material

What is Testing?
Testing:
Testing is the validation or verification of a
predefined set of rules, conditions, criteria or
attributes
Copyright 2011 | People Tech Group

www.PeopleTechGroup.com
Objectives of testing
Testing
To validate requirement
To identify missing requirements
To identify additional requirements
Defect
A Defect is any form of variance from a predefined
set of rules, conditions, criteria or attributes
A Defect may also be referred to as a deficiency or
bug
Why do bugs occur:

Human errors
In experience
System complexity
Computer do not think, they need to be told

Why test software

Provide information to programmers so they
can prevent bugs

Provide information to management so they
can evaluate the risk of using an object
To achieve a bug-free object as warranted by
the situation Break the software
Show that software works
To enhance the quality of whatever it is that
has been built
Testing Principles
Timely
Balanced
Provable
Repeatable
Sensible
Clarity of Roles

Timely
The earlier that defects are identified in the Testing Life
Cycle the less cost is associated with fixing it.
Balanced
The effort required in testing must be balanced with the
time, budget and resources available
It is imperative that significant effort is spent on testing
functions that are deemed necessary or critical rather
than those that are considered nice to have
Provable
The results of testing must be provable in
order to create an audit trail

The results of testing must be provable in
order to assist developers with problem
identification
i.e. prove the existence of defect
Repeatable
Testing must be repeatedly in order verify
(retest) tests identifying defects.
Sensible
It is not feasible to test every thing
It may be necessary to identify when enough
testing has been done

Test critical functions more thoroughly then
less critical functions
Clarity of roles
A clear distinction of roles and responsibilities
reduces replication and ensures maximum
coverage
Test Strategy
PTM
Test Plan
PTL
Test Scenario
STA
Test Cases
TA
Test Scripts
Testers
Execution
Test Strategy Document

Based on project requirement (different
departments, scope of project, resources and
time ) and project character (version, time
from, resources, feasibility study), project test
manager will prepare the strategy.
<Project Name> Here we will mention the project name
<Version No>

10
Strategy
Initialize
Version
Sign Off
PTM
1.0
PM or BA
Initialize: This column shows the creator of document

Version: Gives the version of the project
Sign Off: Once the project is verified , signed by PM,BA
KeyPerson
Accountability
Peter
Project Manager
Lilly
Project Test Manager
Jack
Test Lead
Sam
Test Analyst
Eric
Tester
Key person: in this column P.T.M will mention the person

name on a particular project.
Accountability: in this column P.T.M will mention the role
of key person on project

12
1. Overall test scope: Based in BRS document project

test manager will look what are the resources needed
for project and estimate the project for testing
Here resources means
Time How much time will take to test the project.
Manager How many testers will work on the project.
Budget Estimate the budget to test the project.

13
2. Test phases :
This section shows the what type of tests perform on
the project, like system test and U.A.T test and why
these test are performing on project.
3. Roles and Responsibilities :
It shows the staffing assumptions for the project.

14
Roles and Responsibility

S.No
Role
Responsibility
Project Test Manager
Understand SRS
Prepare test strategy
Review Test plan
Project Test Lead
Prepare test plan

Review Test plan
Understand summary document
Senior Test Analyst
Prepare test scenario

Prepare Defect Report
Test Analyst
Prepare test cases

Prepare test scripts
Tester
Test the script

execution

15
4. Test environment :
What type of front End, Backend, internet,
networking used for the testing.
F/E =Asp.Net
B/E = SQL-Server
OS =Windows
Internet = Netscape Navigator.
Band Width=512 kbps
Project Manager , System Analyst and IT
people will involve in this.
16
5. Deliverable and expectations:
It shows what type of deliverables deliver to the

client on periodic basis
Test strategy
Test plan
Test scenarios
Test cases
Test strategy
Test plan
High level document

System Testing
SIT
UAT
Test scenarios
Test Results
Defect Summary Report
Test cases
Test Scripts

17
6.Management of test problems :
In this section describes, how to manage the test

problem during testing.
Procedures :
how to send
1.Defect Raised
whom to send
what to send
2.Retesting we can minimize the problem
Daily
3.BackUp
Weekly
Monthly
18
By incidence management or defect tracking
system (tool) tester will send the defect to

development team. Developer fix the defect
and send back to testers. Testers Retest
again and take the backup for further
reference.

19
7.Risks & mitigations:

During testing the project what type of risks will come
and what are the solutions for that risks are
mentioned here.
Time
1. Deadlines
Budget
2. Test lead may leave in between the project.

3. Unavailability of software tools.
4. Test data is not available on time.
5. Application response is very high.

20
Risks
Constraint
12 Crores coming for 2 Over Budget

Years
2 Years 2 Months
Delivery Late

Mitigation
Reduce Expenses
No of Emp may reduced
No of Emp goes
increased
21
8.High Level Schedule:

This section defines the detail schedule of the
entire project.
Knowledge Week1
Transfer
Week2
Week3
Week4
Client
meeting with
entire project
team
PTM with
team
members
PTL test plan

22
Test Plan Document

The purpose of Test plan is to define scope,
approach, reasons and scheduling of testing

activities in a project. The test plan will
describes the features to be tested in an
application, the resources and their
responsibilities involved in a project. This
document is prepared by testing head.

23
1. Definition of scope or Objective of Testing:
In this section test lead define the purpose of the project, object
of the document, project description and modules.
Requirement
Functional req.
System req.
Client req.
Cost
U.A.T
S.T
S.I.T
Time
UAT - 6months
ST - 2months
SIT - 4months
Manpower
10men
Plan
Scenario
Cases
Scripts
Test plan- 1
scenario - 1
Cases - 4
Scripts - 6

24
2. Identification of entry Criteria and exit Criteria

Entry Criteria : Inputs are entry criteria.
e.g. For creating test plan, requirement document is entry criteria
Exit Criteria : output are : Exit Criteria.
e.g.: Completion of Test plan document .
Understanding SRS(Entry criteria)

Preparing Scenarios by Use cases
Smoke Testing
Scripts
Sign Off(Exit Criteria)
25
3. Testing Approach:
In this phase, Test lead , decide what modules are
going for manual testing and what modules are going
for Automation Testing and which tools we want to
use is mentioned here and what type of testing will be
performed on particular module.
Unit testing
Integration testing
System testing
UAT Testing

26
Functional
Non-Functional
Manual
Automation
M1
M3
M2
M4
M6
M5
M7
M8
M10
M9

27
4. Process to be followed in Executing & Managing

approach:
In this section it defines what process we are going to
follow to execute the (Test Cases) and how to manage
the project
BRS
Use Case
SRS
Use Case document is prepared

Test Scenario is Prepared
Test Case is Prepared

28
Iterations
Unit
Testing
ST
SIT
Defect %
Cycle1/Build1
____
_____
____
70%
Cycle2/Build2
____
_____
____
35%
Cycle3/Build3
____
_____
____
8%
UAT
____
_____
____
0.5%
Testing the defect on the modified build is

Regression Testing

29
5. Preparation of Test data :

To Test the application, Test Administrator or
Developer will prepare the test data. Document are
specified here.
6. Preparation of Test environment :
To test the application, what is the hardware
configuration and software configuration used is
mentioned here
H/w configuration : 32 MBRAM
S/w configuration : Win98, Ms-word, Excel.
Tools : QTP, Load Runner.
30
7. Risks :
Time
1.Deadlines
Budget
2.Test lead may leave in between the project

3.Unavailability of s/w tools.
4.Test data is not available on time.
5.Application response is bad

31
8. Schedule (daily) and Resource management.

Day
Work
Assigned
Test Plan
Rajesh
Test Scenario
Sanjay

32
Test Case Document

Test cases can be designed on use cases
and functional specification.

We can also design Test cases based on
screenshots and functional specifications.
Use case:- Definition:- Use case describes
how to access the functionality in the system
or application, i.e. user interaction w.r.to a
system

33
Use case consists of following contents :

(i) Use case name :
(ii) Objective :
(iii) Pre condition : It describes the necessary
steps that should be verified before starting
the testing process
(iv) Post Condition :It describes the successful
Test condition after the Test execution.

34
(v) Normal flow : It describes the flow of events

to access the AUT.
(vi)Alternate flow: The alternate condition
(vii) Exceptions : It describes the error
messages which may be occurs during the
testing process.

35
Functional specifications : This document

describes the validation of each I/P object in
the AUT
Ex: Username in the login page accepts 4 to
20 characters.
Test case : Def : Test case is a document
which consist of description, I/P data or test
data and expected results
36
In Test case scenarios are created

Login Scenario
How many ways Login is done, different test
cases is made.
Test Case
UserId
Password
TC_1
Fail
Pass
TC_2
Pass
Fail
TC_3
Fail
Fail
TC_4
Pass
Pass

37
It contains a clear information of what to
make the quality oriented product.

What is best case approach. If we write test
case that should be understand even by
Layman.

38
Test case template

Phase Name
TC_Id
StepNo
Responsible Tester
Descrip
tion(wh
at to
do)
Expect
ed
Actual
result

Status
Execn
Date
Assigne
d Date1
39
Notes :- Q) Difference b/w use case & Test

case?
A) Use case how to access the functionality
Test case used to verify the in depth
functionality of the AUT, to check whether it
is working properly or not. It is mainly used
to validate the Use case
In this Test case design, tester can use
Black box testing technique like
Equivalence class partitioning (ECP)
Boundary value Analysis (BVA).
40
Equivalence class partitioning (ECP)

In this method we can divide the type of input
class into equal partitions or classes that is
valid and invalid.
Ex: User Name accepts 4 to 20 characters
Valid Class
Invalid Class
ECP:
4 Char
<4
20 Char
> 20
4-20 Char
0-9 Special Char Alpha Numeric

41
Boundary Value Analysis (BVA):
It is used to analyze the I/P data at boundary

conditions
Ex: If the data is w.r.to range m-n then
(say 4-20 Char)
Min: m-1=3 (Fail)

m=4 (Pass)
m=5(Pass)
Max: n-1=19 (Pass)
n=20 (Pass)
n+1=21 (Fail)
42
Q: Verify the functionality of check mail option in

the inbox page of Yahoo
Sol: Use case:
Use case name: Check mail
Pre condition: Successful Login
Post condition: Mail list should display
Normal flow:
Invoke the browser
Specify the URL
Enter the Uid, Pwd
Click on check mail
43
Alternate flow:
Invoke the browser
Specify the URL
Enter the Uid, Pwd
Click Signout
Exception:
Invalid URL
Invalid Uid,Pwd
Functional Specification:
Uid accepts 4-10 Characters
Pwd accepts 5 digit

44
Bug
Why does Bug occurs?
Due to miscommunication or no
communication
Software complexity
Programming errors
Changing requirements
Time Pressure
Human error
In experience

45
Defect Tracking Life Cycle

Application will be tested
If Fail
If
Passed
Stop Testing
Raise a defect or Error
Retest
Reason for not being a
defect will be given
Cancelled
No
Is that a
genuine
defect
Yes
Fix the defect
Differed (Next release)
Will be fixing it in next

release

46
Bug:
A fault in a program which causes the program

to perform in an unintended form or
unanticipated manner. It is also known as
deficiency or bug.
Bug Status:
Bug status may be New, Open, Fixed, Closed,

Reopen, Differed.

47
Bug status is New when testers reports a
defect, status is Open when developers

accept that it is a bug or if the developers
rejects the defect, Fixed when developers
make changes to the code to rectify the bug.
Closed or Reopen when testers test it again
for the expected result shown up, it is turned
into Close & if the problem persist again it is
Reopened

48
Differed Status
It means the developer accepts the bug or

problem, but it is scheduled to rectify in the
next build.
Defect_Id
Defect
Description
Defect Status

Severity
Priority
49
What is Testing?
Testing
Testing is the validation or verification of a
predefined set of rules, conditions, criteria or
attributes

50
Difference between Manual and

Automated Testing
Manual Testing
Automated Testing
1.Takes more time
Takes less time
2.Cannot generate accurate results
Can generate accurate results
3.Requires more No: of personal

requirements
Does not Requires more No: of

personal requirements
4.Requires more No: of H/W, S/W
Does not Requires more No: of H/W,

S/W
5.Repeatability is not possible for

more No: of time
It is Possible
6. Project size is small
Project size is large

51
Testing Levels
Unit Testing
Integration Testing
System Testing
User Acceptance Testing

52
Unit Testing
Unit testing :This kind of Testing is done by
the developers to verify the internal structure
of each individual module based on LLDD
using white Box Testing techniques consists
of individual stones )
(if, switch)
(for, while, do-while)
(set of stmts which are interlinked)
(no of individual paths based on graphs)

53
Basic path testing

Conditional coverage
Loop coverage
Branch coverage
Cyclomatic complexity
Lowest-level component, program,

subprogram test. Unit testing verifies that the
unit works correctly based on some predefined
minimal set of requirements
Unit testing is usually performed in a
development end environment using test data.
It is usually performed by programmers.
Smallest part is unit. Testing the smallest part
of an application. Its a kind of grey box testing.
Unit testing wont be given to Black box tester
55
Integration Testing
This testing is done by the developers by integrating
or combining the individual modules based on HLDD

to form the integrated sub system using white box
testing technique.
Integrated Testing consists of
Incremental Integration
Top-Down approach
Bottom-Up approach
Sandwich approach
Non Incremental Integration

Big Bang approach

57
Top-Down approach
In this approach testing can be done on the

integrated subsystem from higher level modules to
the lower level modules. In this approach if any
module is under implementation, then stubs can
be used as a temporary function to perform the
task.
Bottom Up approach
In this approach integration can be tested from
lower level modules . In this approach to create an
interface between low level to high level modules
we can use drivers

58
Sandwich approach
It is the combination of both the top-down and

bottom-up approach.
Big-Bang approach
In the Big-Bang approach all the individual

modules will be integrated in a single stage

59
In the Bottom-Up approach, the errors can be
rectified easily.
Integration testing is also done by the testers
to verify the functionality of the interface
which combines one or more modules.
Ex: of Integration testing
Window based
Web based
Data base also

60
System Testing
This kind of testing is done by the system
engineer to verify whether the system meets

all its requirements or not (SRS), the tester
can use black box test technique on the build
or exe to verify both functional and nonfunctional requirements.
This testing is based on functional
requirements (FSD or SRS or BSD)

61
System Requirements
Functional
Non-Functional
Functionality test
Installation test
Parallel test
Compatibility test
Configuration test
Performance test
User Interface(GUI) test
Security test

62
Functional Requirements
Functionality Testing
This testing is done to verify the behavior of

the AUT (Application Under test or build) as
per the functional requirements.
Ex:1. Button click

States message, error message
Confirmation message, Pop-up window
2. Check box, Radio button for selection
Checkbox for multiple selection

Radio button for single selection
63
Combo box
Drop down list, No: of list focused properly
Text box
We can verify the insertion of text or value in this
object and the properties are enabled, focused.
Multiline text control
It is used to verify to enter multiple lines of text.
Links
Valid link
ex: Correct page
Invalid link ex: Incorrect page
Broken link ex: Error page: Page not found
64
Tooltip (Help message)

Move the cursor on an option (Menu drop
down list)
Click on any option/menu
Images or Logos

65
Installation Testing
Testing is done to verify whether the S/W can

be installed properly or not using the following
properties
Installation guide
Size of S/W (Before installation)
Typical or Custom options
Wizards
Size of S/W (After installation)

66
Parallel Testing
Testing the same AUT or build on different

versions using the same test requirements like
input requirements, Business requirements to
observe the difference between those
versions. Track the results for each version
and create a test report.

67
Compatibility Testing
Executions of the different environments gives

the same result.
Testing the AUT functionality on different
customers expected environments
Ex: Browsers, Operating System

Different Browsers are: Internet explorer,
Netscape Navigator, Opera, Firefox, Mozilla, AOL
etc. Verification of the HTML page for the above
different browsers.

68
Configuration Testing
This testing is done to verify the system

functionality on different customer expected
H/W environment.

69
Non-Functional Requirements
Performance Testing
This testing is done to verify whether the

system meets all the performance limits or not.
We can use the following scenarios to perform
this testing
Load Testing
Stress Testing
Volume Testing

70
This testing is done using the parameters like
execution time or elapsed time, response

time, hits/sec, Latency.
Note:
Performance testing is also called as

Benchmark testing

71
Load Testing
It is used to verify the system performance

w.r.to the concurrent user(at a time) request.
It may be w.r.to different work loads and
different intervals of time.
Stress Testing
It is used to estimate the server/system

performance under peak load or more than
the customer expected load.

72
This testing is mainly done to verify whether

the system enters into abnormal condition or
not.
Ex: Submit concurrent user request w.r.to long
duration of time(i.e., 5Hrs / 10Hrs or
1Day/2Days )

73
Volume Testing
This testing is done to verify the system

performance under large volumes of data in
the Database.
Ex: Insert 1000,10000 records so on in the
Database at the same time.

74
User Interface Testing(GUI Testing)
In this testing we can verify the look and feel

properties or appearance of the AUI
Ex: Font and size of the labels, label names, No:

of objects, images, logos etc.
Security Testing
This testing is done to verify whether the AUT

is protected from the unauthorized users, i.e.,
we can verify authorization and authentication.
Ex: Password should be masked in the login

window.
75
User Acceptance Testing(Acceptance Testing)
This testing is done by the customer whether to

accept the product or not w.r.to his Business
requirements.
This testing is of two types
Alpha Testing
Alpha testing is done by the customer in the developer
environment to verify his business requirements.
Beta Testing
Beta testing is done by the customer in his own environment
or called as real/customer environment to verify his Business
requirements.

76
Test Case Execution

Smoke Testing
Functionality Testing
Retesting/Regression Testing
Performance Testing
GUI Testing
UAT Testing

77

Testing Material

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Testing Material

Uploaded by

Copyright:

Available Formats

What is Testing?

Copyright 2011 | People Tech Group

Why do bugs occur:

Copyright 2011 | People Tech Group

Why test software

can prevent bugs

Copyright 2011 | People Tech Group

order to create an audit trail

testing has been done

Test Strategy Document

Copyright 2011 | People Tech Group

Initialize: This column shows the creator of document

Project Test Manager

Key person: in this column P.T.M will mention the person

Copyright 2011 | People Tech Group

1. Overall test scope: Based in BRS document project

Copyright 2011 | People Tech Group

Copyright 2011 | People Tech Group

Roles and Responsibility

Project Test Manager

Project Test Lead

Prepare test plan

Senior Test Analyst

Prepare test scenario

Prepare test cases

Test the script

Copyright 2011 | People Tech Group

5. Deliverable and expectations:

It shows what type of deliverables deliver to the

High level document

Copyright 2011 | People Tech Group

6.Management of test problems :

In this section describes, how to manage the test

By incidence management or defect tracking

system (tool) tester will send the defect to

Copyright 2011 | People Tech Group

7.Risks & mitigations:

2. Test lead may leave in between the project.

Copyright 2011 | People Tech Group

12 Crores coming for 2 Over Budget

Copyright 2011 | People Tech Group

8.High Level Schedule:

Copyright 2011 | People Tech Group

Test Plan Document

approach, reasons and scheduling of testing

Copyright 2011 | People Tech Group

1. Definition of scope or Objective of Testing:

Copyright 2011 | People Tech Group

2. Identification of entry Criteria and exit Criteria

Understanding SRS(Entry criteria)

Copyright 2011 | People Tech Group

Copyright 2011 | People Tech Group

4. Process to be followed in Executing & Managing

Use Case document is prepared

Copyright 2011 | People Tech Group

Testing the defect on the modified build is

Copyright 2011 | People Tech Group

5. Preparation of Test data :

2.Test lead may leave in between the project

Copyright 2011 | People Tech Group

8. Schedule (daily) and Resource management.

Copyright 2011 | People Tech Group

Test Case Document

and functional specification.