Page 1

Soft Ware Testing:

 Why did you choose this Course?
* 1. Scope of getting job is very high.
2. No need to depend up on any technologies.
3. Testing remains forever
4. I want to be consistent through out my life

Why explicitly the s/w companies are recruited the

test engineers?
1. One person cannot efficiently perform two tasks at a time
2. Sentimental attachment.

Who can do the course?

Any graduate can do this course at this point of time

 What exactly we require to get a job?

1. Stuf
2. Communication skills
3. Confidence
4. Dynamism

 Project:
Project is some thing that is developed based on the particular customers
requirements and used by that customer only ( E.g.: Marriage laddu)

Product:
It is some thing that is developed based on the companies specification and used
by the multiple customers (e.g.: Thirupathi laddu)
Quality:

Classical definition for quality: - Quality is defined as justification of all the

requirements of customer in a product.
NOTE: Quality is not defined in the product; it is defined in the customers mind

Defect: - Defect is defined as deviation from the requirements

Latest definition for quality: - quality is defined as not only the justification of
requirements but also the presence of value (User friendliness)
 Testing:

1
Page 2
Testing is processes, in which the defects are identified, isolated, subjected for
rectification & ensure that the product is defect free. In order to produce the quality
product in the end and hence customer satisfaction.

 Bidding The Project:

Bidding the project is defined as request for proposal, estimation and signing off
(Official agreement).

 Kick Off Meeting:

It is an initial meeting conducted in the soft ware company soon after the project
is signed off. In order to discuss the overview of the project and to select a project
manager for the project.

Usually high level management, Project managers, team managers, quality

managers, team leads and quality leads will be involved in this meeting.

PIN (Project Initiation Note):-

It is a mail prepared by the project manager and sent to the CEO of the soft ware
company in order to get the permission to start the project developments.

 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.

I. Initial Phase or Requirements Phase :

(a) Tasks: Interaction with the customer and gathering the requirements.

(b) Roles: Business Analyst (B.A), Engagement Manager (E.M)

Process: First of all the business analyst will take an appointment from the customer,
collects the templates from the company, meets the customer on appointed day, gathers
the requirements with the help of template and comes back to the company with the
requirements documents.

Once the requirement document has come to the company the engagement
manager will check whether the customer gives any extra requirements or confused
requirements. In case of extra requirements he deals the excess cost of the project. In case
of confused requirements he is the responsible for prototype demonstration and gathering
the clear requirements.

2
Page 3
Proof: The proof document of this phase is Requirements Document. This is called
with different names in different companies.

1. FRS (Functional Requirements Specification)

2. CRS (Customer Requirement Specification)

3. URS (User Requirement Specification)

4. BDD (Business Design Document)

5. BD (Business Document)

6. BRS (Business Requirement Specification)

Some companies may maintain the over all business flow information in one document
and the detailed functional requirement information in the other document

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

4. Requirement Analysis
(b) Roles: 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.
3
Page 4
SRC- System requirement specification

Proof: - The proof of this phase is system Requirement specification.

III. Design Phase: -

Tasks:

1. High level designing

2. Low level designing

Roles: High-level designing is done by the chief Architect & Low level
designing is done by the Technical Lead

Process: The Chief architect will be drawing some diagrams using unified modeling
language in order to divide the whole project in to modules.

The Technical lead will also draw some diagrams in order to divide the modules
in to sub modules.

The technical lead will also develop the PSEUDO code in order to make
developers comfortable while de3veloping the actual code.

Proof: The proof document of this phase is Technical design document.

IV. Coding phase:

(a) Task: Developing or Programming

(b) Roles: Developers or Programmers

Process: Developers will develop the actual code by using the technical design
document as well as following the coding standards like Proper indentation, color
coding, proper commenting and etc..,

Proof: The proof document of this phase is source code Document.

E.g.: The programmer will develop some programs every one will develop his program
in different colors but the soft ware companies will ask the developers to develop the
program according to the company standards using proper color, coding, commenting.
So as to understand it easily.

V. Testing Phase:

(a) Task: Testing

(b) Roles: Test engineers

Process:
4
Page 5
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

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 customer’s
requirements in order to test a particular feature or a function.

VI. Delivery & Maintenance Phase:

Delivery:
(a) Task: - Installing the application in the client’s environment

(b) Rolls: -Deployment engineer or Senior test engineers.

5
Page 6
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.

************************^^^^^^^^^^^^^^^^^^^************************

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 Methodology or Testing techniques:

There are three methods of testing

(a) Black-Box Testing

(b) White-Box Testing

(a) Grey-Box Testing

6
Page 7

(a) Black-Box Testing: If one performs testing only on the functional part of an
application with out having any structural knowledge then 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.

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.
7
Page 8
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

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

DRIVER: -While integrating the modules in bottom up approach. If at all any

mandatory module is missing then that module is replaced with a temporary program
known as DRIVER

4.System Level Testing:

It is a level of testing in which one will install the complete application in to the
environment and then perform testing on it. At this level different types of testing will be
done one among those is system integration testing.

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

8
Page 9
System: The application installed in to an environment combinable called as system.

a. Presentation Logic: The logic that is used for viewing application is known as
presentation logic

b. Business Logic: - The logic that is used for performing the operations on the
application is known as business logic.

c. Data Base Logic: - The logic that is used for sharing and retrieving the data is
known as database logic.

Types of Environment: - There are Four types of environments

a. Stand alone environment or One-tier environment

b. Client –server environment or Two-tier Architecture

c. Web environment or Three-tier Architecture

d. Distributed environment or N-tier Architecture

a. Stand Alone environment: -

In this type of environment all the three layers that is presentation layer,
Business layer& Database layer will be present in al single tier. This type
of environment is suitable for single user application.

One-Tier Architecture
PL

BL One tier Architecture

DBL

b. Client –server environment:

In this type of environments there will be two tiers, one tier is for clients
and other tier is for database servers. The presentation layer and the
business layer will be present in each and every client . The database layer
will be present in the database server. This type of environment is suitable
for multi user application in a single or a limited area.

Two tier Architecture

PL+BL DBL

9
Page 10
PL+BL

PL+BL

Clients Server

c. Web environment: - In his type of environment three tiers will be there. One is for
client’s the middle one is for application server and the other one is for database
servers. Presentation layer will be present at clients, Business layer will be present in
the application server, and database layer will be present at the database servers.
This type of environment is suitable for the applications that are used all over the
world by limited number users

Three-tier Architecture:

PL
DBL
BL
PL

DBL
PL

Clients Appl Server Database server

Web server: -
It is software, which provides web services to the clients.
E.g.: - Internet Information service (IIS).

Example for Application servers: Tom pact, Web logic, web sphere etc..,

d. Distributed environment: -
It is similar to the web environment but the number of application servers
are increased and represented in individual tiers in order to distribute the
business logic so that the logic will be distributed.

N-tier Architecture:
W
PL DBL

BL BL BL
10
Page 11
PL

PL

PL

Clients Apl server1 Apl server2 Apl server2 Database server

******************^^^^^^^^^^^^^^^^^^^^^^^********************************

Software Development Models: -

1. Water Falling Model

PHAS ACTIVIT OUTCO

INITIAL Req.gathering BRS

ANALYSIS Sys.design SRS

DESIGN S/w design to Mod Test TDD, GUI

DEL&MAINT Delivery Unit test
Sys.Test.
TESTING
CODING client Int.
UAT test 11
Black
Implementation
box testing UTR
 Page 12

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 SRS Doc Client environment

Base lined confirmation

H/Wprototype H/Wprototype
Prototype

S/WPrototepe H/Wprototype

REQ.are
Advantages: - BRS DOC
Refined
Base
Whenever the customer is not clearLined
with the requirements this is the best
suitable model for gathering the clear requirements.

Drawbacks: -
 It is not a complete model
 Prototype has to be built on companies cost
 User may limit his requirements by sticking to the prototype.

(B) Evolutionary Model: -

Initial Req

N Feed back with

Dev. new Req.
User

User accept
Application validation 12 is Base lined
Appl
Y
 Page 13

Advantages: -
Whenever the customer is evolving the requirements this is the best
Suitable model.
Drawbacks: -
 Cannot define the dead lines
 Project monitoring & maintenance is very difficult
 No Transparency (No clear)

Spiral Model: -
Defining the objectives/WA/Constraints

Refining & Risk Root cause

Planning for the analysis
next cycle Estimation
Contingencies

Implementation
Advantages: -
This is the best suitable for developing the highly risk based project
(scientific projects)

Drawbacks: -
 Risk analysis and estimation is not an easy task
 It is a costly model
 It is a time consuming model

(C) Fish Model: -

Delivery &
Req. Gathering Analysis Design Coding Maintenance
   
Sys testing

SRS HLD
LLD SCD
 Black Box
testing
13
 Page 14
BRS Review
   
SRS Review TDD Review White box
Test S/W
testing
Changes

Advantages: -

This is the best suitable for developing the highly risk based project(scientific projects)

Drawbacks: -
o Time consuming Model
o Costly model

Verification: -
It is a process of checking conducted on each and every role of the organization in order to check
whether they are working according to the guidelines or not right from the starting of the process
till the ending of the process

Validation: -
It is a process of checking conducted on the developed product in order to check whether it is
working according to the requirements or not.

(D) V-Model: -
Verification
Validation
BRS Preparing proj plan
Initial& design SRS Preparing Test plan
Phase Req.Phase testing

Design Phase testing

Design & TDD Program phase testing
coding
Test SCD

S/W Build System testing

Test management Process
Testing User acceptance testing

Port Testing
S/W efficiency
DRE=A/A+B
14
 Page 15
Delivery & Maintenance Test S/W changer

Advantages; -
AS verification and validation as well as test management process is done the out come
will be a quality product.

Drawbacks: -
o Time consuming mode
o Costly model

DRE: Defects removal efficiency

End of the Basic part…

Testing part to be continued………….

1.Build Acceptance Testing Or Build Verification Testing Or Sanity

Testing: -
It is a types of testing in which one will conduct over all testing on the released build in
order to check whether it is proper for further detailed testing or not. Even some companies call it
as smoke testing, but some companies says that just before releasing the build the developers will
conduct the overall testing on the build that is known as smoke testing and once the build is
released what ever the test engineers do in order to accept the build is known as B.A.T or B.V.T
or Sanity Testing.

2.Regression Testing: -

15
 Page 16
It is a type of testing in which one will perform testing on the already tested
functionalities again and again.
It is usually done in two scenarios.

1. Whenever the testers has raised the defects, rectified by the developers and next build
is released to the testing department then the test engineer’s 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 end-users or
by the third party testing experts before actual implementation.

Drawback: If at all any defects are found then there is no chance of rectifying them immediately.

6. Static Testing: -
It is a type of testing in which one will perform testing on the application or application
related factors with out performing any action.
Eg:- Documentary testing, GUI testing, Code reviews and etc.,

7. Dynamic Testing: -
It is a type of testing in which one will perform in the application or its related factors by
doing some actions
Eg: - Functionality testing.

16
 Page 17
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
b. Direct URL Testing (Uniform Resource Location)
c. Fire Wall Leakage Testing.
17
 Page 18

(a) Authentication Testing: -

It is a type of testing in which one will enter different combinations of usernames and
passwords and try to access the home page in order to check whether only the authorized persons
are accessing the application or not.

(b) Direct URL Testing: -

It is a type of testing in which one will enter the URL of an unauthorized page directly in
the browser and try to access that page in order to check whether it is been accessed or not.

(c) Firewall Leakage Testing: -

It is a type of testing in which one will enter as one level of user and try to access the
other level of unauthorized pages in order to check whether the firewalls are working properly or
not.

17. Mutation Testing: -

It is a type of testing in which one will perform testing on some thing by doing some
changes to it.

18. ADHOC Testing: -

It is a type of testing in which one will perform testing on the application in his own style
after understanding the requirements clearly.

The Soft Ware Testing Life Cycle Contains Six

Phases

They are…

 Test Planning
 Test Development
 Test Execution
 Result Analysis
18
 Page 19
 Bug Tracking
 Reporting

Plan: -
It is a strategic document, which describes how to perform a task in an effective, efficient
and optimized way.

Test Plan: -
It is a strategic document, which describes how to perform testing on an application in an
effective, efficient and optimized way.

Optimization: -
Optimization is a process of utilizing the available input resources to their max and
getting maximum possible out put.

1.0 Introduction
1.1 Objective
1.2 Reference Document

2.0 Coverage Of Testing

2.1 Features To Be Testing
2.2 Features Not To Be Testing

3.0 Test Strategy

3.1 Levels Of Testing
3.2 Types of testing
3.3 Test design techniques

19
Page 20
3.4 Configuration management
3.5 Test metrics
3.6 Terminology
3.7 Automation Plan
3.8 List of automated tools

4.0 Base criteria

4.1 Acceptance criteria
4.2 Suspension criteria

5.0 Test Deliverable

6.0 Test Environment

7.0 Resource Planning

8.0 Scheduling

9.0 Staffing& Training

10.0 Risks & Contingencies

11.0 Assumptions

12.0 Approval Information

1.0 Introduction: -

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: -

20
Page 21
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.

Eg: - BVA (Banded value analysis)

ECP (Equivalence Class Partition)

3.4 Configuration Management:- To be discussed later……

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: -
21
Page 22
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.

8.0 Scheduling: -

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): -

22
Page 23

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

Contingencies (solution Plans):

i. Proper plan ensurance.

ii. Employees need to be maintained on the bench.
iii. What not to be tested has to be planned in case of imposed 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.

FRS (Functional Requirement Specification)

HLI (High level

Information)

LLI (Low-level
Information) USE CASES

Screen Shots

Use Cases:
23
Page 24
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. Screen shot
ii. Functional requirements
iii. Special requirement/Business rules/Validation
iv. Template

i. Screen Shot: -
User name

Password

Connect to

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.

iii. Special requirement/Business ruled/Validation: -

a. Initially whenever the login screen is Invoked Login, clear buttons must be
disabled.
b. Cancels Button must be always enable.
c. Up on entering user name and password the login button must be enabled.
d. Up on entering some information in to any of the fields the clear button must
be enabled
e. The Tabbing order must be user name, Password, Connect to, Login, clear,
cancel.
iv. Use Case Template:
Name Of The Use Case :
Brief Description of Use Case :
Actor’s Involved :
24
Page 25
Special Requirements :
Pre Condition :
Post-Conditions :
Flow of Events :

v. Use Case Document:

Name of the use case: Login use case.

Brief Description of use case: It Describes the functionalities of all the

features present in the login screen.

Actors Involved: Normal user, Admin User.

Special Requirements: There are two types of special requirements

1.Explicit requirements
2.Implicit requirements

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.

List of Explicit requirements: -

 Initially whenever the login screen is Invoked Login, clear buttons must be
disabled.
 Cancels Button must be always enable.
 Up on entering user name and password the login button must be enabled.
 Up on entering some information in to any of the fields the clear button
must be enabled
 The Tabbing order must be user name, Password, Connect to, Login, clear,
cancel.

List of Implicit Requirements: -

 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”

25
Page 26
 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”

Pre-Conditions: Login screen must be available

Post-Conditions: Either home page or admin page for the valid user and error
message for the invalid users

Flow of Events: There are three flows for the application

1. Main Flow
2.Alternative Flow
3.Exceptional Flow

1.Main Flow:
Action Response

1.Actor invokes the application. 1.Login Screen is displayed with the following fields
Username, Password, Connect to, Login, Clear& cancel.

2.Either home page or admin page is displayed

2.Actor enters valid user name, Valid
password and clicks on login button.
3.Actor enters valid user name, valid
password, selects a database option and
clicks on login button.
depending up on the actor entered by authenticating.
3.Authenticates,Either home page or admin page is
displayed depending up on the action entered with
mentioned data base connection.

4.Go to Alternative flow table 1

4.Actor enters invalid user name Valid
password and clicks on login button.
5.Go to Alternative flow table 2
5.Actor enters valid user name, Invalid
password and clicks on login button.
6.Go to Alternative flow table 3
26
Page 27
6.Actor enters both username and password
invalid and clicks on login button.

7.Actor enters some information in to any of 7.Go to Alternative glow table 4

the fields and clicks on clear button.

8.Actor clicks on the cancel button. 8.Go to Alternative flow table 5.

1.Alternative flow table 1: -(Invalid User name)

Action Response
Actor enters invalid user name, valid Authenticates an error message is displayed
password and clicks on login button “Invalid User name Please Try again”.
2.Alternative Flow Table 2: -(Invalid Password)
Action Response
Actor enters valid user name, invalid Authenticates an error message is displayed
password and clicks on login button “Invalid User Password Please Try again”.
3.Alternative Flow Table 3: - (Invalid username & Password)
Action Response
Actor enters invalid user name, invalid Authenticates an error message is displayed
password and clicks on login button “Invalid User name and password Please
Try again”.
4.Alternative Flow Table 4: - (Clear Click)
Action Response
Actor enters some information in any of the All the fields are cleared and cursor is
fields and clicks on clear button placed in the user name fields

5.Alternative Flow Table 4: -(Cancel click).

Action Response
Actor Clicks on the cancel button. Login screen is close

 Identify the module to which the use case belongs.

Security module.

27
Page 28
 Identify the functionality of the use case with respect to the total functionality
Authentication
 Identify the functional points and prepare the functional point document.

 Identify the input required to perform testing

Valid & invalid Inputs
 Identify the actors involved in the used case
Normal user & Admin user.
 Identify whether the use case is linked with any other use case.
Home page and Admin page use cases
 Identify the pre conditions
Login Screen mist be available
 Identify the post conditions
Either home page or admin page for valid users and error message for invalid
users
 Understand the main flow of the application
 Understand the alternative flow of the application
 Understand the special requirements
 Document the test cases for the main flow
 Document the test cases for the alternative flow
 Document the test cases for the special requirements
 Prepare the cross-reference matrix.

Functional Point: -
The point where an user can perform some action is known as functional
point.

Testing Process: -
FRS FPD MTCD DTCD DPD

VLD UN-Entry Validate Login 1

PW-Entry check 2
Login Click Validate Cancel 3
Cancel Click Check 4
Clear Click Validate Clear 5
Check 6
7

28
Page 29

FRS- Functional Requirement Specification

FPD-Functional port Document
MTCD-Master Test Case Document
DTCD-Detailed Test Case Document
DPD-Defect Profile Document

Cross Reference Document: -(Traceably Document)

It is a document, which contains a table of linking information used for tracing

back for the reference in any kind of ambiguous (confusion) or questionable situation.

Common Tracebility Matrix

VLD FPD MTCD DTCD DPD

2 7 3 28 1

8 22 5 5
47

Requirement Tracebility Matrix

TCID REQ ID

1 1
2 1
3 1
4 2
5 2
6 2
7 2
8 2

Defects Tracebility Document

DID TCID
1 28
2 32
3 65
4 96
5 48
6 52

Types Of Test Cases:

There are Two types of test cases if we see broadly they are:
1. GUI Test Cases
2. Functional Test Cases

The Functional cases are further divided in to Two types

29
Page 30
(a) Positive Test Cases,
(b) Negative Test Cases.

Guide Lines fro developing the GUI Test Cases:

 Check for the availability of all the objects

 Check for the alignments of all the objects up on customer requirements
 Check for the consistency of all the objects
 Check for the spellings and grammar
 Apart from the above guide lines any thing else that can be tested just by looking
with out doing any actions will fall under GUI test cases

Guide Lines for Positive Test Cases:

 A test engineer should have positive mind set up

 He should consider the positive flow of the application
 He should use only the valid Input

Guidelines for developing Negative Test Cases:

 A test engineer should have negative mind set up

 He should consider the negative flow of the application
 He should use at least one invalid input per a set of data

Test Case Template: -

(a) Test Objective

(b) Test scenario
(c) Test procedure
(d) Test Data
(e) Test Cases

(a)Test Objective: -
The main purpose of the document is described here in this section
(b) Test Scenarios: -
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.
30
 Page 31
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: -

The format of a test case template is given below

TCID TC DESCRIPTION EV AV Result Severity Priority Reference
TYPE

Test case Table

TC
ID TYPE Description Expected Value Actual Value Result Severity Priority Reference

Check for the availability of All the objects must be All the objects
all the objects as per the available as per the are available as
Login Obj Tab login obj tab per the login obj
1 GUI tab Pass
All the objects must be
consistent with each All the objects
Check for the constancy of other are consistent
2 GUI all the objects with each other Pass
Check for the spellings of
all the objects as per the All the objects must be All the objects
spelled properly as per
Login obj TabLogin Obj are spelled
the login obj tab
3 GUI Tab.xls properly Pass
Initially login, clear must
Check for the enable be disabled and cancel Login, clear and
property of login, clear and button must be enabled cancel buttons
4 GUI cancel buttons are enabled Fail

31
Page 32
Initially the cursor must
be positioned in the Initially the cursor
Check for the initial user name field is present in the
5 GUI position of the cursor username field Pass
Enter some information in
to user name and
Login button must be
password field and check
enabled
for the enabled property of Login button is
6 Positive login button enabled Pass
Enter some info in to any
of the fields and check for Clear button must be
the enabled property of enabled Clear button is
7 Positive clear button enabled Pass
Corresponding page Corresponding
Enter user name, must be displayed as pages are
Password as per the VIT per the VIT displayed as per
8 Positive and click on login button valid in puts table Pass
Corresponding
Corresponding page
pages are
must be displayed as
Enter username, displayed as per
per the VIT With the
Password as per the VIT the VIT with the
mentioned data base
and select a data base mentioned data
connection
9 Positive option and click on login base connection Pass
All the fields are
All the fields must be
cleared but the
cleared and the Cursor
Enter some information in cursor is not
should be placed in the
to any of the fields and placed in the
user name fields
10 Positive clear button user name field. Fail

Login screen should be

closed Login screens
11 Positive Click on the cancel button closed Pass
Tabbing order is
Tabbing order must be as follows
as follows User name, Username,
Password, Connect to, Password,
Check for the tabbing Login, Clear, Cancel Connect to Login,
12 Positive order of all the objects clear, Cancel Pass
Corresponding Corresponding
Enter username, messages should be error messages
Password as per the IVIT displayed as per IVIT are not displayed
13 Negative and click on login button as per IVIT Fail
Enter some information
only in to the user name
Login button must be
field and check for the
disabled
enabled property of login Login button is
14 Negative button enabled Fail
Enter some information
only in to the password
Login button must be
field and check for the
disabled
enabled property of login Login button is
15 Negative button enabled Fail

LOGIN OBJ TAB

Sno Obj Name Type

32
Page 33
1 User name Text Box

2 Password Text Box

3 Connect To Combo box

4 Login Button

5 Clear Button

6 Cancel Button

Valid Inputs Table

Sno User Name Password Expected Page Actual value Result

1 Suresh qtp Admin Admin Pass

2 Raja rani Home page Home page Pass

3 Chiru mbbs Home page Home page Pass

4 Praveen puppy Home page Home page Pass

5 NTR illu Home page Home page Pass

6 Admin Admin Admin Admin Pass

Valid Inputs Table (IVIT)

Sno User Name Password Expected Page Actual value Result

1 Suresh1 qtp Invalid User name Plz try again Admin Fail
Invalid User name Plz try
2 Raja2 rani Invalid User name Plz try again again Pass
Invalid password Plz try
3 Chiru DADA Invalid password Plz try again again Pass
Invalid password Plz try
4 Praveen TOPI Invalid password Plz try again again Pass
Invalid user name & Invalid user name &
5 NTR1 illu4 password Plz try again password Plz try again Pass
Invalid user name & Invalid user name &
6 Admin5 Admin6 password Plz try again password Plz try again Pass

33
Page 34

A test Engineer will do the following during the test execution

1. He will perform the action that is described in the description column

2. He will observe the actual behavior under the actual value column.
3. He will document the observed value under the actual value column.

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: -

The lists 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 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.

34
Page 35
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 Steps for Date Of Version Build Assign

Defect Id Description Reproducibility Submitter Submission NO No to Severity Priority Status
Initially Login, cear
buttons are
Not Applicable
enabled instead of
1 being disabled 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 Sri Balaji 11-Feb-08 1.0.0 1
1.Enter Suresh1 in
to the user name
Upon entering
field 2.Enter
Suresh1 as
qtp in to the
username and qtp
password field
as password and
3.Click on login
clicking on login
button
button admin page
4.Observe admin
is displayed instead
page is displayed
of error message
instead of error
message.
3 Sri Balaji 11-Feb-08 1.0.0 1

35
Page 36
1.Enter some
information in to
Up on entering the username field
information only in 2.Check for the
to the user name enabled property of
field login button is login button.
enabled instead of 3.Observe that login
being disabled button is enabled
instead of being
disabled.
4 Sri Balaji 14-Feb-08 1.0.0 1
1.Enter some
information in tho
Upon entering the password field
information only in 2.Check for the
to the password enabled property of
field login button is login button
enabled instead 3.Observe that login
being disabled button to enable
instead of being
disabled
5 Sri Balaji 11-Feb-08 1.0.0 1

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.

36
Page 37
Severity: -
How serious the defect is defined in terms of severity, Severity is classified
in to four types:

1.Fatal (Sev1) or S1 or 1
2.Major (Sev2) or S2 or 2
3.Minor (Sev3) or S3 or 3
4.Suggestion (Sev4) or S4 or 4

1.Fatal:
If at all the problems are related to the navigational blocks or unavailability of
functionality then such type of defects are treated to be fatal defect.

Val1
Main Menu Val2

Result UN
AVAILABL
ADD E
Next
Next Next

2.Major: -
If at all the problems are related to the working of major functionalities then
such types of defects are treated to be major defects.

Val1 10

Val2 20

Result -10

ADD

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

37
BAD
Page 38

4.Suggestions: -
If at all the problems are related to the value of the application then such type
defects are treated to be suggestions.

Some Invalid
+Ve integer Box alphabets 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.

38
Page 39

Bug Life Cycle: -

HOL
D

Testers
REQ error

As per
No design

Is it OP
DEV Rectific
Reall EN
ation
y
Defe
ct

M1
Build #1 Fixed for
verification
Is
defect
is Build #2
RE
TESTING
really
If
ope verifie
Defect
Clos
STOP TESTING
Nen ed 39
d
Page 40

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.

40
Page 41
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

41