Property of CCS Page |1

Manual Testing – Basic concepts

Scope of this Document:

This is to give just outline of testing process and few basic concepts of testing. Intended
users are who just need knowledge on manual testing. Please refer the reference docs
available for more information and clarity on the concepts.

1 . Software Quality Assurance:

          SQA are the Concepts to be followed by company to validate whether the software has been
developed as per the customer requirement. An SQA team is responsible for Monitoring &
Measuring the strength of developing processes.

A primary purpose for testing is to detect software failures so that defects may be discovered and
corrected
Testing methods:
a. White box testing :
Testing the actual code of the software product. This includes testing the data structures and
algorithms of the code to find the defects at early stage of software development.
b. Black box testing: testing the software product without the knowledge of its internal
design. This will do from usability and functionality perspective.
c. Grey box testing: involves having knowledge of internal data structures and
algorithms for purposes of designing the test cases, but testing at the user, or black-box
level. Manipulating input data and formatting output do not qualify as grey box, because
the input and output are clearly outside of the "black-box" that we are calling the system
under test
Test Case writing methodologies:
a. Equivalence partitioning
Dividing the input data into partitions of data, from which test cases can be derived. This will
reduce the repetitions of test cases on similar kind of input data.
Test Case: a user scenario or description of functionality of the product

Ex: if you want to test a product for input ranges 1-100. To find the possible defects, all inputs
from 1-100 are required. So, make a partition.
1-10 test case: starts from one digit and end with 2 digit.
95 – 100: maximum possible input range.
With this method we can reduce the number of test cases, this effects the same as 1-100 test
cases do.

b. Boundary value analysis

 Property of CCS Page |2

The method of writing test cases for the extreme ends of input data range including invalid
range is called boundary value analysis
Ex: a product required to be tested with input range from 1-100
We can do two partitions here
Input range 1: -1, 0, +1 (-1 and 0 are belongs to invalid input)
Input range 2: 99, 100, 101 (101 belongs to invalid input)

2. Software Development Life Cycle / Life Cycle Development: (in General)

            Stages involved in software project development

1)     Information gathering; Customer requirement
2)     Analysis; Customer requirement v/s Solutions
3)     Design; dividing the project into modules & coupling them .(HLD and LLD)
4)     Coding; Physical construction of project
5)     Testing
6)     Maintenance

Information gathering stage:

            In this stage, Business Analyst studies the requirement of the client /customer and
they prepare Business Requirement Specification (BRS) documents.

Analysis:
            In this stage, Sr. Analyst prepares Software Requirement Specification (S/w RS)
document with respect to corresponding BRS document. This document consists of two sub-
documents System Requirement Specification (SRS) & Functional Requirement Specification
(FRS). SRS contain details about software & hardware requirement. FRS contains details
about the functionality to be used in project.
Practically most of the times FRS and SRS are merged and made to called as SRS.

Designing:
          In designing phase, Designers creates two documents High Level Document (HLD) &
Low Level Document (LLD). HLD consists of main modules of the project from root to leaf
and multiple LLD’s. LLD consists of sub-modules of main module along with Data flow
diagrams, Entity Relationship-Diagrams(ERD), etc., are prepared by Functional experts or
Feature Experts support people or designers called Internal designers.

 Black box tester should have knowledge of customer requirement

 Black box testing tests BRS & SRS
 Testing external interfacing is Black box testing.(testing functionality of product)
 Testing internal interfacing is White box testing. (testing the code implemented)
 White box testing is done w.r.t design documents
Property of CCS Page |3

Testing: will go in details. Please scroll down

Maintenance:
Software maintenance in software engineering is the modification of a software product after delivery to
correct faults, to improve performance or other attributes

3. Different SDLC models

a. Waterfall model:
Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development is divided into
separate process phases.
The phases in Waterfall model are: Requirement Specifications phase, Software Design, Implementation and
Testing & Maintenance. All these phases are cascaded to each other so that second phase is started as and when
defined set of goals are achieved for first phase and it is signed off, so the name "Waterfall Model". All the methods
and processes undertaken in Waterfall Model are more visible.

Disadvantages:

1. Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing
customer requirements.
2. The lifecycle can take so long that the original requirements may no longer be valid by the time the
system is implemented.
3. Estimating time and costs is difficult for each stage.
Property of CCS Page |4

b. Prototype model:

A prototype is a working model that is functionally equivalent to a component of the product.

In many instances the client only has a general view of what is expected from the software product. In
such a scenario where there is an absence of detailed information regarding the input to the system, the
processing needs and the output requirements, the prototyping model may be employed. This model
reflects an attempt to increase the flexibility of the development process by allowing the client to interact
and experiment with a working representation of the product. The developmental process only continues
once the client is satisfied with the functioning of the prototype. At that stage the developer determines
the specifications of the client’s real needs.

Disadvantages :
1 .Implementing the prototype model for creating software has disadvantages. Since
its being built out of concept, most of the models presented in the early stage are
not complete. Usually they lack flaws that developers still need to work on them
again and again. Since the prototype changes from time to time, its a nightmare to
create a document for this software. There are many things that are removed,
changed and added in a single update of the prototype and documenting each of
them has been proven difficult.

2 There is also a great temptation for most developers to create a prototype and stick
to it even though it has flaws. Since prototypes are not yet complete software
programs, there is always a possibility of a designer flaw. When flawed software is
implemented, it could mean losses of important resources.
Property of CCS Page |5

3 Lastly, integration could be very difficult for a prototype model. This often happens
when other programs are already stable. The prototype software is released and
integrated to the company’s suite of software. But if there’s something wrong
the prototype, changes are required not only with the software. It’s also possible
that the stable software should be changed in order for them to be integrated
properly.

c. Spiral model:

The spiral model is similar to the incremental model, with more emphases placed on risk analysis.  The
spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation.  A software project
repeatedly passes through these phases in iterations (called Spirals in this model).  The baseline spiral,
starting in the planning phase, requirements are gathered and risk is assessed.  Each subsequent spirals
builds on the baseline spiral.

Spiral Life Cycle Model

Requirements are gathered during the planning phase.  In the risk analysis phase, a process is undertaken
to identify risk and alternate solutions.  A prototype is produced at the end of the risk analysis phase.
Property of CCS Page |6

Software is produced in the engineering phase, along with testing at the end of the phase.  The evaluation
phase allows the customer to evaluate the output of the project to date before the project continues to the
next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents
cost.

Advantages

 High amount of risk analysis

 Good for large and mission-critical projects.
 Software is produced early in the software life cycle.

Disadvantages

 Can be a costly model to use.

 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

d. V-Model (important)

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes.  Each
phase must be completed before the next phase begins.  Testing is emphasized in this model more so than
the waterfall model though.  The testing procedures are developed early in the life cycle before any coding
is done, during each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model.  Before development is started, a
system test plan is created.  The test plan focuses on meeting the functionality specified in the
requirements gathering.

The high-level design phase focuses on system architecture and design.  An integration test plan is created
in this phase as well in order to test the pieces of the software systems ability to work together.

The low-level design phase is where the actual software components are designed, and unit tests are
created in this phase as well.

The implementation phase is, again, where all coding takes place.  Once coding is complete, the path of
execution continues up the right side of the V where the test plans developed earlier are now put to use.
Property of CCS Page |7

V-Shaped Life Cycle Model

Advantages

 Simple and easy to use.

 Each phase has specific deliverables.
 Higher chance of success over the waterfall model due to the development of test plans early on
during the life cycle.
 Works well for small projects where requirements are easily understood.

Disadvantages

 Very rigid, like the waterfall model.

 Little flexibility and adjusting scope is difficult and expensive.
 Software is developed during the implementation phase, so no early prototypes of the software
are produced.
 Model doesn’t provide a clear path for problems found during testing phases.

 4. Testing

Systematic approach to validate whether the product has been built as per the customer
requirements are not.
OR
Wiki answer: Software testing is an investigation conducted to provide stakeholders with information
about the quality of the product or service under test. Software testing also provides an objective,
independent view of the software to allow the business to appreciate and understand the risks at
implementation of the software. Test techniques include, but are not limited to, the process of executing a
program or application with the intent of finding software bugs.

A test strategy is an outline that describes the testing portion of the software development cycle. It is
created to inform project managers, testers, and developers about some key issues of the testing
process. This includes the testing objective, methods of testing new functions, total time and resources
required for the project, and the testing environment.

5. STLC (Software Test Life Cycle)

Property of CCS Page |8

Software Testing Life Cycle:

Software testing life cycle or STLC refers to a comprehensive group of testing related
actions specifying details of every action along with the specification of the best time to
perform such actions. There can not be a standardized testing process across various
organizations, however every organization involved in software development business,
defines & follows some sort of testing life cycle.

STLC by & large comprises of following Six Sequential Phases: 

1) Planning of Tests

2) Analysis of Tests

3) Designing of Tests

4) Creation & Verification of Tests

5) Execution of Testing Cycles

6) Performance Testing, Documentation

7) Actions after Implementation

Life Cycle of Software Testing ( STLC )

Phase Activities Outcome

Planning of Tests Creation of a Test Refined Test Plans

Plan of High Level & Specifications

Analysis of Tests Creation of fully Refined Test Plans,

descriptive Test Test Cases &
Plan Matrix for
Functional
Creation of Matrix Validation
for Functional
Validation 

Creation of Test
Cases

Designing of Revision of Test Refined Test

Tests  Cases Cases, Input Data
Sets & Documents
Selection of Test for Assessment of
Cases fit for Risk
automation

Creation & Creation of scripts Detailed

Verification of suitable for Test Procedures for
Tests Cases for Testing, Testing
automation Scripts, Test
Reports & Bug-
Reports
Property of CCS Page |9

Execution of Completion of Detailed Test

Testing Cycles Cycles of Testing  Reports & Bug-
Reports.

Performance Execution of Test Test Reports,

Testing, Cases related to Documentation on
Documentation performance tests various metrics
& Stress Testing used during
testing
Detailed
documentation

Actions after Evaluation of all Detailed Plans for

Implementation Processes of improving the
Testing process of testing

1) Planning of Tests:
In this phase a senior person like the project manager plans & identifies all the areas where
testing efforts need to be applied, while operating within the boundaries of constraints like
resources & budget.. Planning is not limited just to the initial phase, rather it is a continuous
exercise extending till the end. 

During the planning stage, the team of senior level persons comes out with an outline of
Testing Plan at High Level. The High Level Test Plan comprehensively describes the
following:

 Scope of Testing : Defining the areas to be tested, identification of features to be

covered during testing 
 Identification of Approaches for Testing: Identification of approaches including
types of testing
 Defining Risks: Identification of different types of risks involved with the decided
plan
 Identification of resources : Identification of resources like man, materials &
machines which need to be deployed during Testing
 Time schedule: For performing the decided testing is aimed to deliver the end
product as per the commitment made to the customer. 

Involvement of software testers begins in the planning phase of the software

development life cycle. During the design phase, testers work with developers in
determining what aspects of a design are testable and with what parameters those
tests will work.

2) Analysis of Tests:
Based upon the High Level Test Plan Document, further nitty-gritty’s covering the following
are worked out.

 Identification of Types of Testing to be performed during various stages of Software

Development Life Cycle.
 Identification of extent to which automation needs to be done. 
 Identification of the time at which automation is to be carried out. 
 Identification of documentation required for automated testing
Property of CCS P a g e | 10

The Software project can’t be successful unless there is frequent interaction among various
teams involved in Coding & Testing with the active involvement of the Project Managers,
Business Analysts or even the customer. Any deficiencies in the decided test plans come to
the surface, during such meetings of cross-functional teams. This provides an opportunity to
have a rethinking & refining the strategies decided for testing.

Based upon the customer requirements a detailed matrix for functional validation
is prepared to cover the following areas:

 Ensure that each & every business requirement is getting covered through some test
case or the other.
 Identification of the test cases best suited to the automated testing

 Identification of the areas to covered for performance testing and stress testing
 Carry out detailed review of documentation covering areas like Customer
Requirements, Product Features & Specifications and Functional Design etc.

3) Designing of Tests:
This phase involves the following:

 Further polishing of various Test Cases, Test Plans

 Revision & finalization of Matrix for Functional Validation.
 Finalization of risk assessment methodologies. 
 In case line of automation is to be adopted, identification of test cases suitable for
automation.
 Creation of scripts for Test cases decided for automation. 
 Preparation of test data.
 Establishing Unit testing Standards including defining acceptance criteria 
 Revision & finalization of testing environment.

4) Construction and verification:

This phase involves the following:

 Finalization of test plans and test cases

 Completion of script creation for test cased decided for automation.
 Completion of test plans for Performance testing & Stress testing.
 Providing technical support to the code developers in their effort directed towards
unit testing.
 Bug logging in bug repository & preparation of detailed bug report. 
 Performing Integration testing followed by reporting of defects detected if any.

5) Execution of Testing Cycles:

This phase involves the following:

 Completion of test cycles by executing all the test cases till a predefined stage
reaches or a stage of no detection of any more errors reach. 
 This is an iterative process involving execution of Test Cases, Detection of Bugs, Bug
Reporting, Modification of test cases if felt necessary, Fixing of bugs by the
developers & finally repeating the testing cycles.
Property of CCS P a g e | 11

6) Performance Testing, Documentation & Actions after Implementation:

This phase involves the following:

 Execution of test cases pertaining to performance testing & stress testing.

 Revision & finalization of test documentation 
 Performing Acceptance testing, load testing followed by recovery testing
 Verification of the software application by simulating conditions of actual usage.

7) Actions after Implementation:

This phase involves the following:

 Evaluation of the entire process of testing. 

 Documentation of TGR (Things Gone Right) & TGW (Things Gone Wrong)
reports. Identification of approaches to be followed in the event of occurrence of
similar defects & problems in the future.
 Creation of comprehensive plans with a view to refine the process of Testing.
 Identification & fixing of newly cropped up errors on continuous basis.

6. Contents of Test plan (IEEE format)

TEST PLAN OUTLINE

1) Test Plan Identifier
2) References
3) Introduction
4) Test Items
5) Software Risk Issues
6) Features to be Tested
7) Features not to be Tested
8) Approach
9) Item Pass/Fail Criteria
10) Suspension Criteria and Resumption Requirements
11) Test Deliverables
12) Remaining Test Tasks
13) Environmental Needs
14) Staffing and Training Needs
15) Responsibilities
16) Schedule
17) Planning Risks and Contingencies
18) Approvals
19) Glossary
Please see the Test Plan IEEE.docx for more info

7. Test Matrix

A test matrix is simply a spreadsheet that suggests test and captures test results by laying them
out in the form of a table. A test matrix can be used for a number of purposes:
Property of CCS P a g e | 12

A test matrix can be used for a number of purposes:

 to record a consistent set of tests;

 to document a desired level of test coverage based on an intersection of two criteria and,

when filled out, to be used as evidence that the desired amount of testing has been done;
 as a quick visual indication of how much testing has been done on those criteria;

 to help to identify and refine the specific environments in which a defect occurs;

 When it is completely filled out, as a checklist to assure that some exhaustive task has

been completed.

Traceability Matrix

A traceability matrix is the plot of Test cases against the requirement of the product, majorly
used to make sure the completeness of the requirement coverage.
Example :

Requirement ---> Req1 Req2 Req3 Req4 Req4 Req5

# of Test cases --> 3 3 3 2 3 4
Test cases            
TC0     x   x  
TC1 x   x     x
TC2         x  
TC3   x   x    
TC4 x          
TC5         x  
TC6     x     x
TC7   x        
TC8 x         x
TC9   x   x   x
Property of CCS P a g e | 13
Property of CCS P a g e | 14

8. Bug Life Cycle

7. Verification and Validation

Verification : the process of examining the product at end of each/specified phase of product
development, to make sure product is built in right manner as planned

Have we built the software right? (i.e., does it match the specification).

Validation :(Quality Assurance) process of establishing evidence that provides a high

degree of assurance that a product, service, or system accomplishes its intended requirements.
This often involves acceptance of fitness for purpose with end users and other product
stakeholders.

Have we built the right software? (i.e., is this what the customer wants).
Property of CCS P a g e | 15

8. Different Types of Testing

Functionality testing

Functional Testing is conducted to evaluate the compliance of a system or component with

specified functional requirements and corresponding predicted results. Every aspect of testing
under this section will be directly related to functionality of the product

Unit testing: it is a method by which individual units of source code are tested to determine if
they are fit for use. A unit is the smallest testable part of an application like a function or
procedure.

Integration Testing: Individual software modules are combined and set of test cases will be
executed against that.

The purpose of integration testing is to verify functional, performance, and reliability

requirements with respect to the group(unity of modules)

User Acceptance Testing: (it is a part of functional testing) A User Acceptance Test is
conducted to determine whether or not a system satisfies its acceptance criteria and to enable
the customer to determine whether or not to accept the system. A User Acceptance test is
performed purely from the application user’s perspective.

Adhoc Testing: the process of testing without any documentation and planning from the
usability perspective.

Smoke testing: after the repairs or assembly of the product, smoke test will be done to make
sure the product has not broken because of latest changes.

Sanity testing: it is the basic tests to quickly evaluate whether product can be go for further
intense testing. In this testing, major functionalities of the product will be tested and will pass to
the regression testing.

Alpha testing: it is the testing done by potential users/customers or an independent test team
at the developers' site

Beta Testing: The software is released to groups of people for further testing can ensure the
product has few defects. This will be done prior to major customer release.
Property of CCS P a g e | 16

Non - Functionality testing

Compatibility testing: is testing conducted on the application to evaluate the application's

compatibility with the different computing environments like different browsers and OS’s .

Performance testing: is how fast the system can perform under particular workload.

Stability testing /Load testing: Stability testing checks to see if the software can
continuously function well in or above an acceptable period. It implies the other way of load
testing

Security testing: method to test whether the confidential date is secured from unauthorized
access.

Localization testing: checking the product whether it performs the same with different
operating languages (so that software can be marketed to different countries with same core
code and functionality)
Property of CCS P a g e | 17

Testing : over all view diagram