TABLE OF CONTENTS

Chapter 1
Introduction to software testing…………………………………………………………………………………3

Chapter 2
Software Development life cycle and Software Quality……………………………………………………. 6

Chapter 3
Static Techniques.......................................................................................................................................9

Chapter 4

Types of testing……………………………………………………………….…………………………………..12

Chapter 5
Different Software testing models………………………………………….…………………….……………17

Chapter 6
Test Data Preparation Techniques…………………………………………………………………………….32

Chapter 7
Testing Department………………………………………………………………………………………………36

Chapter 8

Test Plan and Test plan template………………………………………………………………………………42

Chapter9

Test Management…………………………………………………………………………………………………45

Chapter10

Test Execution……………………………………………………………………………………………………..50

Chapter 11

Defect template……………………………………………………………………………………………………52

Chapter 12

Defect life cycle……………………………………………………………………………………………………54

Chapter 13

Test closure………………………………………………………………………………………………………..59

Chapter 14

Testing Terminologies……………………………………………………………………………………………61
Chapter 1

Introduction to Software Testing

The software testing is as important as the development. You will not able to maintain the product quality
until unless you have applied proper testing and quality measures.
If you go through the software evaluation history you will come to know a small bug has cost a million
dollar losses even some time it endanger many lives.

1.1 What is Software Testing?

Software Testing is a process of analyzing a software to detect the differences between actual and
expected requirements.
Any program or software is written by human and human are bound to make mistakes. However we
can overcome this limitation with the proper planning and testing. Testing helps us to identify the root
cause of the error it also helps to prevent errors. Also it helps to find the defect and bugs before the time
i.e. before the system get in to the production or before it get live.
0
Testing provide us many process and control procedure to control the bugs like if bugs are found then by
doing the root cause analysis we can minimize the cause of it. There are certain matrixes which helps you
to identify and alert you if bugs are going beyond control so that you can take appropriate action.

1.2 Why to do Software testing

1. As mentioned above, humans are bound to make mistakes. To find the bug/mistakes made during
coding, testing is required.

Following example of Mercury spacecraft will explain the necessity of the testing:

The computer program ABOA spacecraft contained the following statement with the FORTRAN
programming language.
.DO 100 I = 1.10
The programmer's intention was to execute a succeeding statements up to line 100 ten times then
creating a loop where the integer variable I was using the loop counter, starting 1 and ending at 10.
Unfortunately, what this code actually does is writing variable I do to decimal value 1.1 and it does that
once only. Therefore remaining code is executed once and not 10 times within the loop. As a result
spacecraft went off course and mission was abort considerable cost!).
The correct syntax for what the programmer intended is:--
.DO 100 1=1, 10
so a small mistake make a very big thing.

1. To ensure the built product meets the business requirement

2. To ensure the software quality
3. To meet the customer’s satisfaction.

1.3 What to test?

The functionality under testing is decided on what’s important. Good business requirement explains what
is important. Not always the code is wrong, many times the code is correct but the requirements captured
are wrong. Hence the scope of testing includes following:

1. Business Requirements
2. Functional Requirements
3. Technical Specifications
4. Programmer code
5. Hardware configuration
6. Language differences

1.4 Cost of errors in Software testing:

The cost of an error can vary from nothing at all to large amounts of money and even loss of life. The
aborted Mercury mission was obviously very costly but surely this is just an isolated example. Or is it?
There are hundreds of stories about failures of computer systems that have been attributed to errors in
the software. A few examples are shown below:
A nuclear reactor was shut down because a single line of code was coded as X = Y instead of X=ABS (Y)
i.e. the absolute value of Y irrespective of whether Y was positive or negative.

1.5 Reliability in Software Testing:

Reliability is the probability that software will not cause the failure of a system for a specified time under
specified conditions. Measures of reliability include MTBF (mean time between failures), MTTF (mean
time to failure) as well as service level agreements and other mechanisms.

1.6 Exhaustive testing why not test everything?

It is now widely accepted that you cannot test everything in Software Testing. Exhausted testers you will
find, but exhaustive testing you will not. Complete Software Testing is neither theoretically, nor practically
possible.
Consider a 10 character string that has 280 possible input streams and corresponding outputs. If you
executed one test per microsecond it would take approx. 4 times the age of the Universe to test this
completely.

1.7 Software Testing and risk:

How much testing would you be willing to perform if the risk of failure were negligible? Alternatively, how
much Software Testing would you be willing to perform if a single defect could cost you your life's
savings, or, even more significantly

1.8 Software Testing and quality:

Software Testing identifies faults whose removal increases the software quality by increasing the
software's potential reliability. Software Testing is the measurement of software quality. We measure how
closely we have achieved quality by testing the relevant factors such as correctness, Reliability,
usability, maintainability, reusability, testability etc.

1.9 When to start testing?

Software Testing can be performed in either the two types:-
1.Conventional-In this Software Testing is started after the Coding.
Testing is not done at an early stage. In this type cost of testing is very huge because if the defect is
found in requirement itself, the entire process has to be done again. It is time consuming too.

2. Unconventional-In this Software Testing is done from the Initial Phase.

Testing is done in different forms at every phase of SDLC starting from requirement gathering till the
deployment of the software.
It is less time consuming and cost effective as the defect is corrected at that level itself.
Testing process/rules differs for the following terminology in the company:

PROJECT in which exact rules must be followed that is customer requirements

PRODUCT which are based on general requirements that is on our own requirements

2.0 How much Software Testing is enough?

It is difficult to determine how much Software Testing is enough. Software Testing is always a matter of
judging risks against cost of extra testing effort. Planning test effort thoroughly before you begin, and
setting completion criteria will go some way towards ensuring the right amount of Software Testing is
attempted. Assigning priorities to tests will ensure that the most important tests have been done should
you run out of time.
Finally it is when the project manager is confident enough to ensure that the software is mature enough to
deliver to the client, the testing is stopped.

2.1 Categories of testing

Testing can be categorized in two types
1. Manual Testing
2. Automation Testing

1. Manual Testing
In this type of testing, test cases are executed manually. Manual testers should know following testing
knowledge

• Testing concepts:
A. SDLC (Software Development Life Cycle)
B. STLC (Software Testing Life Cycle)
C. DLC (Defect Life Cycle)
D. Different types of SDLC models

• Any test management tool like

A. QC (Quality Center)
B. TD (Test Directory)
C. TL (Test Link)

• Defect Management tools like

A. JIRA
B. Bugzilla
C. Heat Call

• Basic Database concepts

• Writing of test cases which will cover expected and unexpected behavior of the application
• Test Case execution
• Defect Logging
• Preparation of test report.

Advantages of Manual Testing

- Manual testing requires when GUI is constantly changing
- It requires less time and expense to start productive manual testing
- Human intuition, inference, and inductive reasoning cannot be replaced by automation testing.

Disadvantages of manual testing

- It is very time consuming
- Repetitive test case execution is quite boring and hence prone to skip defects.
- GUI object, color changes cannot be observed manually.
- Load testing, performance testing cannot be done manually.
- Multiplatform, Multi browser, multi lingual testingbecomes too difficult is performed manually.

2. Automation Testing
Automation testing is performed to remove manual intervention. This is performed by using automation
testing tool.

Automation tester should know the following automation testing knowledge

• Automation tester have the knowledge of automation tools available in the market like QTP,
Selenium, Win Runner, Rational Robot, Skill Test etc.
• Scripting language for the selected automation tool.
• Scripting as per the designed test cases
• Execution of the scripts
• Logging defects as per the result.
• Preparation of test report.

Advantages of Automation Testing

- It is very time efficient - Regression testing can be performed effortlessly even unattended
- Very less chance of skipping any defect, hence reliable
- Multiplatform, Multi browser, multi lingual testing can be performed smoothly
- Small change in GUI can be identified easily.
- Load testing, performance testing can be done using automation testing.
- Reusable as same set of script can be used again and again
- Ensures the better quality of the software

Disadvantages of automation testing

- Automation testing cannot be used when application is not constant.
- Though it is very time efficient, scripting phase is very time consuming
- Proficiency is required while writing test script.
- Script maintenance is a difficult in case of big projects
Chapter 2

Software Development life cycle and Software Quality

2.1 Software Development life cycle (SDLC)

Software life cycle models describe phases of the software cycle and the order in which those phases are
executed. Each phase produces deliverables required by the next phase in the life cycle. Requirements
are translated into design. Code is produced according to the design which is called development phase.
After coding and development the testing verifies the deliverable of the implementation phase against
requirements.

There are multiple phases in SDLC:

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

• Business Analyst will fix the appointment from the customer in order to get the
requirements from the client.
• He will gather the requirements from the customer using the organization template.
• Once the understanding on the requirements are clear he will prepare a document called
“Functional Required Specifications(FRS)”

FRS is called with different names in different companies.

1. FRS (Functional Requirements Specification)

2. CRS (Customer/client Requirement Specification)

3. URS (User Requirement Specification)

4. BDD (Business Design Document)

5. BD (Business Document)

6. BRS (Business Requirement Specification)

The Outcome of the Requirements Phase is FRS Document.

II. Analysis Phase:

FRS is given as input of this phase.

(a) Tasks:

1. Feasibilty Study

2. Tentative planning

3. Technology Selection

(b) Roles: System Analyst, Project Manager.

1. Feasibility Study: - It is detailed study of the requirements in order to check whether 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.
The System Analyst prepare a detailed document called “System Required Specification(SRS)” which
contains the required software & Hardware Information.

II. 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
Senior Programmer

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

The Senior Programmer will also draw some diagrams in order to divide the modules in to sub
modules.

The Senior Programmer will also develop the PSEUDO code in order to make developers
comfortable while developing the actual code.

The outcome of this phase is “Technical Design Document (TDD)” Along with the “Graphical User
Interface (GUI)

II. 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..,

Output of this phase is build/software.

4) Testing: After the code is developed it is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements phase. During this
phase all types of functional testing like unit testing, integration testing, system testing, acceptance testing
is done as well as nonfunctional testing is also done.

Output of this phase is Quality Software.

5) Deployment: After successful testing the product is delivered / deployed to the customer for their use.
As soon as the product is given to the customers they will first do the beta testing. If any changes are
required or if any bugs are caught, then they will report it to the engineering team. Once those changes
are made or the bugs are fixed then the final deployment will happen.

6) Maintenance: Once when the customers starts using the developed system then the actual problems
comes up and needs to be solved from time to time. This process where the care is taken for the
developed product is known as maintenance.

2.2 Software Quality overview

Software quality is meeting customer requirements for first time and each & every time.

The factors that should meet are-

- Meeting customer requirements (Functional Requirements)

- Meeting Customer expectations
- Cost
- Time

Testing-Validating the final product with respect to customer’s requirement in order to identify defects and
to provide quality product to the end user/ customer is called software testing.

Bidding the project:

This is defined as request/proposal estimation & signing off. This is carried out by marketing manager.

Kick Off meeting:

This is an initial meeting conducted in a software company soon after the project is signed out. In order to
discuss the overview of the project, like to select the project manager. Usually Program managers, tech
managers, HR managers are involved.

PROJECT INITIATION NOTE (PIN):

It is just a mail prepared by the project manager and send it to the CEO of the company in order to create
Project ID and Project account.
Chapter 3

Static Techniques
Static test techniques provide a great way to improve the quality and productivity of software
development. It includes the reviews and provides the overview of how they are conducted. The primary
objective of static testing is to improve the quality of software products by assisting engineers to
recognize and fix their own defects early in the software development process.

• Static testing is the testing of the software work products manually, or with a set of tools, but they
are not executed.
• It starts early in the Life cycle and so it is done during the verification process.
• It does not need computer as the testing of program is done without executing the
program. For example: reviewing, walk through, inspection, etc.
• Most static testing techniques can be used to ‘test’ any form of document including source code,
design documents and models, functional specifications and requirement specifications.
• Since static testing can start early in the life cycle so early feedback on quality issues can be
established.
• As the defects are getting detected at an early stage so the rework cost most often relatively low.
• Development productivity is likely to increase because of the less rework effort.
• Types of the defects that are easier to find during the static testing are: deviation from
standards, missing requirements, design defects, non-maintainable code and inconsistent
interface specifications.
• Static tests contribute to the increased awareness of quality issues.

Under Static technques we see the follwing

• Reviews and the test process

• Review Process
• Review types

Reviews and the test process:

Reviews in Analysis – In general software development process starts with requirement gathering and
analysis. In this phase B.A. team gathers reuirements from customer and preparing BRS (Business
Requirement Specification ) document and SRS (System Requirement Specification) document.

BRS defins the requirements of the customer in business terminalogy.

SRS defines the functional requirements to be developed & system requirements to be used. SRS
cointains screenshots and the explaination of the functionality. BRS & SRS are reviewed by B.A.s or
sometimes by client.
Reviews in Design – After complition of BRS & FRS with their modification, the designer category people
develops HLD and LLD.

HLD: defines the overall architecture of the complete system. (External view of the software)

This HLD and LLD contains flow charts, algorithms, Dataflow diagrams, Entity Relationship diagrams.
Developers will write the code based on flow charts, algorithms etc.

Benefits of Reviews

•Early defect detection and correction,

•Development productivity improvements,

•Reduced development timescales

•Reduced testing cost and time,

•Lifetime cost reductions,

•Fewer defects at later stage and improvedcommunication

Review Process:
A typical formal review has the following main phases:

•Planning:selecting the personnel, allocating roles; defining the entry and exit criteria for more formal
review types (e.g.inspection); and selecting which parts of documents to look at.

•Kick-off:distributing documents; explaining the objectives,process and documents to the participants; and
checking entry criteria (for more formal review types).
•Individual preparation: work done by each of the participantson their own before the review meeting,
noting potentialdefects, questions and comments.

•Review meeting: discussion or logging, with documented results or minutes (for more formal review
types). The meeting participants may simply note defects, make recommendations for handling the
defects, or make decisions about the defects.

•Rework:fixing defects found, typically done by the author.

•Follow-up: checking that defects have been addressed,gathering metrics and checking on exit criteria
(for more formalreview types).

A typical formal review will include the roles below:

•Manager: decides on the execution of reviews, allocates time in project schedules and determines if the
review objectives have been met.

•Moderator: the person who leads the review of the document or set of documents, including planning the
review, running the meeting, and follow-up after the meeting. If necessary,the moderator may mediate
between the various points of view and is often the person upon whom the success of the review rests

•Author: the writer or person with chief responsibility for thedocument(s) to be reviewed.

•Reviewers: individuals with a specific technical or businessbackground (also called checkers or

inspectors) who, after thenecessary preparation, identify and describe findings (e.g.defects) in the product
under review. Reviewers should be chosen to represent different perspectives and roles in the review
process and they take part in any review meetings.

•Scribe (or recorder): documents all the issues, problems and open points that were identified during the
meeting.

Review Types:
1. Walk Through
2. Inspection
3. Peer Review

In these types of reviews, B.A.s reviews BRS and SRS interms of following factors

- Are they complete requirements

- Are they correct requirements
- Are the achievable requirements
- Are they reasonable requirements
- Are they testable requirements
Chapter 4

Types of testing
The following are the types of software testing generally seen in any of the SDLC models.

1. Unit Testing
A. Basis Path Coverage
B. Control Structure Coverage
C. Program Technique Coverage
D. Mutation Coverage
2. Integration Testing

1. Unit Testing:
Unit testing is prepared by the developers who has prepared the modules. After completion of design,
developers are writing the code based on the HLD and LLD.After writing the code each program is
verified by using ‘White Box Testing’. These techniques are also known as ‘Glass box testing’, ‘Open Box
Testing’ or ‘Clear box testing’.

White box testing techniques are:

A.Basis Path Coverage:In this coverage, the programmer will verify the continuation in execution. The
programmer is calculation all execution ways. In that program to estimate continuing in execution without
runtime error. [Just checking the thinks like “.” And executing the code without errors] Somethis is
executing or not without errors is cyclomatic complexity.Here no need of output is required.

B.Control Structure Coverage:

In this type of coverage the developers are concentrating on corectness of the program in terms of input
and output.

Ex. if a>b

(Perform some action)

Else

(Perform some action)

Debugging – a=6 & b=5, first box should be executed. If the first box is executed then the test is verified,
if the second box is executed then the test is not verified.

C.Program technique Coverage:

With the help of Monitors and Profiles software executation time of .Net & Java is calculated.If the
executation time is not acceptable then the programmers performs changes in the programming
techniques without disturbing the functionality.
D.Mutation Coverage:

Mutation means the known change in the program. The programmers performs changes in already tested
programs and repeat the previous test on the program to identify the change.

If the program is successful in identifying the change then the previously applied tests are complete,
otherwise the previously applied tests are incomplete.

Ex. if (i == 10) Break; (If value of i is 10 then if condition is executed )If == operator is replaced by >
operator then the condition should be executed. Even after replacing with > the test is executiong then the
provious test is wrong.If the test is not executiong after replacing == with > operator then the previous test
is correct.

2. Integration Testing:
It also called as interface testing. After completing individual modules developers are going to integrate all
the modules to form the software build and verifies the program interconnection to estimate completeness
and correctness. Module integration happens at front end integration and database integration, hence
called as Dev integration.

Eg. If the program is in dev integration, there are four approaches in integration of program.

A. Top- Down Approach:

In this approach testing is conducted from main module to sub module. If the sub module is not
developed a temporary program called STUB is used for simulate the submodule.

In this type of testing programmers are interconnecting main module and some of other modules.
Programmers’ uses temp program instead of ‘Under Constructive main module’, those temp programs are
called as ‘STUBS’ or ‘Called Programs’

Advantages:
- Advantageous if major flaws occur toward the top of the program.
- Once the I/O functions are added, representation of test cases is easier.
- Early skeletal Program allows demonstrations and boosts morale.

Disadvantages:
- Stub modules must be produced
- Stub Modules are often more complicated than they first appear to be.
- Before the I/O functions are added, representation of test cases in stubs can be difficult.
- Test conditions may be impossible, or very difficult, to create.
- Observation of test output is more difficult.
- Allows one to think that design and testing can be overlapped.
- Induces one to defer completion of the testing of certain modules.

B. Bottom- Up Approach(Driver or calling program) :

In this approach testing is conducted from sub module to main module, if the main module is not
developed a temporary program called DRIVERS is used to simulate the main module.

In this type of testing, the programmers are interconnecting unit level tested modules without using ‘Under
constructive main module’. They uses temp program instead of ‘Under Constructive main Module’. This
temp program is called as ‘DRIVER’ or ‘Calling Program’.

Though Top level components are the most important, yet tested last using this strategy.

Advantages:
1. Advantageous if major flaws occur toward the bottom of the program.
2. Test conditions are easier to create.
3. Observation of test results is easier.

Disadvantages:
1. Driver Modules must be produced.
2. The program as an entity does not exist until the last module is added.

C.Hybrid Approach:

It is combined approach of top down and bottom up approach. It is also called as sandwich approach.
Advantages1. Rigorously test critical and complex software early (benefit of bottom
2. Minimizes development of test software by using high level drivers and previously tested system
software to perform test (advantage of top-down).
3. Testers can tailor their approach to concentrate on the items of high concern (high risk, etc.)
4. Supports rapid prototyping (concentrating on key functional areas).

Disadvantages 1.Require both stubs and drivers to be developed.

2. Can be more difficult to manage and track progress.
3. Requires greater discipline and control than just one pure approach, test team must be careful to keep
track of where they are in the process. They must know what they have drivers for, what stubs they have
and, what real modules are ready to be inserted.

D.Big Bang (System Approach):

In this approach programmers are concentrating on interconnection of modules after completing the total
coding of the programs. This approach is also known as Big Bang approach.

In this approach no temp modules are used.

Advantage of Big Bang Integration:1.Bigbang testing has the advantage that everything is finished
before integration testing starts.

Disadvantages of Big Bang Integration

1. The major disadvantage is that in general it is very time consuming

2.It is very difficult to trace the cause of failures because of this late integration.

3. The chances of having critical failures are more because of integrating all the components together at
same time.

4. If any bug is found then it is very difficult to detach all the modules in order to find out the root cause of
it.

5. There is high probability of occurrence of the critical bugs in the production environment
Chapter 5

Different Software testing models

There are different types of software testing models among them the following are listed below.

1. Waterfall model
2. V model
3. Incremental model
4. RAD model
5. Agile model
6. Iterative model
7. Spiral model
8. Prototype model

1. Waterfall Model
The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential
life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be
completed fully before the next phase can begin. This type of model is basically used for the project which
is small and there are no uncertain requirements. At the end of each phase, a review takes place to
determine if the project is on the right path and whether or not to continue or discard the project. In this
model the testing starts only after the development is complete. In waterfall model phasesdo not
overlap. Diagram of Waterfall-model:
Advantages of waterfall model:

• This model is simple and easy to understand and use.

• It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a
review process.
• In this model phases are processed and completed one at a time. Phases do not overlap.
• Waterfall model works well for smaller projects where requirements are very well understood.

Disadvantages of waterfall model:

• Once an application is in the testing stage, it is very difficult to go back and change something
that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use the waterfall model:

• This model is used only when the requirements are very well known, clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.

Very less customer enter action is involved during the development of the product. Once the product is
ready then only it can be demoed to the end users. Once the product is developed and if any failure
occurs then the cost of fixing such issues are very high, because we need to update everywhere from
document till the logic.

2. V- model means Verification and Validation model. 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 of the product is planned in parallel with a corresponding phase of development
in V-model.

The various phases of the V-model are as follows:

Requirements like BRS and SRS begin the life cycle model just like the waterfall model. But, in this
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 (HLD) phase focuses on system architecture and design. It provide overview of
solution, platform, system, product and service/process. An integration 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 (LLD) phase is where the actual software components are designed. It defines the
actual logic for each and every component of the system. Class diagram with all the methods and relation
between classes comes under LLD. Component 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.
Coding: This is at the bottom of the V-Shape model. Module design is converted into code by
developers.

Advantages of V-model:

• Simple and easy to use.

• Testing activities like planning, test designing happens well before coding. This saves a lot of
time. Hence higher chance of success over the waterfall model.
• Proactive defect tracking – that is defects are found at early stage.
• Avoids the downward flow of the defects.
• Works well for small projects where requirements are easily understood.

Disadvantages of V-model:

• Very rigid and least flexible.

• Software is developed during the implementation phase, so no early prototypes of the software
are produced.
• If any changes happen in midway, then the test documents along with requirement documents
has to be updated.

When to use the V-model:

• The V-shaped model should be used for small to medium sized projects where requirements are
clearly defined and fixed.
• The V-Shaped model should be chosen when ample technical resources are available with
needed technical expertise.

High confidence of customer is required for choosing the V-Shaped model approach. Since, no
prototypes are produced, there is a very high risk involved in meeting customer expectations.

3. In incremental model the whole requirement is divided into various builds. Multiple development
cycles take place here, making the life cycle a“multi-waterfall” cycle. Cycles are divided up into
smaller, more easily managed modules. Each module passes through the requirements, design,
implementation and testing phases. A working version of software is produced during the first module, so
you have working software early on during the software life cycle. Each subsequent release of the module
adds function to the previous release. The process continues till the complete system is achieved.

For example:

In the diagram above when we

work incrementally we are adding piece by piece but expect that each piece is fully finished. Thus keep
on adding the pieces until it’s complete. As in the image above a person has thought of the application.
Then he started building it and in the first iteration the first module of the application or product is totally
ready and can be demoed to the customers. Likewise in the second iteration the other module is ready
and integrated with the first module. Similarly, in the third iteration the whole product is ready and
integrated. Hence, the product got ready step by step.

Diagram of Incremental model:

Advantages of Incremental model:

 • Generates working software quickly and early during the software life cycle.
• This model is more flexible – less costly to change scope and requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified and handled during it’d iteration.

Disadvantages of Incremental model:

• Needs good planning and design.

• Needs a clear and complete definition of the whole system before it can be broken down and built
incrementally.
• Total cost is higher than waterfall.

When to use the Incremental model:

• This model can be used when the requirements of the complete system are clearly defined and
understood.
• Major requirements must be defined; however, some details can evolve with time.
• There is a need to get a product to the market early.
• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.

4. RAD model RAD model is Rapid Application Development model. It is a type of incremental model.
In RAD model the components or functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working prototype. This can quickly
give the customer something to see and use and to provide feedback regarding the delivery and their
requirements.

Diagram of RAD-Model:
The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that are
needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and created for
CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and the actual
system.
Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

 • Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

• Depends on strong team and individual performances for identifying business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.

When to use RAD model:

• RAD should be used when there is a need to create a system that can be modularized in 2-3
months of time.
• It should be used if there’s high availability of designers for modeling and the budget is high
enough to afford their cost along with the cost of automated code generating tools.
• RAD SDLC model should be chosen only if resources with high business knowledge are available
and there is a need to produce the system in a short span of time (2-3 months).

4. Agile development model

This is also a type of Incremental model. Software is developed in incremental, rapid cycles. This
results in small incremental releases with each release building on previous functionality. Each
release is thoroughly tested to ensuresoftware quality is maintained. It is used for time critical
applications. Scrum is currently one of the most well-known agile development life cycle model.
Diagram of Agile model:

Advantages of Agile model:

• Customer satisfaction by rapid, continuous delivery of useful software.

• People and interactions are emphasized rather than process and tools. Customers, developers
and testers constantly interact with each other.
• Working software is delivered frequently (weeks rather than months).
• Face-to-face conversation is the best form of communication.
• Close daily cooperation between business people and developers.
• Continuous attention to technical excellence and good design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed.

Disadvantages of Agile model:

• In case of some software deliverables, especially the large ones, it is difficult to assess the effort
required at the beginning of the software development life cycle.
• There is lack of emphasis on necessary designing and documentation.
• The project can easily get taken off track if the customer representative is not clear what final
outcome that they want.
• Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined with
experienced resources.
When to use agile model:

• When new changes are needed to be implemented. The freedom agile gives to change is very
important. New changes can be implemented at very little cost because of the frequency of new
increments that are produced.
• To implement a new feature the developers need to lose only the work of a few days, or even
only hours, to roll back and implement it.
• Unlike the waterfall model in agile model very limited planning is required to get started with the
project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT
world. Changes can be discussed and features can be newly effected or removed based on
feedback. This effectively gives the customer the finished system they want or need.
• Both system developers and stakeholders alike, find they also get more freedom of time and
options than if the software was developed in a more rigid sequential way. Having options gives
them the ability to leave important decisions until more or better data or even entire hosting
programs are available; meaning the project can continue to move forward without fear of
reaching a sudden standstill.

1. An iterative life cycle model

This model does not attempt to start with a full specification of requirements. Instead,
development begins by specifying and implementing just part of the software, which can then be
reviewed in order to identify further requirements. This process is then repeated, producing a new
version of the software for each cycle of the model.

For example:

In the diagram above when we work iteratively we create rough product or product piece in one iteration,
then review it and improve it in next iteration and so on until it’s finished. As shown in the image above, in
the first iteration the whole painting is sketched roughly, then in the second iteration colors are filled and
in the third iteration finishing is done. Hence, in iterative model the whole product is developed step by
step.

Diagram of Iterative model:

Advantages of Iterative model:

• In iterative model we can only create a high-level design of the application before we actually
begin to build the product and define the design solution for the entire product. Later on we can
design and built a skeleton version of that, and then evolved the design based on what had been
built.
• In iterative model we are building and improving the product step by step. Hence we can track the
defects at early stages. This avoids the downward flow of the defects.
• In iterative model we can get the reliable user feedback. When presenting sketches and
blueprints of the product to users for their feedback, we are effectively asking them to imagine
how the product will work.
• In iterative model less time is spent on documenting and more time is given for designing.

Disadvantages of Iterative model:

• Each phase of an iteration is rigid with no overlaps

• Costly system architecture or design issues may arise because not all requirements are gathered
up front for the entire lifecycle

When to use iterative model:

• Requirements of the complete system are clearly defined and understood.

 • When the project is big.
• Major requirements must be defined; however, some details can evolve with time.

7. The spiral model this model is similar to the incremental model, with more emphasis 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.

Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ that is
‘Business Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’.

Risk Analysis: 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. If any risk is found during the risk
analysis then alternate solutions are suggested and implemented.

Engineering Phase: In this phase software is developed, along with testing at the end of the phase.
Hence in this phase the development and testing is done.

Evaluation phase: This phase allows the customer to evaluate the output of the project to date before
the project continues to the next spiral.

Diagram of Spiral model:

Advantages of Spiral model:

• High amount of risk analysis hence, avoidance of Risk is enhanced.

• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

Disadvantages of Spiral model:

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

When to use Spiral model:

• When costs and risk evaluation is important

• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to economic priorities
• Users are unsure of their needs
 • Requirements are complex
• New product line
• Significant changes are expected (research and exploration)

The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a
throwaway prototype is built to understand the requirements. This prototype is developed based on the
currently known requirements. By using this prototype, the client can get an “actual feel” of the system,
since the interactions with prototype can enable the client to better understand the requirements of the
desired system. Prototyping is an attractive idea for complicated and large systems for which there is no
manual process or existing system to help determining the requirements.

8. The prototypethe prototype are usually not complete systems and many of the details are not built
in the prototype. The goal is to provide a system with overall functionality.

Diagram of Prototype model:

Advantages of Prototype model:

• Users are actively involved in the development

• Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
 • Confusing or difficult functions can be identified
Requirements validation, Quick implementation of, incomplete, but
functional, application.

Disadvantages of Prototype model:

• Leads to implementing and then repairing way of building systems.

• Practically, this methodology may increase the complexity of the system as scope of the system
may expand beyond original plans.
• Incomplete application may cause application not to be used as the
full system was designed
Incomplete or inadequate problem analysis.

When to use Prototype model:

• Prototype model should be used when the desired system needs to have a lot of interaction with
the end users.
• Typically, online systems, web interfaces have a very high amount of interaction with end users,
are best suited for Prototype model. It might take a while for a system to be built that allows ease
of use and needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system and provide a feedback
which is incorporated in the prototype to result in a useable system. They are excellent for
designing good human computer interface systems.

Chapter 6
 Test Data Preparation techniques

Black-box testing is a method of software testing that examines the functionality of an application based
on the specifications. It is also known as Specifications based testing. Independent Testing Team usually
performs this type of testing during the software testing life cycle.

This method of test can be applied to each and every level of software testing such as unit, integration,
system and acceptance testing.

Black box testing techniques

1. Boundary value analysis2. Equivalence Class Partition

3. Decision Table
4. State Transition

1. Boundary value analysis

More application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing
technique is used to identify errors at boundaries rather than finding those exist in center of input domain.

Test cases for input box accepting User Id between 6 and 24 using Boundary value analysis:

1) Test cases with test data exactly as the input boundaries of input domain i.e. values 6 and 24 in our
case.
2) Test data with values just below the extreme edges of input domains i.e. values 5 and 23.
3) Test data with values just above the extreme edges of input domain i.e. values7 and 25.
Boundary value analysis is often called as a part of stress and negative testing.

2. Equivalence Class Partition

In this method the input domain data is divided into different equivalence data classes. This method is
typically used to reduce the total number of testcases to a finite set of testable test cases, still covering
maximum requirements.
In short it is the process of taking all possible test cases and placing them into classes. One test value is
picked from each class while testing.

Test cases for input box accepting User Id between 6 and 24 using Equivalence Partitioning:
1) One input data class with all valid inputs. Pick a single value from range 6 to 24 as a valid test case. If
you select other values between 6and 24 then result is going to be same. So one test case for valid input
data should be sufficient.2) Input data class with letters A-Z or a-z to represent a valid test case.
3) Input data class with all values below lower limit. I.e. any value below 6, as an invalid input data test
case. 4) Input data with any value greater than 24 to represent third invalid
input class.5) Input data with any special character to represent fourth invalid input class.

3. Decision Table

A decision table is a good way to deal with different combination inputs with their associated outputs and
also called cause-effect table. Reason to call cause-effect table is an associated logical diagramming
technique called cause-effect graphing that is basically use to derive the decision table.

Decision table testing is black box test design technique to determine the test scenarios for complex
business logic.

We can apply Equivalence Partitioning and Boundary Value Analysis techniques to only specific
conditions or inputs. Although, if we have dissimilar inputs that result in different actions being taken or
secondly we have a business rule to test that there are different combination of inputs which result in
different actions. We use decision table to test these kinds of rules or logic.

Why Decision table is important?

Decision tables are very much helpful in test design technique – it helps testers to search the effects of
combinations of different inputs and other software states that must correctly implement business rules.
Also, provides a regular way of stating complex business rules, that’s helpful for developers as well as for
testers. Testing combinations can be a challenge, as the number of combinations can often be huge. It
assists in development process with developer to do a better job. Testing with all combination might be
unrealistic or unfeasible. We have to be happy with testing just a small subset of combinations but making
the option of which combinations to test and which to leave out is also significant. If you do not have a
efficient way of selecting combinations, an arbitrary subset will be used and this may well result in an
ineffective test effort.

A decision table is basically an outstanding technique used in both testing and requirements
management. It is a structured exercise to prepare requirements when dealing with complex business
rules.

Decision table with input combinations:

Rule1
TestCaseNo Rule2(Password) Criteria
(UId)
1 Y Y Enter to display welcome page
2 Y X Error message is displayed
3 X Y Error message is displayed
 4 X X Error message is displayed

4. State Transition

State Transition testing, a black box testing technique, in which outputs are triggered by changes to the
input conditions or changes to 'state' of the system. In other words, tests are designed to execute valid
and invalid state transitions.

This is a is a dynamic testing technique, which is used when the system is defined in terms of a finite
number of states and the transitions between the states is governed by the rules of the system.
Or in other words, this technique is used when features of a system are represented as states which
transforms to other state. The transformations are determined by the rules of the software. The pictorial
representation can be shown as:

So here we see that an entity transitions from State 1 to State 2 because of some input condition, which
leads to an event and results to an action and finally gives the output.

When to use?

• When we have sequence of events that occur and associated conditions that apply to those
events

• When the proper handling of a particular event depends on the events and conditions that have
occurred in the past

• It is used for real time systems with various states and transitions involved
Deriving Test cases:

• Understand the various state and transition and mark each valid and invalid state

• Defining a sequence of an event that leads to an allowed test ending state

• Each one of those visited state and traversed transition should be noted down

• Steps 2 and 3 should be repeated until all states have been visited and all transitions traversed

• For test cases to have a good coverage, actual input values and the actual output values have to
be generated

To explain it with an example:

You visit an ATM and withdraw $1000. You get your cash. Now you run out of balance and make exactly
the same request of withdrawing $1000. This time ATM refuses to give you the money because of
insufficient balance. So here the transition, which caused the change in state is the earlier withdrawal

Chapter 7

Testing Department
Testing department receives the build only after the integration testing tasted by developers. Testing
department starts with the system testing. Following are the different types of system testing:

System Testing
1.Usability Testing

A. User Interface (UI) testing

 B. Manual Support Testing

2. Functional Testing

A. Behavioral Coverage

B. Error handling Coverage

C. I/P domain coverage

D. Calculations Coverage

E. Functionality Order Coverage

F. Back End Coverage

3. Non Functional Testing

A. Reliability Testing

B. Compatibility Testing

C. Configuration Testing

D. Intersystem Testing

E. Security Testing

F. Installation Testing

G. Performance Testing

1. Usability Testing

In general, the system test execution process is starting with Usability testing.Usability testing provides
the opportunity to evaluate a product by studying how real users actually use the product. This analysis
ensures that key assumptions about intended users and interface designs are supported (or challenged)
with real data. Only by gathering this empirical data can you find out how well the UI for a product fits your
users' needs and expectations.

It consists of two sub sets-

• User Interface Testing: UI testing is the process of ensuring proper functionality of the
user interface (UI) for a given application and making sure it conforms to its written
specifications. UI testing checklist is

o Check Screen Validations

 o Verify All Navigations

o Check usability Conditions

o Verify Data Integrity

o Verify the object states

o Verify the date Field and Numeric Field Formats

o Look and feel of the screen (Attractiveness of the screen)

o Speed in interface (Short navigation of the screen, quick results)

o Ease of use (understandable of screen)

• Manual Support Testing: During this test, testing team verifies the correctness and
completeness of user manuals.

E.g. We buy a mobile, we get a user manual with it, testing the correctness and completeness of
that manual is a manual support system

2. Functional System

It is a mandatory testing level in system testing. During this test, testing team is concentrating on
customer’s requirements in terms of functionality which are available in F.R.S.

During this test, testing team is validating the correctness of every functionality through the below
coverage –

• Behavioral coverage/ GUI coverage – In this coverage, testing team observes the behavior of
objects in screens of product with respect to corresponding functionality and validate changes in
properties values of objects, which are involving in testing functionality of product.

• Error Handling Coverage – In this coverage, testing team observes the behavior of objects with
respect to invalid events. For example, if a user operates object or control wrongly, then our
product retunes a meaningful error message to indicate wrong event on that object.

• I/O Domain Coverage – Testing team goes to special treatment to input domain testing in terms
of boundary value analysis (BVA) and equivalence class partition (ECP). BVA concentrates on
range or size of the input object and ECP concentrates on the type of the input object.
 • Calculation Coverage/Manipulations Coverage – In this coverage, testing team validates
output or outcome of that corresponding functionality at the end. For example, a login operation
in web site returns inbox of that user at the end of login operation with valid input data.

• Functionality Order/Service level Coverage –In this coverage, testing team validates the place
of testing functionality in that product. For example, before login to a website, new user
registration option occurs.

• Back End Coverage –In this coverage, testing team validates the impact of front end
functionality on the backend database tables in terms of data validation and data integrity.

3. Non Functional Testing -

To verify more quality testing team is conducting nonfunctional testing. Non-Functional testing is a
software testing technique that verifies the attributes of the system such as memory leaks, performance
or robustness of the system. In non-functional testing the quality characteristics of the component or
system is tested. Non-functional refers to aspects of the software that may not be related to a specific
function or user action such as scalability or security. E.g. how many people can log in at once? Non-
functional testing is also performed at all levels like functional testing.

Nonfunctional testing consists of –

• Reliability Coverage/Recovery Testing – During this test, testing team is validating whether
application build is navigating abnormal to normal stage. For example, Firefox gets hanged
(abnormal) and becomes normal with 5 to 15 seconds

• Compatibility testing/ Portability/Cross Browser/ Cross O.S. testing Coverage –For most of
the web applications compatibility testing is applicable. During this test, testing team is validation
whether the application build is running on customer expected platform like different
browsers/OS, different devices.

• Configuration testing/Hardware compatibility testing - During this test, testing team is

validating whether application build is co-existing with different hardware devices or not. For
example, different printers or scanners.

• Inter System/Inter-operability test/End to end test - During this test, testing team is
validating whether application build is co-existing with different software also. For example cash
can be withdrawn using a SBI ATM card or an ICICI ATM card from a HDCF ATM.
 • Installation testing – During this test, testing team is validating whether we can install software
without any complexity. This installation will be done from customer’s point of view.

• Security/ penetration testing - During this test, testing team is concentrating on security
aspects like –

1. Authorization

2. Access Control

3. Cookie testing

4. Url testing/ direct url testing

5. Encryption/ Decryption testing

• Performance testing – During this test, testers are validating the performance of the application
like load or stress

1. Load Testing/Scalability testing – Load or scale means the number of

concurrent users work with the application.

2. Stress testing/Endeavors testing – During this test,test engineerare running

out application build under customer expected configurations and various load
levels to estimate continuity.

Stress and performance testing cannot be performed manually. This can be

tested using tool like load runner or Silk etc. by Performance test engineer.

• Localization testing – Testing the application in different language is called as localization

testing.

User Acceptance Testing (UAT)

User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual
software users test the software to make sure it can handle required tasks in real-world scenarios,
according to specifications.

UAT is one of the final and critical software project procedures that must occur before newly developed
software is rolled out to the market.

There are two type of UAT –

 1. Alpha testing – This type of testing is suitable for projects. This is conducted at
development site. Testers and developers are involved in this testing. This testing is
conducted by real customers.
2. Beta testing – This type of testing is suitable for products. This is conducted at
customer’s site. Only customer is involved in this testing. This testing is conducted by
model customers.

Software Release

After the completion of UAT & modifications, the project management defines a release team. This team
consists of two developers, two testers and few hardware engineers. This release team go to customer’s
site and conduct port testing. Port testing consists of –

o Compact installation
o Overall functionality run
o I/P device handling
o O/P device handling
o Secondary storage device handling
o Co-existence with O.S.
o Co-existence with other software.

After completion of port testing the release team provides training sessions to the customers/end users.

Software Maintenance

During installation of software, customer site people are sending change request (CRs) or program
change request (PCR). There are two kinds of CRs

1. Missed defect
2. Enhancement

CCB (Change control board) handles the CRs. This board consists of project manager, few developers
and few testers.

Software Test Life Cycle

Test Initiation – Management level document/ Test strategy document (TSD) is prepared at this stage by
project manager.

Test Planning- Operational level document/ test plan document (TPD) is prepared at this stage by test
lead / project lead.

Test Design – Preparation of Test Scenarios, Test cases, RTM (Requirement Traceability Matrix), test
reviews are don’t at this stage by test engineer.

Test Execution – Execution of test cases/test scripts is don’t at this stage by test engineer.

Test Reporting – Generating reports from the executed test cases is done at this stage by test engineer.

Test Closure –Final test summary report is generated.

Chapter 8

Test Plan and Test plan template

Test Plan

A Software Test Plan is a document describing the testing scope and activities. It is the basis for
formally testing any software/product in a project. After the completion of testing team formation and risk
analysis, the test lead will prepare the Test Plan Document [TPD] in [IEE 829 Format]
It contains –

• What are the requirements to be tested [what to be tested]

• How to test the requirement
• Who to test the requirement
• When to test the requirement

Input for the test plan is –

• FRS (Functional Requirement Specification)

• MPP (Master Project Plan)
• Test Strategy Document

Following is the process for test planning –

• Testing team formation

• Identify the risk
• Test plan preparation

Output of this project is –

• Test Plan

Testing Team Formation

Test planning starts with testing team formation. Test lead forms the team based on following factors –

• Project size (No. of functional requirement/ No. of requirement)

• Test duration
• Availability of resources

Identifying the Risk

After test team formation, test lead concentrates on identifying the risk involved. Following are the risks
typically identified in testing.

• Lack of domain knowledge of selected test engineer

• Lack of time
• Lack of resources
• Delay in build delivery by developer team
• Lack of communication
• Lack of development scenarios.

Test Plan Template

1. Test Plan ID
2. Introduction
 3. Item in scope
4. Items not in scope
5. Approach (Test Strategy)
6. Test Environment
7. Entry Criteria
8. Suspension Criteria
9. Exit Criteria
10. Test Deliverables
11. Schedules
12. Staff and training needs
13. Responsibilities
14. Risks & assumptions
15. Approvals

1. Test Plan ID: -Unique name or ID for further reference.

2. Introduction: - Description about project requirement.

3. Items in scope: -Consists of features to be tested and names of the modules to be tested.

4. Items not in scope: - Consists of features not to be tested and names of already tested modules or
out of scope modules list.

5. Approach [Test Strategy]:- Includes the list of reasonable tests –

• Test Case Design

• Test Execution
• Test Result
• Test Data
• Defect Management
• Test Reporting
• Daily Reporting, etc.

6. Test Environment: -Required hardware and software for testing including testing tools.

7. Entry Criteria:-The list of comments to start test execution the test engineer.

- Study requirement/ functionality

- Test Case Preparation
- Establish test environment
- Receive build from developer

8. Suspension Criteria (Temp stop):- If any defects are found which seriously impact the test
progress the test lead may choose to suspend testing.The criteria which are considered for suspension
or resumption are:

- Test environment abundant

- Pending defects are more
- Returns build because of show stopper
9. Exit Criteria:-

- The list of comments to stop the test execution

- All the requirements are tested
- Time exceeded.
- All major defects are resolved.

10. Test deliverables:-

- List out all the testing documents to be prepared by test engineer.

- Test scenarios
- Test cases
- Defect reports and summary reports.

11. Schedules:-

- Provide a summary of the schedule (date and time), specifying key test milestones, and/or

provide a link to the detailed schedule.

12. Staff and training needs:-

- Provide the number of selected test engineer and required number of training sessions to them.

13. Responsibilities:-

- Work allocation to above mentioned resources as per the requirement and the technology.

14. Risks and assumptions:-

- Provide previously analysed risk & solutions to overcome.

15. Approvals:-

- Signature of test leads, project managers and other stake holders.

[Who ever involved in this project are called stake holders]

Review test plan: - After

the test plan preparation, the test lead will review the test plan for its completeness and correctness. In

this review, test lead will concentrate on

- Requirement oriented coverage

- Testing techniques coverage

- Risks oriented techniques

Training Sessions: -

- It is a team level training to understand customer requirement in corresponding project.

- In this training the B.A.s and the SMEs [Subject Matter/Domain Expert] are sharing their

knowledge with test engineer.

Chapter 9

Test Management

Test management, process of managing the tests. Plan testing activities and test scheduling, the logging
of results, test tracking, incident management and report the status of quality assurance activities,
generate of the requirement test matrix (RTM), which is an indication of functional coverage of the
application under test (SUT).

Test Management Responsibilities

• Test Management has a clear set of roles and responsibilities for improving the quality of the
product.

• Test management helps the development and maintenance of product metrics during the course
of project.

• Test management enables developers to make sure that there are fewer design or coding faults.

Test Management Process-

1. Functional Understanding Document

- After completion of successful training, test engineers will prepare functional understanding
document.
- Test engineers will note down all the understanding in this release document and share it
with project manager/test lead and B.A.s

2. Test Scenarios & test case preparation

- After completion of test planning and training sessions, test engineers will be concentrating
on test scenarios and test case preparation.
- Every test scenario defines a unique test condition.
- This condition is implementing with required procedure called ‘test case’.
- Every test case contains a series of steps which explains some functionality.

Three methods to prepare test case and scenarios -

A. Functionality specification based test case design

B. Use case test case design
C. Application interface test case design

A. Functionality specification based test case design

In general, most of the test engineer are preparing test cases and scenarios depending on
functional system description available in FRS. Using FRS test engineers prepares high level test
scenarios and implement that scenarios as in depth test cases.
 Step1:- Select respective modules FRS documents and dependencies.
Step2:- Select FRS in terms of entry point, required input, normal flow, desired output, alternative
flow, exceptions & exit point.
Step3:- Prepare test scenarios and review them for completeness and correctness with the help
of test lead.
Step4:- Test cases for every scenario.
Step5:- Review them for completeness and correctness with the help of test lead.
Step6:-Follow the above procedure for all FRS documents.

B. Use case based test case design

In this method test engineers are taking less assumptions on test case design because the use
cases are more elaborative the functional requirement document. These use cases are
developed by B.A.s or Test lead.
Use case is designed with a standard format.

Use Case ID: - Unique number & ID.

Use Case Overview: - Necessary task to do before starting this functionality.
Events List: - Step by step procedure for corresponding functionality for required i/p and
expected o/p.
Business Rules: - List of rules, if available.
Post Condition: - Necessary task to do after stopping this functionality.
Flow Diagram: - Pictorial presentation of the functionality.
Prototype: - A model screen to indicate the corresponding functionality.
Alternative Events: - Alternative list of events for functionality, if available.
Referenced Use Case: - List of use cases related to the functionality.

C. Application Based/ U.I based test case design

In this method the test engineers are depending on UI dev standard / psychology level of end
user / model screens/ prototype of testing build to prepare usability test cases.
This cases are applicable on all types of applications, due to this reason the testing teams are
maintaining the common set of test cases for “Usability Testing”.

Common set of Usability Test cases:-

1. Verify spelling in every screen.

2. Verify initial capital letter.

3. Verify color contrast, alignment, Borders, Title font, title size, and tool tips, back round color,
help messages etc.

RTM (Requirement Traceability Matrix)

RTM is used to map the requirements with the written test cases. With the help of RTM, we can
understand How many test cases are written for each requirement.
In future, if customer raises a defect or if any defect leakage happens, RTM will be used for tracing
purpose. It helps to trace whether the related test is mentioned or not?

RTM is filled by test lead at release time. Sample RTM is as follow:

Reqd Id Test Id Test Case Remarks

Name
Pass Fail Block NA
TC-log- Verify User
001 Name Pass
Edo-log- TC-log- Verify
001 002 Password Pass
TC-log-
003 Verify Sign in Pass

Test Results or Test Logs: - After executing the test cases, the test logs or test results are to be sent to
test lead in below format:

Reqd Id Test Id Test Case Actual Status

Name Result Bug Id
TC-log- Verify User
001 Name As expected
TC-log-
Edo-log- 002 Verify Password As expected
001 TC-log-
003 Verify Sign in Fail Bug001
TC-log-
004 * Mark Fail Bug002

Test Case Review:-

- After writing the test cases, test engineer will be sending the test cases for review to TL.
- The test cases are peer reviewed and then reviewed by test lead.

Peer Review:-

- In this review, the test cases are reviewed by colleagues and the review comments are given
in the review report form.
- Based on the review comment, respective test case designer will update the test case.

Test Lead Review:-

- After peer review, test case will be sent to test lead for review.
 - Test lead will review the test cases at high level and note down the review comment in review
report.
- Again the respective test case designer will update the test case.

B.A/Client Review:-

- After TL/peer review, test cases will be sent to B.A. for review.
- They will review it and comment in the review report form.
- Based on the review comment, respective test case designer will update the test case.

Chapter 10

Test Execution
The process of step by step execution of the test cases for comparing expected results with actual result
is called test execution. After completion of test case design and review, project manager is concentrating
on the formal meeting between the representative of testing team and dev team.

Formal Meeting: - In this meeting, the project management and test management people are defining –

- Build Release
- Defect Reporting
- Build Version Control
- Test Coverage

Build Release and Version Control:-

From the above architecture, the organization scenario maintaining –

- Soft base with build

- Dev base with development document
- Test base with test documents

MS Outlook or lotus notes will be used for ‘mail purpose’. MS Lync or Same time or POD will be used for
instant messaging to co-ordinate within team members. Development team is maintain unique versions
number to distinguish output build or modified build by testing team.

For this build version control, version control tools like VSS, perforce, CVS are used.

Different levels of test execution:

After getting build from dev base, testing is done at following levels -

Level 0: Sanity and smoke testing.

• Sanity Testing – After receiving build for bug fixes, the testing is carried out to ensure that the
bugs have been fixed and no further issues are introduced because of these changes. This
testing process is called as sanity testing.
• Smoke Testing – The testing process in which critical functionality of the application is tested
before testing detailed functionality or regression test. If the critical functionality is working fine
then testers go further for regression test. If the critical functionality is not working fine then
testers can reject the badly broken application.

Level 1: Functional testing/ Regression testing

 • Regression Testing: Even if any small change is done in the application, the entire application is
tested to ensure that other functionality is working fine and not impacted due to this small
change.This testing is called as regression testing.

Level 2: Final stage testing.

Test Reporting and Defect reporting

While testing if test engineer finds any mismatches in expecting results, test engineer reports this
mismatch to dev team in the form of a defect. To raise a defect, defect tracking tools like JIRA, Bugzilla,
QC etc. are used.

Chapter 11

Defect template

Reporting a bug/defect properly is as important as finding a defect, if the defect found is not
logged/reported correctly and clearly in bug tracking tools (like Bugzilla, JIRA etc.) then it won’t be
addressed properly by the developers, so it is very important to fill as much information as possible in the
defect template so that it is very easy to understand the actual issue with the software.

Defect Template enables you to build the description in a way that fits the standard in your organization.

Defect template consists of following elements:-

1. Defect ID - Unique number created by tracking tool. No need to create it manually.

2. Summary – Brief description for the defect.

3. Steps to Reproduce - Navigation steps to reach the defect.

4. Expected Result – What we need/ expected with respect to the FRS.

5. Actual Result – What is currently available in the application?

6. Status – New/Assigned/Open/Deferred/In progress/Fixed/Closed.

7. Severity – Critical/High/Medium/Low

8. Priority – High/ Medium/Low

9. O.S. –The O.S. on which testing is in progress

10. Browser –The browser used for the testing.

11. Build No –This defect is found in this build version.

12. Reported By – Test Engineer Name/Id

13. Assigned to – Developer’s Name

14. Attachment – Required screenshots or document

15. Submit – Submit the defect after entering all the information.

Example: Raising a defect for * symbols

1. Defect Id: Bug 001 (It is created by the tool)

2. Summary: * symbol is not displayed for Username, Password fields.

3. Steps to reproduce: 1. Open IE – Enter test URL www.gmail.com– Press enter.
2. Check of username, password fields.
3. Check for mandatory (*) symbol for username and password fields.

4. Expected Result: Mandatory symbol (*) should be present for username and password fields.

5. Actual Result: Mandatory symbol not present for username and password fields.

6. Status: New (for first time posting)

7. Severity: Low (as no impact on the functionality)

8. Priority: Low

9. O.S.: XP

10. Browser: IE

11. Build No: 007

12. Reported By: Test Engineer Id/Name

13. Assigned To: Developer Lead

14. Attachment: Screenshot of the Gmail login screen

15. Submit.

Chapter 12

Defect life cycle

New defect is raised in the tracking system, if same type of defect is already existing then this defect is
marked as a duplicate of other defect(previous defect id need to mention) and then it’s been closed.

If it is not a duplicate then it is been assigned to the developer by developer lead. Developer will work on
the defect and then he resolves it. Status of the defect is fixed now. Test engineer will verify the fixed
defect, if the defect has been resolved properly then the defect is marked as closed, if still now working as
expected then test engineer will reopen the defect again.

If a defect cannot be addressed in that particular cycle, then it is marked as Deferred to fix in future build.

Defect can be rejected for a. Not a defect b. cannot reproduce.

Defect Resolution Type

After receiving Defect Report from T.E.s, B.A.s, Dev Lead, Test Lead will go through the defects in the
daily Bug Meeting, and take necessary action on that defects.

Defect Resolution

Defects are categorized in following types:

1. Duplicate defects: Duplicate defects are to be closed.

2. Hardware limitation: Few defects are raised due to hardware limitation

3. Software Limitation: Defects raised because of software limitation.

4. N.A.: The defects which are not attempted.

5. Need for more info: Few defects lacks the complete information.

6. Not reproducible: The defects which cannot be reproducible.

7. Open: The defects in open status and needs to be resolved.

8. Deferred: Defects which are deferred to future build.

Severity:Severity of a defect is related to how severe a bug is. It is the impact that a defect has on the
development. The severeness of the defect for the test engineer to continue further testing depends on
following levels

- Blocker
- High
- Medium
- Low

Severity is set by the test engineer.

Priority:
Priority is urgency or importance of fixing a defect. Based on the business urgency development lead will
set the priority. Following are the priority levels:
 - Immediate
- High
- Medium
- Low

Different Kinds of Defects

A.UI Defects: Following type of defects are UI defects. It has low severity.

1. Spelling Mistakes 2. Text Overlapping 3. Font Size, font theme

4.Complex meaning

B.Error Handling: Following types of defects are error handling defects. It has medium severity.

1. Error handling message 2.Error message missing 3.Wrong Error message 4. Correct error
message with complex meaning

C.I/P Domain: Following types of defects are I/P domain defects. It has medium severity

1. Input objects are taking valid and invalid inputs. 2. Input objects are talking only invalid input. 3.
Input objects are taking values with exceed range,

D.Calculation Defects: Following types of defects are calculation defects. It has high severity.

1. Wrong output 2. Correct output without having decimal point. 3.Correct output with wrong no of
decimal points.

E. Race Condition Defects: Following types of defects are race condition defects. It has high severity

1. Doesn’t run on all expected browsers, O.S. Application gets hanged, dead lock

F. ID Control Defects: Following types of defects are ID control defects. It has low severity.
 1. Wrong version number
2. Logo missing/ wrong logo
3. Copyrights missing

Test Management Tool:

Test management tool refers to the management of all testing process. It includes creation of test cases,
its execution, raising defects, generation reports. Management tools like Test Director, QC, and Test link
are available in the market.

QC (Quality Center):

Till now we have seen, Manual testing done through documents for maintenance. JIRA, Heat Call,
Bugzilla etc. are used for defect raising. Microsoft excel is used for test case writing and test case results.
Now we will see features of Quality Center which can be used for test case writing, test execution, defect
reporting, generating reports, maintaining the versions, test management.

Tabs in QC are –

1. Management Tab: It has no access for test engineer. At the time of UAT, this tab is used,
2.Requirement Tab: It has access for test engineer. In this tab all F.R.S. (Functional Requirement
Specification) documents are kept. 3. Business Component: It has no access for test engineer. 4. Test
Plan: In the test plan tab, test engineer writes test case design.
5. Test Resources: It has no access for test engineer.6. Test Lab: Test case execution is done in test lab.
All test case modification is done in test plan only. 7. Test Defect: Defect are raised in Test Defect tab.8.
Dashboard: This tab is used for monitoring purpose. (E.g. TE1- 20 defects, TE2- 50 defects)
Chapter 13

Test Closure

Test closure is the last phase of the testing cycle. After completion of the reasonable test cycles
of test execution, the testing team is now conducting test closure review meeting to stop the test
execution. In this review meeting, testing team is concentration on –

A.Coverage Analysis: To ensure whether all modules are tested or not.

B. Calculate Defect Density: Calculate the ratio of how many defects are detected (means confirmed and
agreed upon, not just defects reported) to the size of the module (line of code).
C. Analysis of deferred defects: How many defects are deferred to future build is analyzed.

After completion of test closure review meeting, testing team is concentrating on final stage testing/final
regression testing/Pre acceptance testing

In this final stage, if any defect is detected, Developer will fix it within short time. If the time span is too
short or they are not able to fix it, then this defect will be mentioned as a known issue in the release note.

U.A.T. (User Acceptance Testing):

After completion of a successful test closure, the project manager is concentrating to collect feedback
from real customers/model customers. There are two ways to collect the feedback

1.α Testing

2. β Testing

The difference between the two is as follows:

Sr.
No α Testing β Testing
1 Conducted by real customers Conducted by model customers
2 Conducted by development side Conducted by customer side
3 Involvement of developers and testers Involvement of model customers
4 Suitable for projects Suitable for products.

Sign Off

After completion of the UAT, TL is gathering all the testing documents to form a final test summary report.
This report consists of following documents:

1. Test Strategy
2.Test Plan
3. Test Scenario
4. Test Cases
5. Test Execution Report
6. Defect Report
7. Summary Report
8. R.T.M.
And archive all the documents.

Test Case Maintenance: After the release and in the meantime test engineer will be updating the test
cases as per new functionality.

Lessons Learnt Document: After the release, test engineer prepares lessons learnt document.
Following learnings are mentioned in this document –

1. In previous release what went well.

2. What went wrong?
3. Things need to be done for next release.

Chapter 14

Testing terminologies

White box testing:

Testing the internal structure of the application (coding) is called as white box testing. It is done by
developers.

Black Box Testing:

Testing the external structure of the application (build) without knowing the internal structure is called as
black box testing. It is done by test engineers.

Gray Box Testing:

By knowing the internal structure of the application, testing the external structure (build) is called as gray
box testing. It is done by test engineers.

Retesting:

Testing a previously failed test again after the defect is fixed.

E.g. Defect raised –> Assigned to Dev ->In Progress->Fixed –> Checking (Retesting)

Regression:

If any new functionality is added or existing functionality is modified, regression testing is done just to
ensure that the other existing functionality is working as expected.

Ad hoc testing:

Ad hoc testing is testing the application randomly. After the test execution if free time available the ad hoc
testing is performed or if there is no time for test execution, then ad hoc testing is formed. Here test
engineer is well known to the application.

Exploratory Testing:

If there is no F.R.S., no test cases only build is given to test, then exploratory testing is performed on that
build by – browsing the application and preparing the Functional Understanding Document (FUD
– Browse the similar sites and then test the application

–If help is available, then understand the application using the help
–If B.A, Dev, client is available then speak to them and understand the functionality.
–If old defect report is available then go through it and understand the functionality.
–Based on the previous experience on the same domain.
Monkey Testing:

Testing the application randomly is called Monkey testing, here test engineer doesn’t know the application
at all. If there is no time for test execution, monkey testing is performed.

Verification and Validation:

Whether we are developing a right product or not is called verification.

Validating the product with respect to customer’s requirement is called validation.

Quality Assurance and Quality Control:

QA is a department which checks each and every role in the organization. In order to check whether they
are doing the work according to the company process guidelines or not. QA is a preventive activity.
E.g. Test cases are reviewed. This reviewing is a QA activity which prevents errors.

QC is a department which checks the developed applications. In order to confirm that they are working
according to the requirements. QC is a corrective activity. QC is a part of QA.

Minutes of Meeting (MOM):

MOM is a document prepared by any team members, after completion of the meeting. It contains action
points discussed in the meeting.

Non Conformance Report (NCR):

NCR is raised whenever the role is not following the process, then the penalty given for him is known as
NCR.

Defect Product & Defective Product:

If at all the product is not justifying some of the requirements but it is still usable then that type of product
is called as defect product.
If at all the product is not justifying some of the requirements as well as it is not usable then such type of
product is called defective product.

Audit:

It is a process of checking conducted on the roles with prior intimation. E.g. Internal audits, external
Audits.

Release Audit:

On the release day, internal QA team will be conducting the release audit to check the quality of the
product.

Review Report:

It is an outcome document of a review. If someone reviews any document and if they find any instance,
that instance will be noted in review report.

Slippage:

Slippage is defined as the amount of time a task has been delayed from its original baseline schedule.
The slippage is the difference between the scheduled start or finish date for a task and the baseline start
or finish date

Test bed:

It is a combination of test cases and test environment, is called test bed.

Defect Age:

The time gap between opening a defect and closing a defect is called as defect age.

Latent Defect:

If a defect is found later of releases is called latent defect.

Release Notes:

Along with the software the release note will be released to the client. This release note contains release
version number, release build number, known issues and list of open and closed issued.

Patch:

Whenever testing team suspend the build, the developer will rectify the problem and release the same
build as a patch.

Metrics:

Metrics can be used for measuring the testing activity. It has two types

A. Process Metrics: A metrics used to measure characteristics of the methods, techniques and tools
employed in developing, implementing and maintaining a software.
E.g. Effort variance, Scheduled variance, Test Case Development Productivity. Test case review effort.

B. Product Metrics: A metrics used to measure that characteristics of any product of software
development process. e.g.: defect density.

Effort Variance: Effort is calculated in hours. This is to compute the difference between estimated effort
and actual effort.

Deviation = (Actual effort – Estimated Effort)/ Estimated Effort * 100

Scheduled Variance is calculated in days. This is to compute the difference between planned schedule
and actual schedule.

Deviation= (Actual schedule-estimated schedule)/Estimated schedule * 100

Test Case Development Productivity:TC dev productivity= Actual no. of test cases/Actual effort in days

Test Case Review Efficiency:TC Review Effort= No. of TCs reviewed/ Effort in days

Test Case Execution Efficiency:TC Execution efficiency=No of TCs executed/Effort in days.