MANUAL TESTING

By
ZEEESHAN ALAM KHAN
SOFTWARE TESTING

It is the process of checking any software application is meeting all the customer
requirements or not

QUALITY

When we have reached validating all the requirements and found application is defect
free then we can say project or product is quality.

PROJECT

Any software application is developed based on the single customer requirement then
we can say it is a project.
Ex: ICICI Application, Stitching Shirt

PRODUCT

Any software application is developing based on the software industry requirement then
we can say it is a product.
Ex: Windows XP, GMAIL
QUALITY ASSURANCE

It is the process of verifying all the standards and processes of company for giving right
product to the customer.
We are going to verify are we building the right product or not.

QUALITY CONTROL

It is the process of validating the application, based on the requirements and verify are we
building the product right or not.

VERIFICATION

It is a technique in quality assurance and we will verify the process for delivering the right
product to the customer.

VALIDATION

It is a technique under quality control, here we will do the actual testing for delivering
quality software to the customer.
 SOFTWARE DEVELOPMENT LIFE CYCLE

SDLC is divided into 6 phases for developing any software , we have to choose one of
the process for successfully delivering quality product to the customer. The phases as
follows:

Requirement
Analysis
Design
Coding
Testing
Delivery and Maintenance

REQUIREMENT

Participant: Business Analyst, PM, Technical Lead, Development Lead

Process: Based on the appointment date given by the client along with project manager,
development lead, technical lead( all are optional ) along with business analyst will go to
the client location and gather all the requirements of a customer.
After gathering the requirements from the client, they will come back to the
company and they will start documenting the requirements which is easily
understandable to all the teams. After that business analyst will share documented
requirements to the customer, he will verify all his requirements are covered or
documented and he will update to the business analyst if at all any requirements need to
updating documented requirements.
Once business analyst will get the approval from the client then he will give sign off to
the requirement document.

Output:
SRS - Software requirement specification
BRS - Business requirement specification
FRS - Functional requirement specification
BD - Business document
BDD - Business design document
ANALYSIS PHASE

1. Feasibility Study
2. Selection of Technology and Environment
3. Requirement Analysis
4. Team Building
5. Understanding Document
6. Planning
Feasibility Study:
As per the budget and time provided by the bidding teams here we are going to
cross verify whether we are able to complete entire project by above budget and time.
If there discussion demands any changes in the budget or time with the help of
business analyst they will take it to the customer.

Selection of technology and environment:

Project manager will discuss with the architects of development lead for
selecting the which technology is suitable for our project along with the environment
based on the type of project.

Requirement Analysis:
project manager , development lead, test lead are going to discuss with the
business analyst for understanding of the requirements more clearly, if at all they are
having any doubts or queries they are going to ask in this session.
Team Building:
Based on the understanding of the requirements in the above analysis phase,
they are going to find out how many number of resources are required for both
development and testing.
Based on the availability of resources they may use from the bench strength or
they may recruit from outside.

Understanding Document:
For understanding all the requirements business analyst is going to provide a
requirement sessions to the both development and testing teams.(nearly it will be for 7 to
10 days)
Based on the understanding they have to prepare their own understanding
document which is going to use for giving reverse knowledge transfer presentation to the
client.

Planning:
With the help of development lead and testing lead, project manager is going to
prepare plan and he will send it to the client for approval.

Participants: BA, PM, TL, Test Lead, Development Team, Test Team, Architects
Output: Understanding Document and Project Plan
Note: requirement query document is the document containing questions of both
development and testing people and then either development or test lead are going to
share this document to business analyst for update.

DESIGN PHASE:

Participants: Architects

Process: Based on the understanding of the requirements architects will prepare the
design documents which are going to use for developing the GUI part of the application
along with understanding of the application flow.

Output:
1. Design document
a) High level design document
b) Low level design document

Note: unified modelling language is used for creating the diagrams, flow charts with the
effective manner and easily understanding to the all team members.
CODING PHASE

Participants: development team

Process: Developing the programming statements

Output: Programming statements (build)

Note: it is a part of software containing some features and deliver to the testing team for
verifying the application functionality

SRN – Software/Service Release Note

TESTING PHASE

1. Test Plan
2. Test Scenario and test cases
3. Test Case execution
4. Results analysis
5. Bug Tracking
6. Reporting
Testing is the process for ensuring quality of the software and update to the client on
periodic basis about status of this software application.

Test Plan:
It is a document containing all the project activities under testing.
This document will tell us when and what need to do by the testing team.
Based on this document we are going to start activities accordingly.

Test Scenarios:
Usecases: Usecases are having diagram representation of actors, actions involved as
per the requirements(Architechs will prepare these diagrams).

Scenarios:
These are high level verification points or high level ways of testing the entire
application.
We need to derive test scenarios from requirements document and knowledge
of all the requirements.
Test Cases:
These are low level verification points which we need to derive from test
scenarios.
There is no mandatory need to derive few test cases. We can derive any number
of test cases based on the requirements.
Test cases having unique id, test steps, description, expected results, actual
results, comment section which will allow us to easily understand what we need to verify
in our application.

Test Case Execution:

Here we are going to validate all the low level verification points and going to
justify what is the quality of part or entire application.
Based on this if at all any test cases not meeting expected result then we have to
update issue to the development team.
Once development team fix above raised issues, then they will update to the
testing team so that we need to test again same feature whether it is working according to
the requirements or not.
Status Reports:
Based on the above test case execution, we need to update to the client
through daily status reports for the update daily activities and weekly status reports for
the update of week activities.
Based on these reports client will understand what is the stability of the part or
entire application.

100% Quality Software:

Based on the test case execution and if we have done with all the test cases
and there is no more number of defects opened then we can deliver 100% quality
software to the client and if we are able to do all these activities as per the test plan then
we can say we are giving quality software to the client in on time and on budget.

Delivery and Maintenance Phase:

Delivery:
Whenever testing phase is completed, it means all the test cases need to
execute by the testing team and there are no open defects with the development team
then we are going to deliver quality software to the client.
Based on the client, with the help of his own team going to deploy it in real
time environment so that it can be used by the end users.
Maintenance:

Whenever end users keep on working on our software, when they get any
issues which leads to stop their business then with the help of client or vendors they
are going to post those all issues to the specific development team for fixing.
The same process will continue number of years as per mentioned in
SOW(Statement of Work).
 Testing methodology

The number of methods of testing we used to do for getting quality on entire application
to find whether it is working according to the requirements or not.
There are 4 different methods we can use for ensuring application quality.

1. Static Testing
a. Review
b. Walk-through
c. Inspection
2. White Box
3. Black Box
4. Grey Box

1.Static Testing:
It is the type of testing done by the people who are having 100% knowledge on
entire project requirements.
Here we are going to check entire process and documentation as per the
company standards and process.
Review:

It is type of verification technique to check something is as per the requirements,

whether it is prepared according to the all the standards or not.
It is informal meeting and there is no prior intimation to the team members.
Review are divided into 2 types
1. Peer Review
2. Lead Review

Peer Review: This is the review done by the same designation people, will update us any
enhancements on the same document.

Lead review: This is the review done by all the test leads, he will go through the all the
team members documents and will update whether we are on right track to deliver the
right product to the client.

Walk-through:
It is more formal than review, here we are going to discuss about specific
document (requirements, test scenarios, test cases, test case results, defects ) whether
these all are according to the client requirements are not, we are going to verify.
Moderator will be sending a clear note to the members who are required with
prior intimation.
Inspection:
It is more formal then walk-through, separate quality assurance(QA) team is
going to inspect our standards and processes, whether we are following or not.
If at all they found anything not following by the company standards it should
be escalated to the higher management.

Ex: 1) Maintaining documents in configuration management tool

2) Using the company standard format for all documentations.
3) Sending the daily and weekly status reports to the client ( as per the discussion with
the client)

These all process verification will be handled by auditing department (QA Team)

White Box Testing:

It is type of testing done by the development team for restricting number of
defects moving from development phase to testing phase.
Development team will cross check or do testing through programming
source code and if at all they find any issues they will update or for those all and
updated software will be delivered to the testing team.
Black Box Testing:
It is a type of testing done by all the testing team through application GUI
based on the client requirements, they are able to find application is working
according to the given requirements.
Before getting the software for testing team will prepare the test scenarios,
test cases and perform the execution so that they are able to justify whether it is
working according to the requirements or not.

Grey Box Testing:

It is type of testing done by the team who are having knowledge on both
programming (developing the source code) and how to test the application (writing
test scenarios, test cases and execution).
Earlier days grey box testing will be done by the development team due to
budget saving with that process they could not able to deliver the quality projects to
the customers hence they are maintaining separate testing team.
 Testing Levels

Software development life cycle(SDLC), once software is developed by the development

team is giving to deliver to the testing team then we have to perform below levels of
testing for ensuring 100% quality for his project/product.

1. Module Level Testing

2. Integration Level Testing
3. System Level Testing
4. User Acceptance Testing
5. Pre-production Testing
6. Production or Production validating Testing

Module Level Testing:

Based on the features or functionality developed in the number of builds, testing team
have to test all these features or functionalities individually, they have to ensure each
feature or functionality or collection of features working according to the client
requirements.

Module: It contains collection of features and we are able to perform one specific
Operation or activity. In this level of testing we are going to get quality on all modules
individually.
Integration Level Testing:
Once module testing is done, we are going to verify interrelations between
individual modules whether data is passing from one module to another modules or not.
Here we will test all the modules integration and ensure entire application is
integrated very well.

System Level Testing:

Testing team is going to test entire application end-to-end and they have to
ensure all the requirements are covered and working according to the client
expectations.
We are going to test entire system on multiple browsers and multiple
operating systems and we have to ensure entire system is working according to the client
requirements.

Note: System testing justifies whether we are able to deliver quality product to the client
and when we can deliver.

User Acceptance Testing (UAT):

It is a type of testing done by the client side testing team to ensure one more
time whether all functionalities are covered and those all are working according to the
client requirements.
UAT team will perform End-to-End testing in front of the client at offshore
location is called alpha testing. Here theVEyNw
KATilAl KeRn
ISs
Hu re entire system functionality
NA
according to the requirements.
 Developed software will be taken to the client location or on-site location and
application will be tested in this location with the help of installation engineers
(Deployment engineers) and they will continue one more round of testing for ensuring
application quality and stability in his location. This type of testing is beta testing.

Pre-production Testing:
It is a type of testing done by the client side team to ensure system is working
and stable in the production simulated environment.
It will be similar to the production testing but before going to deploy it in
production, we will create duplicate environment to the production and we will ensure
application is stable.

Production Testing:
It is a type of testing done on real time environment or live environment,
along with the end users, client side testing team will perform End-to-End testing to
ensure everything is working according to the client expectations.
White Box Testing Level

Before application is delivered to the testing team, development team will perform few
types of testing's for restricting number of defects moving from development phase to
testing phase.

1. Unit Testing
2. Integration Level Testing

Unit Testing:
It is a type of testing done by the development team by checking every piece
of code and ensure every unit is working according to the requirements.

Technical Integration Level Testing:

It is a type of testing done by the development team through source code for
checking inter relations between multiple modules whether those are working or inter
relations are happening or not.
Development team will follow few types of integration levels for integrating
multiple modules.

Top Down Approach

Bottom Up Approach
Hybrid Approach
Top Down Approach:
Started developing modules or features from high priority to low priority or
from parent to child and integrated accordingly.
Here integration will be happened from top to bottom till end of all the parent
and child modules.

Parent1

Parent1 Parent1

Child1 Child2 Child3 Child n

Bottom Up Approach:
Development team will start developing from low priority or child module to
high priority or parent module and integrated accordingly from bottom to top till end of
all the parent and child modules
 Parent1

Parent1 Parent1

Child1 Child2 Child3

Hybrid Approach:
It is a type of approach covers combination of both top down and bottom up
approaches.
The way development team is comfortable for developing either parent or child,
they will integrate both the ways till end of all the parent and child modules.
Parent1

Parent1 Parent1

Child1 Child2 Child3

Stub and Driver:

It is a temporary program developed by the development team for replacing the
mandatory module which is required for testing people to test all the integrated modules.

It will work as a normal behavior and based on the SRN document. We have to find what
are all the features or functionalities this temporary program is going to provide.

If it is a top down approach integration, then we are calling this temporary program as
stub.

If it is a bottom up approach integration, then we are calling this temporary program as
driver.
 SDLC Models
Waterfall Model:

Requirement

Analysis

Design

Coding

Testing

Delivery & Maintenance

In waterfall model all the phases will move from top to bottom and should not go bottom
to up.
Once completion of each phase then only we are moving to the next phase.
How the water falls from top to bottom, in the same manner this model going to work
from requirements to delivery and maintenance phase.

Advantages:
For any project if all the requirements are stable, then this is the suitable model to deliver
quality product.
Minimal budget is required for the project if requirement are stable.

Drawbacks:
It will not allow moving from bottom to up when there is a change in requirement then
again we have to start from requirement phase.
Verification technique will not be available so that we cannot ensure everything is
happening in each phase according to the requirement. Hence all the issues leads to find in
testing phase
For any project which are having unstable requirements, it is not at all suitable, if we
continue then it will become a deliver quality product in unexpected time and lot of budget
required.
Spiral Model:
This model is going to overcome few of the disadvantages getting in the waterfall
model.
In this model we will deliver entire project in multiple cycles and we are going to deliver
few of the requirements in each cycle so that in ‘n’ number of cycles we will deliver entire
project.
If at all client asked us to change or update any of the requirements, we should need to
incorporate and continue with the next cycle.

Advantages:
High visibility will be there for client on his product or project.
For every cycle client will be receive some part of the application based on that client
may give feedback to the company for updating or changing the any of the features.
Risk management will be handled properly for each cycle, it will allow us to deliver in
ontime, if at all we did not get any major changes from the client.

Drawbacks:
Defect identification will be happen only in the testing phase.
More time consuming.
More budget is required.
 n
Requirement

Analysis
1

Testing

Designing
Coding

Prototype Model:
Based on the requirements received from the client company is going to start
preparing prototype by covering all the requirements. Company will share the same to
the client for approval.
If at all client reviewed and updated few more changes then we have to update our
prototype and share it with the client. This process will continue till either acceptance or
rejection of the prototype.
If the client rejected the prototype then we have to stop our work on it.
If at all he accepted the prototype then we have to kick start with the actual work on it.

Advantages:
Client visibility will be more.
Scope of getting the projects from the client will be more based on the client satisfaction
on prototype.
Requirement

Analysis

Prototype
Send

Client
Not Accept Accept

Waterfall
Stop
model
Drawbacks:
The prototype cost will be taken care by the company, if at all client rejects the Prototype,
company is going to loose entire cost spent on prototype.
Mistake done in requirement, analysis, design, coding are going to find in testing phase,
due to this we may deliver in ontime or not.

V – V MODEL

We can also call it as a verification and validation model.

By using verification in all the phases we are going to verify all the documents and
standards whether we are on right track to deliver right product to the customer.
Testing team involvement will be there right from starting of the project.
Parallely to all the phases we will involve and we will design various scenarios and test
cases.
Once we get the build from development team we need to use designed test cases and
go ahead with test case execution.
 Verification Validation

Requirement UAT

Analysis System Testing

Designing Integration Testing

Coding Unit Testing

Advantages:

With the verification we can cross check in every phase whether we are on right track as
per the requirement.
Testing team will be involving from start, any deviations to the requirements they can
identify in the earlier stage.
We can assure quality product or project deliver to the client in ontime and onbudget.
Disadvantages:

Stable requirements are required to continue this model.

More budget is required due to maintaining testing team from beginning of the
project.

AGILE MODEL

For any projects/products which are not having stable requirements then they have to
approach agile model as it is most suitable and more visibility to the client on daily basis.

Scrum master is the person who is going to manage all the testing and development
activities on daily basis, he will monitor and ensure every thing is going on as per the
sprint time lines.

Product owner is the person from client side and he will cross check all the activities
from both development and testing team are working according to the client
requirements.
All the requirements are splited into stories by the scrum master and he will derive tasks
from the stories based on the priority to the client and depends on the time lines given
by the team(Estimations) and he will include all those tasks into that sprint and
according teams needs to work.
Usually sprint duration will be nearly 2-3 weeks.

This process will continue till end of all the stories given by the client.
Coding Scrum Meeting

Testing
Design
Sprint
Delivery Analysis

Sprint
Project Divide High priority
Stories (scrum Demo
requirements Tasks Testing
masters)

Enhancements
Defects
Scrum Meeting/Daily Stand up meetings:

This is the meeting conducted by the scrum masters with development and testing
teams for tracking the project/product development activities.
If at all anybody struck with any issues they can update those issues and resolutions will
be found in this meeting.

Here every body need to update tasks covered on that day and planning of tomorrow
and regarding the issues.
Advantages
High visibility will be there to the client

On daily basis client will check this product or project features if at all he found to
change any thing then immediately he can update to the scrum master so that
development teams will try to change those feature instantly in coming sprints.

It wont take more time for the development and testing activities.
Disadvantages

Poor documentation will be there

Both development and testing team will be allocated with some tasks. So that teams
feels more busy with work.
 TYPES OF ENVIRONMENTS

The place or area where we are going to develop the application or accessing the
application is called environment.
Four types of environment will be there

1. Standalone environment or 1-tier architecture

2. Client-server environment or 2-tier architecture
3. Web environment or 3-tier architecture
4. Distributed environment or n-tier architecture

1. Standalone Environment:

Any application or software is installing or using in single system for personal usage
then that environment is called standalone environment.
We cannot access the data from other systems because it will be limited to specific
system.
PL

BL

DL
 2.Client Server Environment:

The application or software which we are able to access in the specific area or
limited environment is called client server environment.
We are making one system as a server and installing the application after that it will
allow us to access the application from the server

Ex: companies internal sites, siri technologies

SERVER SYSTEM

DL
PL
BL

3.Web Environment:

Any application or software which we are able to access from world wide web that
environment is called web environment.
Application will be displayed into the server and it will be linked with the internet by
making or giving a URL based on that we can access the application by using the same
URL in the internet.
 SERVER SERVER CLIENT

DL BL PL

4.Distributed Environment:

Any application or software is installing or deploying into the server system in multiple
locations using many business logic layers and database layers is called distributed
environment.
In this environment even though load is getting increased and though one or more servers
will be down, then automatically requests will connect to the other business logic layers and
database layers and it will give the response.
Ex: Gmail application, Google
SERVER SERVER CLIENT

DBL BL PL
DBL BL PL
DBL BL PL
 TYPES OF TESTING

1. Smoke Testing
2. Sanity Testing
3. Retesting
4. Regression Testing
5. Compatibility Testing
6. Performance Testing
7. Install/Uninstall Testing
8. Adhoc Testing
9. Usability Testing
10. Security Testing
11. Functional Testing
12. GUI Testing
13. End to End Testing
14. Recovery Testing
1. Smoke Testing

It is type of testing conducted by the testing team for checking build stability whether
it is meeting the acceptance criteria or not

In this testing we are going to verify all the basic functionalities are working or not
based on this we will accept or reject the build.

In smoke testing, atleast 70-80% of the basic functionalities should work, then only we
can say that it meets the acceptance criteria, accordingly our test lead will send a mail to
development lead saying that we are accepting the build for major testing.

If build is not meeting the acceptance criteria then our test lead will send a mail to
development lead saying that rejecting the build by specifying what all the features are
not working.

Usually smoke testing will be done in 2-3 hours, but based on the company, it may
vary.
2.Sanity Testing:

It is used for finding the build stability for accepting the build for major testing by
executing all the basic functionalities related test cases and next level major test cases.

If it meets acceptance criteria, then we will accept the build for major testing.

3.Retesting:

It is first type of testing after smoke testing, whenever we have started our test case
execution, then it there will be a chance for finding deviations in our application, then we
have to update, these deviations or issues or bugs or defects to the development team.

Development team will cross check all the deviations and they will fix these all issues and
sending back to the testing team for testing again to find whether fixed deviations are
working according to the requirements are not. This type of testing is called retesting.

4.Regression Testing:

It is type of testing used for finding the stability of the entire application.

This is used for finding the impacted features due to the fixing of the defects or addition
of the new features.
With these above two cases we are having chance of getting impacted, with this existing
functionalities will not work even though changed feature or added feature are working.

After retesting we have to do the regression testing

ex: car repair of head lights

5.Compatibility Testing:

This type of testing comes under system level testing.

Here we are going to check entire application is supporting multiple software, hardware,
browsers.

Compatibility will give us result our application is supporting all the browsers, operating
system, environments, based on the client request.

Note: what are all the environments we have to check in the compatibility given by the
client.
6.Performance Testing:

It is used for finding the application response time based on the multiple sets of load putting
on the application.

Application is giving response in less time with multiple set of loads then we can say
application performance is very high and it will be satisfactory to the customers.

If at all application is taking more time for giving the response then we can say application
performance is very poor.

Performance testing is combination of

1. Load testing
2. Stress testing

Load Testing:
By giving the multiple set of loads, analyzing the performance time or response time is called
load testing.
Here in this testing we are going to find application response times for the different level of
loads.
Stress Testing:
By giving different set of loads continuously for some time, we are going to find application
stability and where it is getting crashed will be analyzed in the stress testing.
If at all they find peak level of load for the application is bearing, then they have to follow
some other ways to overcome the same.

Note: for the application which are used by the number of customers or end users globally
then they have to concentrate more on performance testing for giving high satisfaction to
the customers or end users.

7.Install/Uninstall Testing:

Install Testing:
Here in this section we are going to find how our product is installing properly or not for
multiple hardware, software is called installation testing.
This testing will be available only for the products which are used in standalone
environments

Uninstall Testing:
If at all we install any product then it is going to create supporting data into our machine by
using uninstallation testing we have to ensure supported data is getting removed properly or
not.
8.Adhoc Testing:

Due to the lack of time, we could not able to manage the testing activities effectively then
adhoc testing will be the testing playing major role.

Here we are not maintaining documentation like test scenario, test cases because due to
insufficient time.

Adhoc testing is the testing done by the experienced testers based on experience they are
having understanding on the requirements.

Note: adhoc testing will not give 100% quality application but as per the client request we
have to do and deliver application to the client.

9.Usability Testing:

It is the type of testing for finding the application graphical user interface (GUI) is user
friendly or not.

Here we have to justify the entire application GUI using client or end user perspective
whether it is easily understanding to the end user or not.

For doing the usability testing we need to have end user expectation on our application.
Note: UAT team is having high visibility on client or end user expectations then it will be
easier for them to do the usability testing.

10.Security Testing:

Security is nothing but how effectively protecting the entire application is called security.

In this testing we are finding or checking how much application or network is getting
protected from unauthorised sources.

Majorly we will concentrate on below three types of testings under on security

1. Authentication
2. Network
3. Application URL

Authentication:
Here we will check whether the application is successfully protecting from unauthorised
people when they do some of the miscellaneous actions on it.

Network:
Here we are having bunch of systems connected to the network, we have to protect the
information of entire network , For that we have to use the firewalls for restricting
unauthorized sources.
Application URL:
Here we are going to check applications security based on the URL, getting the URL from
other source and trying to perform other operations . It should restrict for the
unauthorized sources, it means should not allow to access the information.

11. Functional Testing:

It is the type of testing for finding application behaviour.

By using this testing we can justify whether entire application functionality is working
according to the client requirements or not.

By doing some actions or operations on our application, we have to check application
behaviour is according to the client expectations.

It is divided into 2 types:

1. Functional Positive Testing
2. Functional Negative Testing
Functional Positive Testing:
We are checking functionality of the entire application with positive data or valid
Data and we have to justify whether our application is working according to the client
expectations.

Ex: entering valid username, password into gmail login page

Functional Negative Testing:

By doing some operations or activities with the negative data or invalid data, we have
to find out whether our application is restricting or not.

Ex: entering invalid data into gmail login page

12.GUI Testing:
We are checking GUI of the application according to the client specifications given in SRS
document.

Here we will do testing on GUI elements, such as all the elements or controls are
properly displaying, alignment is fine or not, Tab Order.

Ex: in gmail username, pwd field, login and Cancel buttons are displaying or not.
13.End to End Testing:
It is a type of testing where we can test all the functionalities of entire application to justify
every feature is working according to the given client requirement.

Based on this testing we can find stability of the entire system with one environment.

Note: It is come under System Testing.

Combination of End to End Testing and Compatibility testing is called System Testing.

14.Recovery Testing:
It is a type of testing used for finding the capability of the application, whenever it is getting
crashed whether we are able to recover automatically or not.

If at all any application is not getting recovered then we can say it does not have enough
quality.

Note: For Security Applications, testing team need to concentrate by making forcible
application crashes and we have to check whether it is getting automatically recovered or
not.
 SOFTWARE TESTING LIFE CYCLE (STLC)

In STLC software testing is playing major role for delivering the quality product to the
client.
We should plan our testing activities accordingly based on the client request.
Testing phase is divided into 6 phases:

1. Test Planning
2. Test Development
3. Test Execution
4. Result Analysis
5. Defect Tracking
6. Reporting

Test Planning:
We are going to plan our testing activities for entire project along with scope, staffing,
schedule.
By including all above test lead is going to prepare test plan document and he will share it
to the client for approval.
Once we get the approval from the client we are going to start our actual testing activities.

Note: test plan is the first deliverable to the client from testing team.
Test Development:

Based on the test plan we are going to start writing test scenarios, test cases.

We have to complete preparing scenarios and test cases as per the schedule mentioned in
our plan.

Test Execution:

By using test cases, once we get the build from the development team then we have to
start performing all these validations to find what are all working and what are all not
working.

Result Analysis:

Based on the test case execution, here we are going to verify the test case results and
analyzing the results for finding genuine issues.

Defect Tracking:

If at all any failed test cases we are going to update all those issues to the development
team by using any of the tools like bugzilla, jira, QC, testopia, tfs(Team foundation server)
,………..
Reporting:

Based on the above phase and test cases results, defect reports, we have to update to
the client on stability of the application.

We have to report on daily basis, weekly basis, monthly basis based on the client request.
 TEST PLAN

Test Plan Contents:

1. Introduction
2. Purpose
3. Scope and Goals
4. Features that are not to be tested
5. Definitions and Abbreviations
6. References
7. Product/Project Architecture
8. Test Environment
a) Required Hardware
b) Required Software
9. Assumptions
10. Constraints
11. Test Coverage
a) Functional Testing
b) User Interface Testing
c) Performance Testing
d) Security Testing
e) Recovery Testing
f) Compatibility Testing
12. Test Strategy / Approach
13. Test Deliverables
14. Human Resource Requirement
a) Staff Requirement for Testing
b) Roles and Responsibilities
15. Test Schedule
16. Readiness Criteria
17. Acceptance Criteria
18. Defect Classification
19. Defect Management
20. Testing Resumption Criteria
21. Tools and Techniques
22. Risk Identification and Contingency Planning
23. Test Case List
24. Test data
25. Traceability Matrix
1.Introduction:
Here we are going to update overview of the test plan document. It will describe
basic thing of this document.

2.Purpose:
Here in this section we are going to update use of this document more clearly
which is understandable to everybody in our project.

3.Scope and Goals:

This section having all the features in our scope for testing and what are all goals
we have to achieve in time manner.

4.Features that are not to be tested:

Here in this section we are having features list which are out of scope.
Note: Mainly in security application, the client will give non-security features to the
companies and he will take care testing of the security features.

5.Definitions and Abbreviations:

Here we are having all the short names and their abbreviations
Ex: SIT = System Integration Testing
UAT = User Acceptance Testing
PVT = Production Validation Testing
NA = Not Applicable
6. References:
For preparing this document , All required documents list will be given in this section.
Ex: SRS, FRD, BRS

7. Product Architecture:
Here in this section, we are having entire project or product functionality flow in the single
diagram. It will represent overview of entire application.

8. Test Environment:
Here we are having environment related data and based on the environment, required
hardware and software details will be mentioned in this section.

Required Hardware:

Category Description

• RAM • 1GB
• MONITOR • 17/19 INCHES
• INTEL
Required Software:

Category Description

• Operating system • Windows XP

• Ms - Office • 2007
• Bugzilla • 1.6
• QC • 10.0
• QTP • 11.0

9. Assumptions and Dependences:

Here in this section for releasing or delivering the quality product to the customer in
ontime, what are all the solutions for the problems and their dependencies will be
analyzed and those assumptions will be mentioned.
Here assumption means assuming something and hoping deliver the product in ontime.
Ex: 1) getting build from the development team in ontime
2) We are going to complete test case execution in ontime.
3) Having all the requirements in SRS and test plan will be accepted by the client.
10. Constraints:
Here in this section we are having all the conditions for delivering quality product to the
customer.
Ex: 1) Some hardware is meeting or not available.
2) Lack of the resources.

11. Test Coverage:

Here we will mention what are all the testing types we are going to use in our project will
be mentioned here.

Functionality Testing
User Interface Testing
Security Testing
Recovery Testing

12. Test Strategy or Approach:

Here in this section we will keep how we are going to test the entire application, what are
all the testing levels we are following for the project mentioned here.

Unit testing
Module testing
Integration testing
System testing
User acceptance testing , preproductionDtuergsatsionftg, production testing
13. Tests Deliverables:
Here we will mention what are all the documents or information need to pass to the client
in periodic fashion will be mentioned here.
Test plan
Test scenario
Test case
Test case execution results
Bug report
Build stability report
Application functionality report

14. Human Resource Requirement:

Here in this section, we are having testing team resource names and their responsibilities
will be mentioned clearly in this section.

Skill Level Specific Areas for Effort Training Required

Testing

SI No Resource Name Designation Responsibilites

15. Test Schedule:
Here we will mention clear dates for entire project testing activities more clearly along
with who are all responsible for completing the tasks in deadlines will be mentioned here.
Based on this schedule testing team will follow and they will start and end their activities
accordingly.

Levels of Person Documents Approval To be Testing

testing responsible and records authority completed on strategy

16. Readiness Criteria:

Here in this section what are all the requirements needed for continuing with testing after
we get the build from the development team will be mentioned here.
Ex: SRS document should be signoff from the client.
Test plan should be approved from the client
Test cases and scenarios should be prepared ontime.
Environment should be ready for testing.
17. Acceptance Criteria:
Here in this section we will update customers acceptance condition of entire project,
when delivering the project to the customer.
Based on the test cases results and defect status. Client will conclude whether we may
accept or will give few more enhancements.

18. Defect Classifications:

Here we will mention different defect types which we are going to rise in our project.
Ex: Critical, high, medium, low

19. Defect Management:

Here in this section we are having all the process how we are going to manage our issues
or defects in our project.
ex: 1) To whom we need to assign the defect either to development lead or development
member will be mentioned here.

20. Testing Resumption Criteria:

Here in this section we will mention when we are going to resume our testing activities
after suspending the build, it will be clearly mentioned in this section.
21. Tools and Techniques:
Here in this section we will update required tools information and required techniques
for continuing with testing comfortably.

22. Risk Identification and Contingency Planning:

Here in this section we will mention all the possible risks and their solutions clearly
mentioned here.
Note: Contingency planning means identifying the solution.

S No Risk Nature of Impact Contingency Planning

1 2 resources are not available Work is getting Recreate another 2
effected resources
2 Build not delivered on time Test plan gets Test plan should need
effected to be updated

23. Test Case List:

Here we will mention test case document name, once we have done with test case
preparation, test case document name and location should need to update in our test
plan document for all the testing team members reference.
24. Test Data:
Here we will mention the data required for testing clearly.

25. Traceability Matrix:

Will be discussed in coming classes.
Test Development:
Here in this phase we are developing the test cases by deriving from scenarios which are
derived from requirements.
Note: Deliverable(Output) from test development phase is test case document.

1. Test Bed:
It is type of environment where we are going to work on application is called test bed.

2. Test Scenario:
It is high level verification point for testing the application. We can derive scenarios
from the client requirement document.

S No Scenario Id Scenario Requirement Expected TC Time Required

description document ID Count for TC’s
3. Test Case:
It is a low level verification point which we can derive from test scenarios. For testing the
application we have to come up with as many number of cases from the requirements
for delivering the quality product to the customer.

TC Scenario Test Pre- Test Expected Actual Pass Comm Positive/

Id Id Descrip requisi steps results results / fail ents negative
tion te
Requirements:

1. Siri Technologies Functionality

1.1 By entering valid username, password it should allow us to login
1.2 Valid username should contain 5-20 characters and combination is upper
case, lower case
1. 3 Valid password should contain 5-10 chars with combination is upper and
special chars

2. Graphical user interface of the app

2.1 Siri title should be available along with siri technologies header, username,
password, text labels, text fields.
2.2 Ok, cancel buttons

3. Error Messages should be displayed when entered invalid data

Scenario Types:
Scenarios are divided into 4 types

GUI Scenario
Functional Positive scenario
Functional Negative scenario
Non-functional Scenario
Field level validation scenarios.

Note: 1) Non-functional testing covers security testing, recovery testing, performance

testing.
2) Based on the project requirement we are going to cover scenarios for the same.

Test Case Types:

Test cases are divided into 4 types and we are deriving these cases from the designed
scenarios.
GUI test cases are derived from GUI scenarios
Functional positive test cases are derived from functional positive scenarios
Functional negative test cases are derived from functional negative scenarios
Non-functional test cases are derived from non-functional scenarios
Field level validation test cases derived from Field level validation scenarios.
Test Case Technique:
For deciding on the length of the input data we need to use below techniques for
finalizing the positive and negative length. If once length is finalized then we can play
with type of data with number of combinations with that length.
Positive data will be the positive length and having the any type of data as per our
requirement.
Negative type of data will be the negative length with positive and negative type of data.

Boundary Value Analysis:

By using this technique we can decide length of the text fields by using 6 combinations
min – 1 5-20 chars
min 4
min + 1 5
max – 1 6
max 19
max + 1 20
21
Equivalence class partitioning:
By using this technique we can finalize the length of the data for the text field by using
3 values.
< min
< min & max >
max >

Error Guessing Technique:

By using testing people experience and knowledge, if somebody will work on similar
type of projects continuously for long time then there will be a chance for guessing the
frequent errors or hidden errors in our application.
For all these errors they will prepare corresponding test cases and they will add it into
original test case document.
Usually test lead or senior test engineer will involve in this technique because they are
having sufficient knowledge for guessing the errors.

Decision Table:
It is a technique used for deriving the regression and integration related test cases.
It is a table containing all the functionality names in left and top sections.
Whenever any relation between any of the functionalities, for those all functionalities
we need to put a mark for identifying those all are interrelated.
For regression and integration we can derive the test cases very easily by using this
table.
Usually it will be prepared by the persons who are having entire project knowledge,
obviously test lead will prepare or in some cases senior test engineers also involve
while preparing.

Function 1 Function 2 Function 3 -------- Function N

Function 1
Function 2

Function 3

|
|
Function N

Test Case Execution:

Based on the test plan schedule, we will get the build from the development team then
we have to start validating test cases as per the test steps mentioned and based on
expected results.
This process continues till end of all the test cases related to features developed in
that build.
This process will continues till end of all the features or covered of all the requirements
in many numbers of builds, testing people will receive and validate the same.
If at all they have validated all the test cases by covering all the requirements, it means
test case execution phase is completed.

Result Analysis:
Based on the execution phase and depend upon the test cases status, here we are
going to analyze or cross check test case results.
Based on the analysis we will come to know what are all the features are not working.
Features which are not working based on the analysis we need to update to the
development team.

Bug Tracking:
Based on the result analysis phase we will finalize or confirm list of issues or bugs or
defects.
For all those confirmed issues we need to track somewhere by using any of the bug
tracking tool.
Mandatory fields or data required for rising the Bugs:

1. Summary:
It is a single line description about the specific defect which is required for
understanding the defect in simple manner.

2.Description:
It is having some more detailed description about the bug which we can use for
understanding the defect more clearly.

3. Steps to Reproduce:
Here we are updating all the sequential steps which we required for reproducing the
issues by the development team.

4. Project:
It is a drop-down field containing all the project names, here we have to select, specific
project of us.

5. Module:
It is a drop-down list containing all the modules name, here we have to select specific
modules related to the defect or issue.
6. Build No:
It is a drop down list containing all the build numbers from starting to latest one we have to
select latest build number which we are working on currently. It can be found from BRN
document.

7. Severity:
It will notifies seriousness of the issue based on the issue seriousness or issue complexity.
We have to update severity any of the below:
Intermediate (Show Stopper or Critical)
High
Medium
Low
Based on the severity ,development people will analyze the issue seriousness and based on
that they may update the priority on top of tester priority value.

8. Priority:
It will notify how much urgently to fix the issue by the development team.
Based on the severity given by testing team, they will update their priority. Based on that
they will work on fixing the issues in the following order.
Intermediate
High
Medium
Low
9. Founded By:
Here we need to update the test engineer name who found this issue. It is a drop down
list containing all the team members, in those we have to select one.

10. Assigned To:

Here we need to update the developer name from the drop down list.
Test lead will update the entire team regarding developer names for respective
features.

11. Comments:
Here we will update any other information required for this issue.

12. Status:
It is a drop down list containing different status for the bug or defect and statuses are:
->New
->Open
->Fixed
->Closed
->Reopen
->Reject
 Bug Life Cycle or Defect Life Cycle:

In our test case execution, test cases are validating based on the expected results
and actual results from the application, we are analyzing and confirming the test cases
passed or failed.

Whenever any test case is failed we need to update this deviation to the
development team

In the form of bug or defect we will update to the development team.

By updating all the mandatory fields required (based on the tool mandatory fields
will change) for rising the bug or defect need to update and saving the issue as it will
create unique bug-id along with the status new.

Development team will work on all the new issues and if at all they confirm the same
issue is getting reproduced in their environment then they will accept the issue for
fixing by changing the status to open.

If at all they could not able to reproduce then they may reject the bug by changing
the status to reject by updating with proper comments.
Whenever development team will work on all the open issues and if at all they fix
any issues then they will change the status to be fixed.

Testing team have to verify all the fixed issues and if at all issued is resolved then we
are going to close the defect by changing the status to closed.

If at all any issue is fails in retesting then again we need to update it to the
development team by making the status reopen.

Based on the comments entered for rejecting the bugs we need to cross check one
more time in the functionality and confirms everything is working then we have to
close the defect by making the status to closed.

Even though some of the closed issues may get reopened while doing regression
testing whenever any new features are added or any defects are fixed.
 New

Not accept Dev

Reject
verify

Accept

Test
Open/Reopen
verify
Fixed
Bug Life
Fixed Cycle

Not working
Testing
team
verify
Work
Work

Closed
Reporting:
We will send multiple status of application in many builds to the client in periodic
manner for updating the status of the application.
These reports include daily status, weekly status, monthly status and project status
report.

1. Daily Status Report:

This is the report we are sending everyday to the client for updating on the activities
covered on the same day. It will be prepared and send by the team lead.

2. Weekly Status Report:

It is a report containing all the activities done in that week. Here we will update tasks
like test cases and scenarios writing, test case execution, test results are mentioned
clearly and update to the client.

3. Monthly Status:
It is a report containing activities done in that month will be mentioned clearly along
with clear explanation on tasks covered.
It will notifies to the client that activities covered by the testing team in that month.
4. Project Closure report:
It is a report containing stability of the entire application. We will mention clearly
number of test cases executed , number of bugs found, based on that client will analyze
stability of the application at that time.
Based on the analysis he may update or talk with the project manager regarding the
application status.
If client satisfied, we will deliver project or product to client and he will continue next
level of testing.

Build 1 Build 2 Build 3 Build n

10 10 + 10 20 + 10 100

FT FT Bugs
Testing regression regression
Testing Testing Build 1&2
bugs resolve
Requirement Traceability Matrix:

This document is used for tracking the requirements for checking the scenarios and test
cases coverage.

Defaultly, this matrix is having columns requirement id, scenario id and test case id.

Requirement id will be updated by the test lead and he will share this document to the
entire testing team for updating the scenario ids and test case ids.

Once entire team is updated with their scenario ids and test case ids, test lead is going to
verify every requirement is covered for writing the test case or not.

If at all he finds any of the requirements is not covered which means scenario ids and test
case ids will be empty for corresponding requirements, then he will assign those
requirements to somebody in our team for writing scenarios and test cases.

Requirement Id Scenario Id Test Case Id

Test Metrics:
The purpose of the metrics is to find the efficiency of the test team & Quality of
the application.
1. Test Coverage:-
This metrics will be used to deside when to stop the testing of a certain feature. If the
Test coverage is 100% & If most of the Test cases is pass, Then we can stop the testing.
To estimate the testers efficiency by lead or P.M

Test Coverage = Total No.of Test cases executed / Total No.of Test cases*100.

2. Remark V/s Defect Ratio:- (Defect V/s Remark Ratio)

The result of metrics should be in B/W 80% - 95%. If it is less than 80% we can derive
that Test team is not clear with the requirements & If it is more than 95% we can
derive that the tester might be interacted with the developer before logging a defect to
confirm, Whether the issue is really defect or not.

This metrics will be use to find out the efficiency of a tester by Lead or PM
Remark to defect ratio = Total No.of Valid defects/ Total No.of Remarks *100
3. Defects per KLOC (or) Defect Dencity:-
This metrics is use to estimate the developer efficiency
Defects per KLOC = Total No.of Valid defects / KLOC
OR
Defects per KLOC = Total No.of Valid defects / LOC * 1000
LCL & UCL for this metrics are 5 &7.

4. Defect Severity Index:-

The purpose of this metrics is to find how stable the application or module.
D.S.I = 10*I + 5*H + 3*M + 2*L / I + H + M + L
Defect Severity Index on Open defects = <7
Defect Severity Index must be = <5

5. Bad fix Ratio :-

To define the developer efficiency, & it will calculation at the end of the project
for each developer.
Bad fix Ratio = Total No.of reopened defects / Total No.of Fixed defects * 100
It should not be more than 10%
6. Effort Variance :- For hours
Schedule Variance:- For Days
This metrics purpose is to define the stability of a PM

EX:Given time to complete the project is 1000 hrs , Then the acceptable time should be
B/W 950 to 1050 hrs Effort variance
950 to 1050 days Schedule variance

Effort Variance :- Actual Time / Estimated Time * 100

Schedule Variance :- Actual Days / Estimated Days * 100
Software process:
A Sequence of steps followed for getting quality on documentation and on
Project/project.

A set of predefined activities should follow by every project team for ensuring quality
and deliver the project in on time with quality.

If at all we are not following process:

a) Not able to reach project deadlines
b) May not able to maintain Quality
e) More rework is required
f) Client may not able to satisfy with the quality
g) More resources are required
h) More gaps will identify in end of the project in testing phase due to the gaps in
documentation.

Benefits Of Process:
a) 100% Quality
b) Defect Prevention
c) Reduce the project cost
d) Reduce the no of resources
e) Assurance on project quality to Client
f) Client satisfaction will be very high
What is Process model:
A model is contains collection of processes used for getting quality in all areas of the
project such as documentation and functionalities of project.

SEI (Software Engineering Institute) was developed Capability Maturity Models(CMM)

model and This will certifies the companies in various levels based on processes
follow and implementing in the Organization.

CMMI(Capability Maturity Model integration)replaces CMM in now a days and it is

developed by the same SEI. It is a model of 5 levels of process and SEI will determine
the companies based on standards followed in the Organizations.
Capability Maturity Models:-
1)Performed
2)Managed
3)Defined
4)Quantitatively Managed
5)Optimizing

Process Areas by Maturity Levels:

1) Performed – Overview:
Introduction
Structure of the model
Maturity Levels, Common Features
Understanding the Model
Using the Model

VENKATA KRISHNA
2) Managed - Basic Project Management
Key Process Areas:
Requirement Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and product quality Assurance
Configuration Management

3. Defined – Process Standardization:-

Key Process Areas:
Requirement Development
Technical Solution
Product Integration
Verification
Validation
Organizational process Focus
Organizational Process Definition
Integrated project management
Organizational Training
Risk Management
4) Quantitatively Managed:
Key Process Areas:
Organizational process performance
Quantitative project management
Metrics are used to track productivity processes and products projects is predictable
and quality is consistently high.

5) Optimizing – Continuous process improvements :

Key process Areas:
Organizational Innovation and Development
Innovating the new standards and updating the same to CMMI
 QUALITY CENTER
Quality center is divided into 2 sections those are:
1. Site Administration
2. Quality Center

Site Administration:
By using this component we can manage the administration part for quality center.
We can manage activities like
 Creating domain
 Creating projects
 Creating users
 Assigning user to the projects

Creating domain:
Based on the client requirements they may mention ‘n’ number of domains in the single
tool then we need to create those domains by using the option under site
administration login

Site project 
create domain
Site project 
delete domain
Creating projects:
Based on the client requirements we can create ‘n’ number of projects under each
domain. We have to provide unique project name while creating

Site administration login

Site projects create project

Site projects delete project
Site projects 
rename project

Creating User:
Based on the requirements we need to create ‘n’ number of users under each project
under specific domain.

Site Administration

Site User 
New User
Site User 
Delete User
Site User 
password
Assigning the user to the project:
By using create users we can assign it to the existing projects.
One user can be assigned to ‘n’ number of projects.
While logging into the quality center it should need to display all the assigned domains
in the assigned drop down list and all the assigned projects under project drop down list.

Site projects 
project users

add user from the users list

Quality Center:
It is a test management tool provided by the Hp. By using this tool we can manage our
testing activities effectively from starting to ending.
By using this we can store all the project related documents related to testing will be
maintained as a central repository and it will allow us to access the data parallely by
team members.
We can store requirements, test cases, test case results, defects or bugs.
It will allow us to generate user friendly reports for our test case execution or defect
details.
Quality center is divided into majorly 4 modules related to testing those are:
1. Requirement
2. Test Plan
3. Test Lab
4. Defects

1. Requirements:
It is used for storing all the requirements documents in the necessary hierarchy.
It will allow us to create ‘n’ number of parent and child requirements and we can
associate or attach requirements documents for the same. The options in this phase
are
New Requirement:
used for creating new parent requirements
New Child Requirements:
used for creating child requirements
Delete:
used for deleting either existing parent or child requirement.

Whenever we have created any requirement, then quality center will generate
requirement id automatically.
Ex: RQ0001 and RQ0002
Test Plan:
It is used for maintaining all our test cases documents in the necessary hierarchy by
creating number of folders and sub folders.
We can classify test cases into different sections and we can create test cases under
that.
For creating test cases mandatory fields are

Test Case Description

Step Numbers
Expected Results
Description
Author
Created of Date and Time
We can update the test case with ‘n’ number of steps.

New Folder:
used for creating the folder.
New Test Case:
used for creating the test case under folder structure.
Delete:
used for deleting the either test case or folder.
3. Test Lab:

It is used for maintaining test case results by linking defects as well for the failed test
cases.

By using select test option we are able to see all the available test cases in test plan tab
then it will allow us to drag test cases from test plan to test lab tab.

By using test set option we can maintain similar type of test cases under single name.

By using run option we can run the test cases one by one.

By using run test set option we can run all the test cases under that test set. It will take
care to show the test case step one by one for updating the results.

Delete option is used for deleting the folders and test sets.

4. Defects:

It is used for maintaining all the issues or bugs found in the test case execution phase.
By using new defect option we can update all the defect details such as

Summary
Detected by
Severity
Detected in version
Project
Status
Detected on date
Assigned to
Priority
Reproducable
Subject
Description

If at all we want to associate any screen shots for giving better understanding to the
developer it will allow us to attach attachments by using attach option.
Visual Safe Source:

It is a configuration management tool. Configuration management is the process for

maintaining all our projects documentation with the version control feature. ( version
control means, it will maintain ‘n’ number of copies for each document whenever we did
only modifications or updation.

It is having authentication as it required unique username and password for each member
for logging into the VSS. With this version control we can track what are all the changes
done by the individual team members.

The features included in VSS are:

Set Working Folder
Create Project
Check Out
Check In
Get Latest Version
Add File
Set Working Folder:
Once we logged into the VSS by using this option, it will allow us to create working folder
which will allow us to upload or download data from the VSS.

Create Project:
It is used for creating the projects for classifying the data of multiple projects.

Check Out:
By using this we can download files from the VSS specifically to the working folder.
Note: Anybody did check out for any file it is not going to allow to do the check out by
anybody else.

Check In:
This option is used for upload the files from working folder to VSS. It will be enabled for
any file after we do the check out.

Get Latest Version:

It is used for fetching the latest file from the VSS. At a time ‘n’ number of persons can get
the latest version from VSS.
Add File:
It is used for adding or uploading the new document or file into the VSS.

History:
It is used for checking all the modifications and respective persons for any document, it
will be used for checking the multiple versions status.