Project: It is something that is developed

based on the customer’s specification and

used by that particular customer

Product:
It is something that is developed by the
manufacturer’s specifications and used by
multiple customers and customized
according to the specifications

What is Quality?
Justification of requirements either in a
product or in a project;
Quality: Classical definition
Quality is not defined in the product or in
the project but defined in the customer’s
mind.
Latest definition of Quality:
Not only justification of requirements but
presence of value (user friendliness)
Defect: Deviating from the requirement

Testing:
It is process of identifying the defects,
isolating the defects, subjecting the defects
for rectification and ensures that the
product is defect free in order to produce a
quality product at the end; And hence
customer satisfaction.

Bidding of the Project:

It is defined as request for proposal,
estimation and signing off.

Kick off meeting:

It is the initial meeting conducted in the SW
company soon after the project is signed off
in order to discuss the overview of the
project, and to select a project manager.

PIN: Project Initiation Note

It is mail prepared by the project manager
and sent to the CEO of the SW company in
order to get the permission to start the
project development.

SDLC Phases:

Phase 1: Initial or requirements phase

Roles: Business Analyst and Engagement
Manager

Task of the Business Analyst:

Takes an appointment from the customer,
collects the template from the SW company,
meets the customer on the appointment
date and time, interacts with the customer
using the template and converts the
template as document and submits the
same to the SW company to make sure that
they both are on the same page.
Task of the Engagement Manager:
Responsible for following:
1) Deals with the excess cost of the project
2) Responsible for the prototype
demonstration:
Prototype is a roughly and rapidly
developed model.

Output document or proof document from

Initial Phase is called FRS or “functional
Requirement Specification.” It is also called
as BRS or Business Requirement
Specification or URS user requirement
specification or CRS client requirement
specification or BDD Business Design
Document or BD business document.

Phase 2: Analysis phase: Input document

for this phase is FRS
Roles: 1) System Analyst, 2) Project
Manager and
3) Team Manager
Tasks:
1) Feasibility study:
 A detailed study of the requirements in
order to check if they are feasible or not;
2) Tentative planning:
The resource as well as the time is
temporarily planned here;
3) Technology selection:
What are all the technologies that are
required for accomplishing this project
successfully are analyzed and listed off.
4) Requirement Analysis:
What are all the requirements that are
required to accomplish the project
successfully are analyzed and listed out.
Proof document or Output document from
Analysis phase is SRS (Software
requirement specification or System
requirement specification)

Phase 3: Designing phase

Input document for this phase is SRS.
Roles:
Chief Architect and Technical Lead

Tasks:
High Level Designing (HLD):
The process of dividing the project into
modules is known as HLD usually performed
by Chief Architect.

Low Level Designing (LLD):

The process of dividing the modules into sub
modules is known as LLD usually performed
by the Technical Lead.
Output document or Proof document from
designing phase is TDD technical Design
document. It contains of some diagrams and
pseudo code

Phase 4 Coding phase:

Input document for this phase is TDD.

Roles:
Programmers or developers

Tasks: Programming or Development

Process: Developers using the pseudo code

and following the coding standards like
proper indentation, proper commenting and
colour coding etc. develops the actual
source code of the project.

Output document or proof document from

the coding Phase is SCD source code
document.

Phase 5: testing phase

Input document is FRS functional
Requirement specification
Roles: Test Engineers

Task: Testing

Process: FRS review.

Prepares the review report; in doubt sends

to the author of the document for
clarification; after understanding all the
requirements clearly, takes the test case
template and develop the test cases.

Once the build or module is released then

executes the test cases.

After the execution:

 Identifies the defects and isolate the
defects. Subject the defects to the
developers for rectification.
 Ensures that the product is defect free
 If any defects are identified, the same
process continue till the product is defect
free
 Output or proof of testing phase is
Quality Product or the Product which is
working as per the customer’s
expectation.
Test CASE definition:

This is a check list of all the deferent

perceptions of a test Engineer in order to
test a specific functionality.

Phase 6: Release and maintenance

Release:

Roles:
Deployment engineer or Senior Test
Engineer

Tasks:
Deploying or installation

Process: The deployment engineer will

deploy the application into the client
environment following the guidelines given
in the Deployment document by the
development team.

Maintenance: After release if at all any

problem is there with the SW then that
problem will become a task depending upon
that problem the corresponding role will be
appointed and he defines the process based
of the issue and resolves the issue.

There are 2 sorts of testing.

1. Unconventional
It is a sort of testing which is conducted on
each and every out come document right from
the initial stage onwards by the Quality
Assurance people
2. Conventional
It is also known as formal testing performed by
the test engineers.

Testing Methodology or Testing Techniques:

White box Testing:

If one performs testing on the structural part of
the application then it is known as WBT usually
developers perform it.

Black Box Testing:

If one performs testing on the functional part of
the application with out having structural
knowledge then that method of testing is known
as BBT. Usually test engineers perform it.

Gray Box Testing:

If one performs testing on both functional as well
as structural part of an application then that
method of testing is known as GBT. Usually the
test engineers with structural knowledge
perform GBT.
Levels of Testing:

Unit level: Smallest part of an application.

One performs testing of a unit is called Unit level
testing.
It is performed by the developers as this is
structural and called WBT.

Module level:
Collection of units is module. So a module will
have some functionality and BBT is the method
used due to it functionality feature.

Integration Level:
Once the modules are all ready, then the
developers will try to integrate the modules and
perform testing to make sure that the modules
are integrated properly or not. This is a WBT.

Integration of modules can be done 4

approaches;

1. Top Down Approach (TDA)

In this approach the parent modules are
integrated with the sub modules.

STUB: While integrating the modules in TDA, if

any mandatory module is missing that module
is replaced with a temporary program know as
STUB.

2. Bottom Up Approach (BUA)

 In this approach the sub modules are
integrated with the parent modules.

Driver: While integrating the modules in BUA, if

at all any mandatory module is missing that
module is replaced with a temporary program
known as Driver.

3. High breed or Sandwich approach

This approach is the mixer of TDA and BUA.

4. Big Bang Approach (BBA)

Once all the modules are ready integrating
them at a time is known as BBA.

System Level Testing:

Once the application is ready, it is deployed into
an environment and is prepared as a system. If
one performs testing on the system then it is
known as system level testing and it is a BBT

User acceptance Testing:

If one performs same system testing in the
presence of the user, then it is known as user
acceptance testing. It is also BBT.

Environment:
An environment is a combination of 3 layers

1) Presentation Layer

2) Business or application layer

 3) Database layer

Types of environments:
There are 4 types of environments
JayaQA\SDLC methods.ppt

1) stand alone environment or 1 tier

architecture:
If the 3 layers i.e. presentation, business or
application and database layer resides in a
single system, then it is known as stand alone
environment.

2) Client server or 2 tier Architecture:

If at all the presentation and business layers
reside in the client system and database layer
resides in the server system then it is known as
2 tier architecture or client server environment

3) Web Environment or 3 tier Architecture:

It contains 3 tiers where in the first tier

contains Presentation or clients, the second or
the middle contains the application server and
the third tier contains the database server.

4) ‘N’ tier architecture or distributed

environment or multi tier architecture:

Which is similar to the web environment but

the business logic is distributed among a
number of application servers in order to
distribute the load.
Software Development Life cycles Models:
SW development Life cycle Models
1) Water fall or sequential model or Linear model
2) Prototyping model
3) Evolutionary model or the fickle minded
4) Spiral model
5) Fish model
6) V model

Software efficiency formula:

DRE = A/ A+B
DRE = Defect Removal Efficiency
A = Defects found by the Test engineer
B= defects found by the end user or the client.

Types of Testing:

1) sanity testing or smoke testing or Build

verification testing or initial testing (look and
feel)

2) regression testing:
In which already tested functionality is tested
again mainly in 2 scenarios.
A) When ever the defects are rectified by the
developer and the next build is released to
the testing department then the test Engineer
will perform testing not only on the defects
part but also on the related functionality once
again.

B) When ever the new changes are

incorporated by the developer and released
 to the testing department then the Test
Engineer will perform testing on the old
tested part once again in order to ensure that
its old functionality is not affected due to the
new changes.

3) Retesting
In which already tested functionalities, tested
once again with multiple sets of data in order
to ensure whether the functionality is working
fine or not. If any defect, whether it is
reproducible or not?

Alpha testing:
It is a type of user Acceptance Testing UAT. A
test engineer performs testing on an application
in the presence of the user within the company.
The advantage is if any defects are found then
there is a chance for rectifying immediately.

Beta Testing:
It is a type of UAT conducted in the client’s place
either by the 3rd party testing units or by the end
users. The disadvantage here is, if any defects
are found then there is no chance for rectifying
immediately.

Usability Testing:
It is a type of testing in which a test engineer
will only focus on the user friendliness of the
application.

Static Testing:
One performs testing on the application or
application related factors whenever it is not
being executed. Ex: document testing and GUI
testing.

Dynamic Testing:
If at all one performs testing on an application
when ever it is being executed then that type of
testing is known as Dynamic testing. Ex:
functionality testing

Installation Testing:
A test engineer will deploy or installs the
application into the environment following the
guidelines given by the development team in the
form of deployment document. If the installation
is successful then he will come to a conclusion
that the guidelines are correct.

Compatibility Testing:
A test Engineer may have to deploy the
application into the environments prepared with
different environmental components like
browsers, application servers, web servers,
Operating systems and databases and check
whether the application is compatible with those
environments.

Port Testing:
One will deploy the application into the client
environment and check whether it is compatible
with that environment or not.
Monkey Testing:
It is type of stress testing in which one will
perform abnormal actions on the application
intentionally in order to check its stability.

Exploratory Testing:
Usually one will be exploring the functionality
and simultaneously testing the functionality.
Usually domain experts will perform it.

Security Testing:
Authentication Testing:
In this type of testing, the test engineer will
check if the application is accessed by the
authorized person or not

Direct URL Testing:

Test Engineer will enter direct URL into the
address bar of the browser and try to access
those pages to make sure that they are not
accessible with out proper authentication.

Firewall leakage Testing:

A test engineer will check weather the
implemented firewalls are working properly
or having any leakage.

Soak Testing:
It is also a type of stress testing. Test Engineer
will perform testing on the application for longer
period of times and checks weather the
application is stable or not.
Mutation Testing: WBT
It is a WBT performed by the developers where
in he will do some complex changes and checks
the performance of it. Since it is associated with
different mutants (Logic) it is known as mutation
testing.

End to End Testing:

In which performs testing on one complete
transaction from one end to the other end of the
application.

ADHOC Testing:
A test engineer will understand the requirements
and performs testing on the application in his
own style with out following any formal
procedure or norms.

SOFTWARE TESTING LIFE CYCLE: STLC

1. Test planning:
This describes how to perform testing on an
application in an effective, efficient and in an
optimized way. Quality lead or test lead will
prepare the test plan.

INDEX or Contents of the TEST PLAN:

1.0 Introduction

1.1 Objective
1.2 reference documents
2.0 Coverage of testing

2.1 features to be tested

2.2 Features not to be tested

3.0 Test strategies

3.1 Levels of testing

3.2 Types of testing
3.3 Test designed techniques (BVA)
boundary Value partition (ECP) Equal
class partition
3.4 Configuration management
3.5 Test metrics
3.6 Terminologies
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 Deliverables

6.0 Test environment

7.0 Resources planning

 8.0 Scheduling

9.0 Staffing and training

10.0 Risks and contingency plan

11.0 Assumptions

12.0 Approval information

2. TEST DEVELOPMENT:

Use case:
It describes the functionality of certain
features of an application in terms of ‘actor’,
‘action’ and ‘response’.

Input information required to prepare the

‘USE CASE’ document
a) Screen shot or snap shot
b) FRS or functional requirements
specification
c) BRS or Business requirement specification
or Special requirement specification
d) Use case template
a) Name
b) Brief description of the ‘Use Case’
c) Actors involved
d) Special requirement, Explicit (FRS)
and implicit requirements (business
people)
e) Precondition
f)Post condition and
 g) Flow of events. (Main flow)
(Alternative flow)

MAIN FLOW:

ACTION RESPONSE
1) Actor invokes the Log in screen is displayed
application with the following fields:
User
Name/password/connected
to/Login/clear/cancel
2) Actor enters valid User Authenticates either home
name, valid pw and click page or Admin page is
on Login button displayed depending the
Actor entered
3) Actor enters valid user Authenticates either home
name and valid pw and page or Admin page is
selects a database options displayed with the
and clicks on login button mentioned database
connection.
4) Actor enters invalid Go to Alternative flow Table
username, Valid PW and 1
clicks on login button
5) Actor enters valid Go to Alternative flow Table
username, in Valid PW 2
and clicks on login button
6) Actor enters some Go to Alternative flow Table
information into any of 3
the fields and clicks on
clear button
7) Actor clicks on cancel Go to Alternative flow Table
button 4

ALTERNATIVE FLOW:
 Table 1 (invalid Username):
ACTION RESPONSE
Actor enters invalid An error message should
username, Valid PW and be displayed “invalid user
clicks on login button name. Please try again”

Table 2 (Invalid PW)

ACTION RESPONSE
Actor enters invalid PW, An error message should
Valid Username and clicks be displayed “invalid PW.
on login button Please try again”

Table 3 (Clear Click)

ACTION
Actor enters some
information into any of the
fields and clicks on clear
button
RESPONSE
All the fields should be
cleared and the cursor
should be placed in”User
name” field.

Table 4 (Cancel click)

ACTION RESPONSE
Actor clicks on cancel Login screen should be
button closed.

GUIDELINES TO PREPARE TEST CASES FROM A GIVEN

‘USE CASE’:

Security:
Identify the module to which the ‘USECASE’ belongs to
(Security module)

Authentication:
Identify the functionality of the UC with respect to the
total functionality of the application.

Identify the functional points and prepare the functional

point documents.
Functional Point examples:
1) user name
2) passwords
3) connect to
4) login
5) clear
6) cancel

Identify the inputs that are required to perform the

UC (use case) EX: Valid and invalid inputs

Identify the actors involved in the use case.

Ex: Admin user and normal user

Identify if the use case is linked with any other use

case
EX: home page or Admin page

Identify the precondition:

Ex: login screen or the initial screen should be
available

Identify the post condition:

EX: for valid user’s valid page and error message
for invalid users.

Understand the ‘Main Flow’ of the use case

The ‘Main Flow’ indicates the main purpose of the
application and the remaining all comes under
‘Alternative Flow’.

Document the Test Cases for the Main Flow

Document the Test Cases for the Alternative Flow
 Prepare the Cross reference matrix or traceability
matrix
This table is useful for tracing the exact location of
the defect.
And it also useful for to check for all the
requirements of the customer are covered by the
developers.

CROSS REFERENCE MATRIX OR TRACEABILITY

MATRIX TABLE
USD (user FPD MTCD DTCD DPD
specification Functional Master Test Detailed Defect
Document) Point Case Test Case Profile
Document Document Document Document
3.5 13 12 8 1
This
document
explains the
number of
test cases
that can be
developed
on a
particular
functionality.

Classification of the TEST CASES:

Types of Test Cases:
Test cases are broadly divided into 2 types
User Interface Test Case:

Guidelines:
 Check for the availability of all the objects in the
application.
Check for the alignment
Check for the font, color and consistency
Check for the spelling and grammar

Functional Test Case:

Divided in to 2 types
a) Positive: Test Engineer should have
positive perception
Considers only the positive flow of the
application by using the valid inputs

b) Negative:
Test Engineer should have negative perception
to consider only the negative flow of the
application by using invalid inputs

TEST CASE TEMPLATE:

1) Test case Objective
2) Test scenario
3) Test procedure
4) Test Data
5) Test Case

Test Test Description Expected Actual Value Result Remarks

Case ID Case (expression Value
Type must be (must use the
commanding) word ‘should’)
LOG_001 User Check for the All the objects All the objects Pass None
 Inter availability of should be are available
Face UI all the available as as per the
objects per the object’s table
object’s table.
LOG_002 UI Check All the objects All the objects Pass None
Spellings of should be are spelled as
all the spelled as per per the
objects the Object’s object’s table
Table
LOG_003 UI Check All the objects All the objects Pass None
consistency should be are consistent
of all the consistent
Objects
LOG_004 UI Check ‘LOG IN and Log in, clear, Failed Log in
‘enabled CLEAR’ cancel and clear
property of buttons buttons are buttons
LOG IN and should be enabled are
CLEAE, disabled and enabled
CANCEL’ ‘CANCEL’
buttons button must
be always
enabled.
LOG_005 Positive Enter the Correspondin Correspondin Pass
Test User Name g pages g pages are
Case and PW as should be displayed as
per the Valid displayed as per the Valid
Inputs Table per the ‘valid input’s table
and click on input’s table’
Login button
LOG_06 Positive Enter some All the fields All the fields Failed Tab
information should be are clear but action is
into any of cleared and the cursor is not
the fields and cursor should not default defaulting
click on be placed in into User to the
‘Clear button’ the user name name field User
field Name
field after
clear.
LOG_07 Positive Click ‘Cancel’ Login screen Log in screen Pass
Button should be is closed
closed
LOG_08 Negative Enter ‘USER Correspondin Correspondin Failed
NAME’ and g Error g error
Pass word as messages messages are
per the should be not displayed
invalid displayed as as per the
input’s table per the invalid invalid input’s
and click on inputs table. table. Refer to
‘LOG IN’ Invalid
 button Input’s table
for details

Objects Table:

Serial Number Object Type Object Name

1 Text Box User Name
2 Text Box Pass Word
3 Combo/drop down box Connect to
4 Button Log in
5 Button Clear
6 Button Cancel

Valid Input’s Table:

S.NO User Name Password Expected Actual Result

Value Value
1 Sai Prema Admin page Admin Pass
should be Page is
displayed displayed
2 Ram Love Home page Home Pass
displayed page is
displayed
3 Alla Akbar Sales Page Sales page Pass
is
displayed

Invalid Inputs Table:

S.NO User Password Expected Value Actual Value Result
Name
1 Kjkdjkj Prema Error message Home page is Fail
should be displayed
displayed.
”Invalid user
name. Please try
again”
2 Sai Nidfje Error message Error message Pass
should be is displayed
displayed. ‘invalid
“Invalid PW. password
Please try again” please try
again’

3. Test Execution Phase:

In this phase, test engineer has to do the
following things:

1) Perform the action that is described

in the description column of the Test
Case document.
2) Observes the actual behavior of the
application
3) Documents the observed value under
actual value column of the Test Case
Document

4) Result Analysis Phase:

In this Phase the test engineer will compare

the actual values with the expected values.
If both are matched then it is decided that
the result is pass other wise the result is
Fail.

5) Bug tracking Phase:

In bug tracking phase, the defects are

identified, isolated and documented and the
documents must be maintained for next
testing.

Defect Profile Document:

Defe Defect Steps Sub Date Build Versi Assig Seve Prior Stat
ct ID Descrip for mitt of num on ned rity ity us
tion reprod er Sub ber num to
ucibilit miss ber
y ion
Inde Defect Instru
x scenari ctions
num o to
ber reprod
like uce
a the
prim defect
ary
Key

Severity:
This describes how sever the defect is. It is classified
in to 4 types.
1) Fatal:

If the defects are related to navigational blocks, or

unavailability of functionality then such types of
defects are treated to be FATAL.
1) Major:
If the defects are related with the major
functionalities working then such types or defects are
treated to be MAJOR.
2) Minor:
If the defects are related to the look and feel of the
application then such types of defects are treated to
be MINOR.
3) Suggestion:
This is not considered as defect. But if the test
engineer wants to give a suggestion to a developer in
order to increase the value of the application then
such types are called SUGGESTIONS.

Priority:
This describes the sequence in which the defects have
to be rectified. Usually it is given by the senior Test
Engineer or Test Lead and can be changed by the
project lead according to his convenience depending on
the situation.

Priorities are classified in to 4 types:

1) Critical: Usually critical is given to FATAL.
2) High: This is given to MAJOR
3) Medium: This is given to MINOR
4) Low: This is given to SUGGESTION
But depending upon the situation the priority may be
changed.

STATUS:
There are 7 Status steps for a DEFECT

1) New or OPEN
Initially when ever the defect is identified by the Test
Engineer newly, then he will set the status as NEW or
OPEN
2) RE OPEN:
If the Test Engineer feels that the raised defect is not
rectified properly by the developer then he will set
the status as RE OPEN.
3) CLOSED:
When the Test Engineer feels that the raised defect is
rectified properly then the Test Engineer will set the
Status as CLOSED.
4) FIXED FOR VERIFICATION:
When ever the raised defect is accepted and rectified
by the developer, then he will set the STATUS as
‘FIXED FOR VERIFICATION’.
5) HOLD:
When ever the Developer is in a dilemma to accept or
reject the defect then he will status to HOLD.
Note: a triage meeting is conducted to resolve these
HOLD status defects. Team lead, corresponding
developer and Test Engineer are involved in the
Triage meeting.
 6) AS PER DESIGNE:
When the new changes are incorporated by the
developer into the build, and the test engineer is not
aware of the updates, then he will raise them as
defects. But the developer will set the status AS PER
DESIGNE.
7) TESTER’S ERROR:
If the Developer feels that it is not at all a defect then
he will set the status of the defect as ‘TESTER’S
ERROR’.
Note: Tester’s errors are kind of warnings for the
testers.

6) REPORTING PHASE:

CHECK THE DIAGRAM

WAYS OF TESTING:
There are 2 ways of testing:
1) Manual Testing:
It is a process in which all the phases of the testing life
Cycle (STLC)
Like test planning, test development, test execution,
Result Analysis, bug tracking and Reporting are
accomplished manually with human efforts.

Draw backs of Manual Testing:

More number of people are required (Man power)
Time consuming
Human Errors
Tediousness
Repetitiveness
Simultaneous actions not possible

2) Automation Testing:
This is a process in which all the drawbacks of manual
testing are addressed properly and provide speed and
accuracy to the existing testing process.

Advantages of Automation:
Virtual users over come the man power issues
As it is a SW component, Time, Tediousness, accuracy
are overcome
Record and Playback facility addresses the
repetitiveness
Rendezvous point feature over comes the simultaneous
action problem

Drawbacks of Automation:
Cost efficiency
Expertise person not available to use the
application
Can not automate all the areas in a project EX:
GUI

---The End-------