1.1. What is testing?

A procedure for critical evaluation or a means of determining the presence, quality, or

genuineness of something is termed as testing. In general, testing is finding out how well
something works.
What is Software? Software is a set of instructions to perform some task. Software is used in
many applications of the real world. Some of the examples are Application software, such as
word processors Firmware in an embedded system Middleware, which controls and coordinates distributed systems System software such as operating systems Video Games
Websites
Software is both a product and a vehicle for delivering a product (information). It is not
manufactured but engineered. As time goes, the software deteriorates during changing
conditions and requirements.
All of these software applications need to run without any error and provide a quality service to
the user of the application. In this regard the software has to be tested for its accuracyand
correctness.
Introduction to Software Testing
Software Testing is the process which ensures that the system or application is free from the
inconsistency or unusual behaviour and working as per the expected behaviour or
requirements. It is a critical element in the software development life cycle and has the potential
to save time and money by identifying problems early and to improve customer satisfaction by
delivering a more defect-free product.
Software Testing can be defined in simple words as Performing Verification and Validation of
the Software Product for its correctness and accuracy of working.
IEEE Definition Software testing is the process of analysing a software item to detect the
differences between existing and required conditions (that is, bugs) and to evaluate the features
of the software item.
Importance of Software Testing
A clever person solves a problem. A wise person avoids it. Albert Einstein
Why is testing necessary?
Complexity of software makes it error prone Untested or weakly tested software can cause
losses in real life.

 To learn about reliability of software To stay in business

Software testing answers questions that development and code reviews cannot. Does it really
work as expected? Does it meet the users requirements? Is it what the users expect? Do
the users like it? Is it compatible with our other systems? How does it perform? How does it
scale when more users are added? Which areas need more work? Is it ready for release?
Examples of Importance of Software Testing.
ISRO calls off GSLV launch after fuel leak.
Because of the final flight test ISRO could identify the problem and called off the launch and
thus saved millions and millions of RS <<http://www.thehindu.com/news/national/isro-calls-offgslv-launch-after-fuel-leak/article5038402.ece>>
NASA Mars Polar Lander
NASA Mars Polar Lander 1999 Malfunction due to anunexpected setting of a single data bit
Disneys Lion King
Disneys Lion King 1994 1995- The software did not work on the most common systems that
the public had.
When to Start / Stop Testing
1. When to Start Testing
An early start to testing reduces the cost, time to rework and error free software that is delivered
to the client. In Software Development Life Cycle (SDLC) testing can be started from the
Requirements Gathering phase and lasts till the deployment of the software.
It also depends on the development model that is being used.
Example: In Water fall model formal testing is conducted in the Testing phase.
And in Incremental model, testing is performed at the end of every
increment/iteration and at the end the whole application is tested.
2. When to Stop Testing

It is difficult to determine when to stop testing, as testing is a never ending process. It is difficult
to claim that any software is 100% tested.
Following are the aspects which should be considered to stop the testing:
Testing Deadlines. Completion of test case execution. Completion of Functional and code
coverage to a certain point. Bug rate falls below a certain level and no high priority bugs are
identified. Management decision.

Chapter 1: Introduction to Testing

Software failure is a term used to label a malfunction, a flaw, a failure or a fault in a computer
program that produces incorrect results. Most software failures arise from errors made by
people in a program's design.
Effect of an Error
An error or mistake leads to a defect which can in turn cause the software failure.
Error ---------> Defect -------------> Failure
Causes of software Failure
Some of the causes making software to fail are:
Environmental conditions
The environment set up for testing the various versions of the code being unavailable on time.
Hardware Failures

Crash of the dependent hardware, loss of versions can impact the code quality
Lack of skilled resources
Lack of knowledge both Technical and Business can lead to critical, expensive errors. In order
to avoid this, companies should seek people with specialized skills, even though they may come
at a higher price.
Inadequate reviews / walk-through
The defects might go unnoticed and cause the failure.
Changing Requirements

Frequent changes to requirements impacts the quality of code and in turn the software.

Time constraints to meet up the deadlines

Rushing up to meet the deadlines leaves many defects being injected into the code.
Impact of Software Failure
Software failure can lead to:
Loss of money
Loss of time
Loss of business reputation
Injury
Death

Software Failure Examples

In February 2003 the U.S. Treasury Department mailed 50,000 Social Security checks without

a beneficiary name. A spokesperson said that the missing names were due to a software
program maintenance error.
In October 1999 the $125 million NASA Mars Climate Orbiteran interplanetary weather
satellitewas lost in space due to a data conversion error. Investigators discovered that
software on the spacecraft performed certain calculations in English units (yards) when it should
have used metric units (meters).
In June 1996 the first flight of the European Space Agency's Ariane 5 rocket failed shortly
after launching, resulting in an uninsured loss of $500,000,000. The disaster was traced to the
lack of exception handling for a floating-point error when a 64-bit integer was converted to a 16bit signed integer.
Keeping Software Under control
To prevent the software failure, it has to be thoroughly tested before it go live.
Incorrect testing or insufficient testing causes a software to fail.
More and better testing is needed for a defect free software, but it isnot quite as simple to
achieve.
Each and every part of the software has to be tested.
With large and complex systems it will never be possible to testeverything exhaustively.
There is a greater probability of a failure in the large and complexsystem and the impact of
the failure is also greater.

What we test, and how much we test is related to risk involved. Greater risk implies more and
better testing is required.
Testing is done to deliver a quality product. Here quality refers whether the product is meeting
the user's requirements.
Resource Triangle
The items at the corner of the triangle are time, money and quality. These three affect one
another, and also influence the features that are or are not included in the delivered software. If
we need to deliver a system faster (i.e. in less time), it will usually cost more.
Testing is to ensure that key functional and nonfunctional requirements are examined before
any defects are reported to the development team.
Testing cannot directly remove defects, nor can it directly enhance quality.
By reporting defects it makes their removal possible and so contributes to the enhanced
quality of the system.
In addition, the systematic coverage of a software product to be measured.
Testing is one component in the overall quality assurance activity that seeks to ensure that
systems enter service without defects that can lead to serious failures.
Go to Doubts

1.3. General Principles of Testing

Seven Principles of Testing
To test the entire possible combinations of project, EXECUTION TIME &COSTS will rise
exponentially. Hence, the testing principle states that EXHAUSTIVE( In this type of testing we
try to check the output given by the software by entering all the possible inputs, in fact we use
all the permutations and combinations of the inputs.) testing is not possible. Instead we need
optimal amount of testing based on the risk assessment of the application where the principles
will play a major role.
Principles Of Testing

Software testing is an extremely creative and intellectually challenging task. When testing
follows the principles, the creative element of test design and execution rivals any of the
preceding software development steps.
Principle 1: Testing shows presence of defects
Testing can show that defects are present, but cannot prove that there are no defects. Even
after testing the application or product thoroughly we cannot say that the product is 100% defect
free.
Testing always reduces the number of undiscovered defects remaining in the software but
even if no defects are found, it is not a proof of correctness.
Principle 2: Exhaustive testing is impossible
Testing everything including all combinations of inputs and preconditions is not possible. So,

instead of doing the exhaustive testing we can use risks and priorities to focus testing efforts
Example:In an application in one screen there are 15 input fields, each having 5 possible
values, then to test all the valid combinations you would need 30,517,578,125 (515) tests.
The above Example is very unlikely that the project timescales would would allow for this
number of tests. So, accessing and managing risk is one of the most important activities and
reason for testing in any project.
Principle 3: Early Testing
The sooner we start the testing activities the better we can utilize the available time. As soon

as the initial products, such the requirement or design documents are available, we can start
testing.
It is common for the testing phase to get squeezed at the end of the development life-cycle,
i.e. when development has finished, so by starting testing early, we can prepare testing for each
level of the development life-cycle

Another important point about early testing is that when defects are found earlier in the life-

cycle, they are much easier and cheaper to fix.

Principle 4: Defect Clustering
During testing, it can be observed that most of the reported defects are related to small

number of modules within a system. i.e. small number of modules contain most of the defects in
the system.
A small number of modules contains most of the defects discovered during pre-release testing
or shows the most operational failures.
By identifying and focusing on these clusters, testers can efficiently test the sensitive areas
while concurrently testing the remaining non-sensitive areas.
Principle 5: Pesticide Paradox
The same kind of tests are repeated again and again, eventually the same set of test cases

will no longer be able to find any new bugs. This is called Pesticide Paradox.
To overcome this Pesticide Paradox, it is really very important to review the test cases
regularly and new and different tests need to be written to exercise different parts of the
software or system to potentially find more defects.
Anytime a fault is fixed or a new functionality added, we need to do regression testing to make
sure the new changed software has not broken any other part of the software.
However, those regression test cases also need to change to reflect the changes made in the
software to be applicable and hopefully fine new defects.
Principle 6: Testing is context dependent
Testing is basically context dependent. Different kinds of sites are tested differently.
For example, a software application in a medical device needs more testing than a games

software. More importantly a medical device software requires risk based testing, be compliant
with medical industry regulators and possibly specific test design techniques.
The same tests should not be applied across the board because different software products
have varying requirements, functions and purposes
Principle 7: Absence of errors fallacy

A test that finds no errors is different than concluding that the software is error-free. It should

be assumed that all software contains some faults, even if said faults are hidden.
When the built system is unusable and does not fulfill the users needs and expectations then
finding and fixing defects does not help.
Go to Doubts

1.4. Software Quality

Quality
There exist several definitions of software quality. Also, one quality attribute might be more
important to a user than another. In any case, software quality is a multidimensional quantity
and is measurable.
Quality from the
Customers Viewpoint - Fitness for use, or other customer needs
Producers Viewpoint - Meeting requirements

Quality has two elements

QA - Quality Assurance
QC - Quality Control

Quality Assurance
Quality assurance activities are work process oriented.
They measure the process, identify deficiencies, and suggest improvements.
The direct results of these activities are changes to the process.
These changes can range from better compliance with the process to entirely new processes.
The output of quality control activities is often the input to quality assurance activities.
Audits are an example of a QA activity which looks at whether and how the process is being

followed. The end result may be suggested improvements or better compliance with the
process.
Quality Control
What is Quality Control?
Quality control activities are work product oriented.

They measure the product, identify deficiencies, and suggest improvements.

The direct results of these activities are changes to the product.
These can range from single-line code changes to completely reworking a product from

design.
They evaluate the product, identify weaknesses and suggest improvements.
Testing and reviews are examples of QC activities since they usually result in changes to the
product, not the process.
QC activities are often the starting point for quality assurance (QA) activities.
Previous
General Principles of Testing

Go to Doubts

2.1. Introduction to Software Development Life Cycle

Software Development Life Cycle (or SDLC) is the process which is followed to develop a
software product. It is a structured way of building software applications. Most organizations
have a process in place for developing software; this process may, at times, be customized
based on the organizations requirement and framework followed by organization.Life Cycle
Model is one specific embodiment of a software process
SDLC Phases
The software development life cycle (SDLC) is a framework defining tasks performed at each
step in the software development process.
It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance
specific software.
The life cycle defines a methodology for improving the quality of software and the overall
development process.
The following picture depicts the phases that are part of a development cycle.
Requirements Gathering

A Software Requirement Specification or SRS is a document which records expected behavior

of the system or software which needs to be developed.
Design Software design is the blueprint of the system, which once completed can be provided
to developers for code development. Based on the components in design, they are translated
into software modules/functions/libraries, etc and these pieces together form a software system.
Coding During this phase, the blueprint of the software is turned to reality by developing the
source code of the entire application. Time taken to complete the development depends on the
size of the application and number of programmers involved.

Chapter 2: SDLC AND STLC

Assurance - All Chapters
Home
See Leaderboard

2.2. SDLC Models

There are various software development life cycle models defined and designed which are
followed during software development process.
These models are also referred as "Software Development Process Models".
Each process model follows a Series of steps unique to its type, in order to ensure success in
process of software development.
Waterfall Model

In the Waterfall model, the different phases of the software development life cycle are explicitly
recognized as mentioned in picture below: .
In this model, the project takes a straight line path.Since different phases are explicitly
recognized,the finalisation of the Contract is seen with reference to delivery and payment
schedules of different phases.
The waterfall model is the oldest and most widely used in software development life cycle. It is
also known as sequential model. Each phase must be completed before the next phase
begins.At the end of each review takes place to determine if the project is on the right track or
not.
Since requirement validation is not done in an explicit manner,it may result in design and
development of large quantities of unusable code. It may also result in extensive rework later,as
document-driven standards, force elaborate specifications of poorly understood user interfaces
and decision- support functions.
Advantages
Below are some of the advantages of the Waterfall Model
Simple and easy to use. Easy to manage due to the rigidity of the model each phase has
specific deliverable and a review process. Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.
Disadvantages

 Adjusting scope during the life cycle can kill a project No working software is produced until
late during the life cycle. High amounts of risk and uncertainty. Poor model for complex and
object-oriented projects. Poor model where requirements are at a moderate to high risk of
changing.
V-Model
V- model 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. Testing of the product is planned in
parallel with a corresponding phase of development.
Advantages
Simple and easy to use Each phase has specific deliverable Higher chance of success over
the waterfall model due to the development of test plans early on during the life cycle Works
well for where requirements are easily understood
Disadvantages
Very inflexible, 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 does not provide a clear path for problems found during testing
phases.
The Spiral Model
A well-managed development project should take a straight line approach,right from feasibility
report to analysis, design, testing, and acceptance to operation. But in actuality, the project
needs to proceed iteratively by taking a spiral path. The project starts with the analysis phase,
then proceeds towards design, moves back to analysis and then design, followed by coding
(version 1.0) and back to design and so forth.
The basic idea behind this model is that you start on a small scale,in the middle of the core
functionality, explore the risks (such as poorly understood requirements and architecture,
potential performance problems, problems in underlying technology etc.) and then make a plan
to handle the risks. This should be followed by a commitment to approach, for the next iteration.
Each iteration moves your project to a larger scale. One layer of the project is rolled first, to
check what was actually wanted, and then, work on the next layer is started.
Each iteration involves the following steps:
- To determine objectives, alternatives and constraints
- To identify and resolve risks
- To evaluate alternatives
- To develop the deliverables for that iteration, and to verify their correctness
- To plan the next iteration
- To commit to an approach for the next iteration

Advantages Good for large projects and also for medium to high risk projects High amount
of risk analysis hence avoidance of risk is enhanced String approval and documentation
control Additional functionality can be added at a later date Software is produced early in the
software life cycle.
Disadvantages
Can be a costly model to use. Risk analysis requires highly specific expertise. Projects
success is highly dependent on the risk analysis phase. Doesnt work well for smaller projects.
Incremental model
The whole requirement is divided into various builds. Multiple development cycles make 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.Each subsequent
release of the module adds function to the previous release. The process continues till the
complete system is achieved
Advantages
Generates working software quickly and early during the software life cycle. More flexible
less costly to change scope and requirements. Easier to test and debug during a smaller
iteration. Customer can respond to each built. Lowers initial delivery cost.

 Easier to manage risk because risky pieces are identified and handled during each iteration.
Disadvantages
Needs good planning and design. Needs a clear and complete definition of the whole system
before it can be broken down and built incrementally. Expensive than waterfall model
Agile Model
Agile model is also a type of Incremental model which is used for time critical applications.
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 ensure
software quality is maintained.Extreme Programming (XP), Scrum are some of the most well
known agile development model
External link: https://help.rallydev.com/sites/default/files/multimedia/videos/agile_primer.swf
Advantages
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 welcome.
Disadvantages

 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 new programmers, unless combined with experienced
resources.
Different software development models have their own advantages and disadvantages. The
right model or combination of models has to be chosen based on the project and all other
related factors.
CC India
Campus Commune
My Channels

: SDLC AND STLC

Assurance - All Chapters
Home

Go to Doubts

2.3. Introduction to Software Testing Life Cycle

The process of testing a software in a well-planned and systematic way is known as Software
testing life cycle (STLC)
Software testing life cycle is an integral part of the software development life cycle.
The overall aspect of STLC phase deals with testing and rectifying any error code generating
within the program under various test conditions.
STLC Phases
In STLC process, different activities are carried out to improve the quality of the product.

1. Requirement Analysis
During this phase, test team studies the requirements from a testing point of view to identify the
testable requirements. The QA team may interact with various stakeholders (Client, Business
Analyst, Technical Leads, System Architects, etc) to understand the requirements in detail.
Requirements could be either Functional (defining what the software must do) or Non Functional
(defining system performance /security availability). Automation feasibility for the given testing
project is also done in this stage.
Activities:
Identifytypes of tests to be performed.
Gather details about testing priorities and focus.
Prepare Requirement Traceability Matrix (RTM).
Identify test environment details where testing is supposed to be carried out.
Automation feasibility analysis (if required).
Deliverables:
RTM
Automation feasibility report. (if applicable)
2. Test Planning
This phase is also called Test Strategy phase. Typically, in this stage, a Senior QA manager will
determine effort and cost estimates for the project and would prepare and finalize the Test Plan.
Activities:
Preparation of test plan/strategy document for various types of testing
Test tool selection

 Test effort estimation

Resource planning and determining roles and responsibilities.
Training requirement
Deliverables:
Test Plan and Test Strategy document.
Effort estimation document.
Test Strategy
Test Strategy is the first document QA should prepare for any project. A Test
Strategydocument is a high level document and normally developed by project manager.
TheTest Strategy is normally derived from the Business Requirement Specificationdocument
and sent to the developer and technical product manager for review.
The Test Strategy document is a static document meaning that it is not updated too often. It
sets the standards for testing processes and activities and other documents such as the Test
Plan draws its contents from those standards set in the Test Strategy Document.
The Test Strategy is a high-level document that details the approach QA will follow to achieve

testing objectives. This document can vary based on the project.

It describes the test levels to be performed and the testing within those levels for an

organization.
It typically includes the decisions made based on the project's goal and the riskassessment

carried out, starting points regarding the test process, the test design techniques to be applied,
exit criteria and test types to be performed.
The overall approach to testing is described in Test Strategy. For each major group of

features or feature combinations, the approach specified should ensure that these feature
groups are adequately tested. The major activities, techniques, and tools which are used to test
the designated groups of features are also specified in Test Strategy document.
The approach should be described in sufficient detail to permit identification of the major

testing tasks and estimation of the time required to do each one.

Test strategy is one powerful factor in the success of the test effort and the accuracy of the

test plans and estimates.

Some of the activities carried out at the Test Strategy level are as given below. These details
will be documented in the Test Strategy document
Define test Objectives, Scope of testing, testing Approach.
Define testing phases, activities and Identify high risk items.

Test Environment and Test Data set up

Define test dependencies, Test assumptions, test completion and user acceptance criteria
Establish configuration standards and defect management

Components of the Test Strategy document

Scope and Objectives Test Approach Test Activities Business issues Test Responsibility
Matrix Industry standards to follow Roles and responsibilities Methodologies and techniques
Test automation and tools Test deliverable Defect reporting and tracking Testing
measurements and metrics Communication and status reporting Risks and mitigation
Change and configuration management Training plan
Test Plan
Test Plan is a document describing the scope, approach, resources and schedule of intended
test activities. It identifies, amongst others, test items, the features to be tested, the testing
tasks, who will do each task, the degree of tester independence, the test environment, the test
design techniques, the entry and exit criteria and any risks requiring contingency planning. It is a
record of the test-planning process. In precise we can say Test plan is a document that covers
what will be tested (Objectives, Scope of Testing) , who will test (Resources, Responsibilities,
Approvers), when to test (Schedule) & how to test (Tools, Standards, Methodology)
Why do we write test plans?
Writing a test plan guides our thinking. We find that if we can explain something in words, we
understand it. If not, there's a good chance we don't. Writing a test plan forces us to confront the
challenges that await us and focus our thinking on important topics
Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the
delay comes at the end of the schedule, no one is aware of schedule trouble until almost the
delivery date and delay at this point has unusual severe financial repercussions. The project is
fully staffed, and cost-per-day is maximum. It is therefor every important to allow enough system
test time in the original schedule.

The test planning process and the plan itself serve as vehicles for communicating with other
members of the project team, testers, peers, managers and other stakeholders.This
communication allows the test plan to influence the project team and the project team to
influence the test plan, especially in the areas of organization-wide testing policies and
motivations; test scope, objectives and critical areas to test.
The test plan also helps us manage change. During early phases of the project, as we gather
more information, we revise our plans. As the project evolves and situations change,we adapt
our plans. Written test plans give us a baseline against which to measure such revisions and
changes. Furthermore, updating the plan at major milestones helps keep testing aligned with
project needs.
At a high level, you need to consider the purpose served by the testing work. In terms of the
overall organizational needs, this purpose is referred to variously as the test team's mission or
the organization's testing policy. In terms of the specific project, understanding the purpose of
testing means knowing the answers to questions such as:
What is in scope and what is out of scope for this testing effort? What are the test objectives?
What are the important project and product risks? What constraints affect testing (e.g.,
budget limitations, hard deadlines, etc.)? What is most critical for this product and project?
Which aspects of the product are more (or less) testable? What should be the overall test
execution schedule and how should we decide the orderin which to run specific tests?
Need for Test Plan
If you fail to plan you plan to fail
One of the keys to successful software testing
Discuss issues early

Test Plan enables to decide in advance

how a projects objectives will be met
how to manage the available resources
how to manage time
how to obtain the desired quality
how to control risks

Level-Specific Test Plan

Master Test Plan Unit Test Plan Integration Test Plan System Test Plan

 Performance Test Plan Acceptance Test Plan

Major considerations are same for different testing levels, but differ in Scope Scope depends on
the level of testing
Five key characteristics defined in a Test Plan are
Scope & Objectives - Defining what will be covered in a project
Resource - What type and number of resources to be used to accomplish the objectives
Schedule/Time - Tasks and their schedules
Quality - Standards to be used and/or customized
Risk - Defines in advance what may happen to drive the plan and what will be done to recover

the situation
And Others

Test Plan Contents

ToC of Test Plan confirming to IEEE 829 Standard.
Test plan identifier Introduction Test items Features to be tested Features not to be
tested Approach Item pass/fail criteria Suspension and resumption criteria Test
deliverables Test tasks Environmental needs Responsibilities Staffing and training needs
Schedule Risks and contingencies Approvals
Contents of Test Plan
Scope clause: Defines what will be covered in a project
Test items
Items of software, hardware, and combinations of these which will be tested.
Programmers or Developers point of view

Contents depend on level of the Test Plan

Features to be tested
Which parts of the software specification are to be tested?
User or customer point of view
Contents depend on level of the Test Plan
Help to focus on software risks

Features not to be tested

Which parts of the software specification are to be excluded?
Reason for not testing
Normally lists low risk features

Resource clause: Gives overall view of the resources to deliver the tasks.
Environmental Needs
What is needed in the way of testing software, hardware etc.
Are there any special requirements for this test plan, such as special hardware such as

simulators, static generators etc.

How will test data be provided. Are there special collection requirements or specific ranges of

data that must be provided?

How much testing will be done on each component of a multi-part feature?
Specific versions of other supporting software.
Restricted use of the system during testing

Responsibilities
Lists who has responsibility for delivering various part of the plan like setting risks.
Selecting features to be tested and not tested.
Setting overall strategy for this level of plan.
Ensuring all required elements are in place for testing.
Providing for resolution of scheduling conflicts, especially, if testing is done on the production

system.
Who provides the required training?
Who makes the critical go/no go decisions for items not covered in the test plans?

Staffing and training needs

Number of people and skills needed to execute the plan

Training needs might include

How to use tool
Testing Methodology
Interfacing systems
Management systems such as defect tracking, configuration management, basic business

knowledge (related to the system under test), etc.

Time clause: Specifies the tasks to be undertaken to meet the quality objectives and when they
occur
Testing tasks
Tasks that are necessary for performing test execution and the dependencies, the elapsed
time they will take, and resource required.
Examples include:
o Test Planning
o Test Analysis
o Test Design
o Test Implementation
o Test Execution
o Test Evaluation

Schedule
This specifies when the tasks will take place.
o It should be based on realistic and validated estimates.
Build around milestones
o All relevant milestones should be identified
Reference to project schedule.
o It is always best to tie all test dates directly to their related development activity dates. This
prevents the test team from being perceived as the cause of a delay. For example, if system
testing is to begin after delivery of the final build, then system testing begins the day after
delivery. If the delivery is late, system testing starts from the day of delivery, not on a specific
date. This is called dependent or relative dating.
Include deadlines
Estimation and resources are considered

How slippage in the schedule will be handled should also be addressed here.

o If the estimates for the development of the application are inaccurate, the entire project plan

will slip. The first area of a project plan to get cut when it comes to crunch time at the end of a
project is the testing. If the users know in advance that a slippage in the development will cause
a slippage in the test and the overall delivery of the system, they just may be little more tolerant,
if they know its in their interest to get a better tested application.
o By spelling out the effects here you have a chance to discuss them in advance of their actual
occurrence. You may even get the users to agree to few defects in advance, if the schedule
slips.

Quality clause: It specifies to what standard the testing will be completed against the scope.
Introduction section
o This gives a high level view of the testing standard. Specifies overall test objectives.
o A basic description of the project or release including key features,history, etc.,
o An introduction to the plan that describes the scope of the plan.
o Any references to other plans, documents or items that contain information relevant to this
project/process. If required a references section can be created to contain all reference
documents.
o Other items
o Resource and budget constraints, scope of the testing effort, how testing relates to other
evaluation activities (Analysis & Reviews),and possible process to be used for change control
and communication and coordination of key activities.

As this is the Executive Summary the information kept here should be brief and to the point.
Item pass/fail criteria
o This defines how the item being tested has passed and completion criteria for this plan. This
is a critical aspect of any test plan and should be appropriate to the level of the plan. Each test
item needs to have an expected result relative to the test level.
o At the Unit test level this criteria could be as
o All test cases completed.
o A specified percentage of cases completed with a percentage containing some number of
minor defects.
o Code coverage tool indicates all code covered.
o At the Master test plan level this criteria could be as

o All lower level plans completed.

o A specified number of plans completed without errors and a percentage with minor defects.

This could be an individual test case level criterion or a unit level plan or itcan be
generalfunctional requirements for higher level plans.
Describes severity
o The number and severity of defects located
Approach
o This is the overall test strategy for this test plan. It should be appropriate to the levelof the
plan (master, acceptance, etc.) and should be in agreement with all higher andlower levels of
plans. Overall rules and processes should be identified.This gives details of how the testing
process will be followed.
Test deliverables
o This specifies the test documents and other deliverables to be produced.
o Test Plans
o Test Design Specs
o Test Cases
o Custom Tools
o Defect Reports
o Test Summary Reports
o Simulators (if any)

One thing that is not a test deliverable is the software itself that is listed under test itemsand is
delivered by development.
Risk clause: Defines in advance what will happen if something goes wrong with the plan.
Suspension criteria and resumption requirements
o This is a particular risk clause to define when testing will stop and restart.
o Conditions for temporary suspension
o If the number or type of defects reaches a point where the follow ontesting has no value, it

makes no sense to continue the test.

o Metrics can be used to derive condition
o Specifies what constitutes stoppage for a test or series of tests andwhat is the acceptable

level of defects that will allow the testing toproceed past the defects.

Risks and contingencies

o This defines all risk events, their likelihood, impact with an emphasis on the testing process
and counter measures to over come them. Examples
o Lack of personnel resources when testing is to begin.
o Lack of availability of required hardware, software, data or tools.
o Late delivery of the software, hardware or tools.
o Delays in training on the application and/or tools.
o Changes to the original requirements or designs.
o Specify what will be done for various events, for example requirements definition will be

complete by January 1, 19XX, and, if the requirements change after that date, the following
actions will be taken.
o The test schedule and development schedule will move out an appropriate number of days.

This rarely occurs, as most projects tend to have fixed delivery dates.
o The number of test performed will be reduced.
o The number of acceptable defects will be increased.
o These two items could lower the overall quality of the delivered product.
o Resources will be added to the test team.
o The test team will work overtime.
o This could affect team morale.
o The scope of the plan may be changed.

This section helps us to make

o Intelligent and informed decisions
o Consider risk priorities to move features from Features to Be Tested to Feature not to be
Tested
Others
o Test plan identifier
o This is a unique name or code by which the plan can be identified in the project's

documentation including version.

o Approvals

o This clause contains the signatures of the various stakeholders in the plan, to show they
agree in advance with what it says.
o Various stakeholders signature

o Different Approvers for different levels of Test Plan

o Approvers should involve in the creation and/or review of the plan

Test Strategy VS Test Plan

In any project, testing is an integral aspect of the process. Testing is a way to make sure that
the project is up to standards. In order to ensure quality and the proper testing methods, the
company usually draws up papers documenting the process of the project. These documents
also serve as proof that the project has complied with any and all required testing methods. Test
strategy and test plan are two such documents that the company draws up
A test strategy outlines the testing approach that the company aims to take. The purpose of a
test strategy is to inform project managers, testers, and developers about some of the key
issues of the testing process. A test plan, on the other hand, is a detailed document which lists
the systematic approach to testing the system. Its aim is to map out the detailedunderstanding
of the workflow
The main difference between the two is their scope. The test strategy is a mere outline of the

entire project testing. It covers the general views and objectives that the project should achieve,
in addition to the approaches that should be used to achieve them. It is usually a project-wide
document that is shared with the entire project team and/or the whole company
The test plan is more detailed. It incorporates a lot of the specifics of that which has been
outlined in the test strategy, such as who does the actual testing and how the steps are to be
conducted. However, it will always follow the guidelines as stated in the test strategy. The test
plan may deal with the entire project as a whole or a specific part of the project. In some smaller
projects, the test strategy can also be found as a section of the test plan.
Some companies include the Test Approach or Strategy inside the Test Plan, which is fine

and it is usually the case for small projects. However, for larger projects, there is one Test
Strategy document and different number of Test Plans for each phase or level of testing
Furthermore, the test strategy is a static document, i.e. it is the same throughout the project

from the beginning to the end. However, the test plan may often be revised in face of
unforeseen circumstances faced by the project. Hence, it is versatile
3. Test Design
This phase involves creation, verification and rework of test cases & test scripts. Test data, is
identified/created and is reviewed and then reworked as well.
Activities:
Create test cases, automation scripts (if applicable)
Review and baseline test cases and scripts

 Create test data (If Test Environment is available)

Deliverables:
Test cases/scripts
Test data
4. Test Environment Setup
Test environment decides the software and hardware conditions under which a work product is
tested. Test environment set-up is one of the critical aspects of testing process and can be done
in parallel with Test Case Development Stage. Test team may not be involved in this activity if
the customer/development team provides the test environment in which case the test team is
required to do a readiness check (smoke testing) of the given environment.
Activities:
Understand the required architecture, environment set-up and prepare hardware and software
requirement list for the Test Environment.
Setup test Environment and test data
Perform smoke test on the build
Deliverables:
Environment ready with test data set up
Smoke Test Results.
5. Test Execution
During this phase test team will carry out the testing based on the test plans and the test cases
prepared. Bugs will be reported back to the development team for correction and retesting will
be performed.
Activities:
Execute tests as per plan. Document test results and log defects for failed cases Map
defects to test cases in RTM Retest the defect fixes Track the defects to closure
Deliverables:
Completed RTM with execution status Execute tests as per plan. Test cases updated with
results
6. Test Cycle Closure

Testing team will meet, discuss and analyze testing artifacts to identify strategies that have to
be implemented in future, taking lessons from the current test cycle. The idea is to remove the
process bottlenecks for future test cycles and share best practices for any similar projects in
future.
Activities:
Evaluate cycle completion criteria based on Time,Test coverage,Cost,Software,Critical
Business objectives and Quality Prepare test metrics based on the above parameters.
Document the learning out of the project Prepare Test closure report Qualitative and
quantitative reporting of quality of the work product to the customer. Test result analysis to find
out the defect distribution by type and severity
Deliverables:
Test Closure report Test metrics
Go to Doubts

2.4. Levels of Testing

There are broadly four levels of testing done in any Testing Project
Unit Testing Integration Testing System Testing Acceptance Testing
Unit Testing
Unit Testing is testing unit of code (program or set of programs) using Unit Test
Specifications,after coding is completed. It involves the basic testing of a piece of code, the size
of which is often undefined in practice, although it is usually a function or a subroutine. It tests
the functional aspects. It tests smallest testable part of an application. It is done by the
developer of the functionality.
Example:
Testing of a cobol program in the reservation system that calculates the price for the ticket
requested based on the inputs supplied to the program from the calling cobol program.
Integration Testing

The process of testing interfaces and data flows between the programs within a sub system,and
between the sub-systems within a system is known as Integration Testing.
In Integration testing tester must look for bugs in the relationship and the interfaces between
pairs of components and groups of components under test.
Example:
Check whether the calling program in previous example passes the right information relating to
starting station and destination, date of journey, discounts to be applied andclass requested.
System Testing
System Testing is a test, executed by the developer or independent test team in a laboratory
environment that should demonstrate that the developed system or subsystems meet the
requirements set in the functional and quality specifications.
It is a process of proving that the system meets its stated design specifications (design
documents) w.r.t criteria such as recoverability, maintainability and security
Example:
Comprehensive black box testing of railway reservation system with transactionsinitiated and
validations performed on databases and reports generated after thecompletion of the
transactions
Acceptance Testing
It is a test, executed by the user(s) and system manager(s) in an environment simulating the
operational environment to the greatest possible extent, that should demonstrate that the
developed system meets the functional and quality requirements.
Non Functional and Other types of Testing
Performance testing Volume testing Load testing Limit testing Stress testing Disaster
Testing Recovery testing Security testing Reliability testing Installation Testing Usability
Testing Accessibility Testing Regression testing

Go to Doubts

3.1. Need for Testing as a separate stream and Testing as

a Profession
Testing is part of overall Quality Assurance It covers the Quality Control aspect of ensuring
Quality. It provides sufficient information to the stake holders for decision making regarding
release of the software/ system, for the next development step or handover to customers.
Testing is not just plain documentation. It is understanding the domain and application
functionality. coding in case of Automation.Testing is breaking the code to make better
solutions.
Need for Testing as a separate stream
The testing team needs to be independent and empowered in order to be effective.
SeparateTesting team would have people having sufficient knowledge and ability to test the
software
Testers would have independent view about the work products derived from requirement
statement
Developers tend to be optimistic while developing s/w that right and correct input will be given
to the s/w while testing.
There may be blindfolds while understanding requirements or selection of approach, and
developers may not be willing to find more defects.

 Understanding approach related defects may not be found by developers. Platform or

database related defects may not be uncovered as developers may feel that as a technological
limitations. As per developers, technology is creating problems.
Developers have more of creation skills while testing needs more of a destruction skill
Special skills required for doing special tests would be available in independent testing teams.
Testing as a Profession
The Wrong Notion:

The Reality:

Next
Building a career in Testing

Chapter 3: Testing as a career and

qualities of a tester
Assurance - All Chapters
See Leaderboard

Go to Doubts

3.2. Building a career in Testing

The below points to be noted for building a career in Testing
Understand the Testing Principles Have the right mind set and set up own goals Learn
testing processes & methodologies

 Take training on testing tools Take professional training on software testing Complete
software testing certifications Learn the Domain Move up in the hierarchy
Behind every great Developer there is an equally great Tester.
Professional Certifications in Testing
Training & Certification makes a better Test Professional. Assurance Academy which is part of
the Assurance Services Unit caters to the competency development in software testing in TCS.
Below is the list of some of the widely taken up certifications in Testing
Roles and Responsibilities

Test Engineer / Tester

Execute test cases as per test plans and log defects Work closely with Test Lead / Analyst to
achieve desired objectives
Test Analyst
Develop Test Cases, Test Scripts and Test Data Prepare traceability matrix Work closely
with Testing team to achieve the desired test result
Test Lead
Develop and manage Test Plans Monitor test execution and track defects Establish Testing
Environment, processes and implement methodologies Report status of testing and coordinate with end-users, testers and test manager
Test Automation Engineer

 Prepare test automation design based on the test automation architecture and framework
defined for the project Define standards and guidelines for automation
Test Strategist
Design testing framework including automated testing Review testing deliverables Analyze
testing tools and recommend for use Define test strategy Define Metrics
Test Process Consultant
Assess testing processes and recommend improvement action plan Assess test automation
feasibility Prepare assessment plan and coordinate with the project/program stakeholders
Test Manager
Develop test strategy Planning, effort estimation, resource management and training
Manage and deliver the Testing team activities Establish, track and improve process
efficiencies Identifying risks and formulating mitigation strategies
Business Analyst
Prepare high level test scenarios based on business scenarios and requirements Analyze
requirements for accuracy and completeness from a business perspective Review high level
test scenarios prepared
Test Consultant
Assess testing processes and recommend improvement action plan Prepare assessment
plan and coordinate with the project/programme stakeholders Pre-sales/ business
development
Test Automation Consultant
Automation feasibility analysis and tool evaluation Automation approach and roadmap Presales/ business development Creation of assets Product review/ keep abreast of
developments in product space
Test Center Delivery Manager
End-to-end management of testing delivery for multiple projects / initiatives Identify and
monitor issues, risks and concerns at test centre level Reporting to Customer Management

 Establish Client expectations End-to-end management of testing delivery Identify and

monitor issues, risks and concerns at test centre level Reporting to Customer Management
Latest trends in Testing
Some of the major trends in software testing are as follows.
Mobile Usability testing Client side performance testing Automated cross browser testing
Mobile performance testing Exploratory Testing Testing in the cloud
Go to Doubts

3.3. Qualities of a Tester

Not just anyone can claim to be an exceptional software tester. Software testing requires a
unique skill set, and the best software testers are the ones that continuously strive to expand
their knowledge and hone their testing strategies. In short, good testers always want to get
better.
A Great Tester is one who wants to know more than the developers know to have that breaking
edge.
Skills required to become a Software Tester
Following skills are indispensable to become a good software Tester.
Analytical Skills Technical skills Communication skills Attitude Productivity Passion
Analytical Skills:
A good software tester should have sharp analytical skills.Analytical skills will help break up a
complex software system into smaller units to gain a better understanding and create
corresponding test cases.
Technical skills:

A good software tester must have strong technical skills. It helps the testers to have a real
insight into the kinds of bugs that come into software and the likeliest place to find them. Also
Technical skills help in test Automation.
Communication skills:
A good software tester must have a good verbal and written communicationskills. It helps in
creation of Testing artifacts like test cases, test plans, test strategies, bug reports. Also in
communicating with developers, clients and management (Negotiation and Soft skills).
Attitude:
A good software tester should have a GREAT attitude.An attitude to Test to break, detail
orientation, willingness to learn, suggest process improvements, upgrade technical skills with
the changing technologies and work independently without much supervision.
Productivity:
A software tester must efficiently manage workload, have high productivity, exhibit optimal time
management and organization skills.
Passion:
A software tester must have a great degree of passion for Testing. The passion should be, to
make a career in testing but not just to treat it as a job.Only then one can excel in this
profession.
Previous
Building a career in Testing

4.1. Database Management System

Introduction
What is a data ? Any factual information in raw and disorganized form is called data.
What is a database? A database is a collection of related data organized in a way that data can be
easily accessed ,managed and updated.
Database Management System
A general-purpose Database Management System(DBMS) is a software system designed to allow
the definition, creation, querying, updating and administration of databases.
Well-known DBMS's include MySql,Oracle,Microsoft SQL server,Foxpro,SQLite, FileMaker Pro.
The primary goal of a Database Management System(DBMS) is to provide a way to store and
retrieve database information that is both convenient and efficient.
Traditional File Processing System A file system is a method of storing and organizing computer
files and the data they contain and to make it easy to find and access them.
Limitations of File processing System: 1. Separated and Isolated Data 2. Data Redundancy 3. Data
Dependence 4. Difficulty in representing data from the user's view 5. Inflexibility in retrieving the
Data 6. Data Security 7. Transactional Problems 8. Concurrency problems
Need of a Database Management System To overcome the limitations of the traditional file
processing system , the modern DBMS was created.
Functions of DBMS : 1. Minimal Data Redundancy 2. Data Consistency 3. Data Integration 4. Data
Sharing 5. Application Development Ease 6. Better Controls

7. Data Independence 8. Reduced Maintenance

Types of DBMS Commonly used databases are: A) Hierarchical Database B) Network model
database C) Object relational database D) Relational database Model
Hierarchical DBMS: 1. A DBMS is said to be hierarchical if the relationships among data in the
database are established in such a way that one data item is present as the subordinate of another
one or a sub unit. 2. The data structure "tree" is followed by the DBMS to structure the database.
Network Model DBMS: 1. A DBMS is said to be a Network DBMS if the relationships among data in
the database are of type many-to-many and appears in the form of a network. 2. Thus the structure
of a network database is extremely complicated because of these many-to-many relationships in
which one record can be used as a key of the entire database.

Object Oriented Relational Database :

1. Object Oriented DBMS add database functionality to object oriented programming languages. 2.
They bring much more than persistent storage of programming language objects. 3. As a result,
applications require less code, use more natural data modelling, and code bases are easier to
maintain.
Relational Database Management System:
1. A Data Base Management System that is based on a relational model is called as Relational
Database Management System. 2. Relational model is the most successfully used Data Base
Management System Model (DBMS)

model. 3. Relational model represents data in the form of tables. 4. Some popular examples are
Oracle, Microsoft SQL Server and Microsoft Access.
RDBMS terms
Relation: The Relation is a collection of related data entries and it consists of columns and rows.
Tuple: A tuple, also called a row of data, is each individual entry that exists in a table.
Fields: Every table is broken up into smaller entities called fields. A field is a column in a table
that is designed to maintain specific information about every record in the table.
Keys in DBMS Keys are used to establish and identify relation between tables
Super Key: A Super key is any combination of fields within a table that uniquely identifies each
record within that table.
Candidate Key: 1. A candidate is a subset of a super key. 2. A candidate key is a single field or the
least combination of fields that uniquely identifies each record in the table. 3. The least combination
of fields distinguishes a candidate key from a super key.

Primary key: 1. A primary key is a candidate key that is most appropriate to be the main reference
key for the table. 2. It is a key that uniquely identifies a record in a table.
Foreign key: 1. A foreign key is the field that generally references values from primary key field of
other table

4.2. Data Query Language

Introduction to SQL
Structured Query Language or SQL is a tool for organizing, managing, and retrieving data stored in
a computer database.
SQL Statements can be divided into following sub categories:
Data Definition Language (DDL)
Data Manipulation Language (DML)
Data Query Language (DQL)
Data Control Language (DCL)
Transaction Control Language (TCL)
Data Query Language : SELECT
The Data Query Language (DQL) is used to retrieve the data from one or more tables.
The SELECT statement is the only DQL statement.
Using SELECT statement the following operation can be performed
Projection : The operation results subset of columns
Selection : The operation results subset of rows
Projection means selecting set of columns from a table. In the below table, 3 columns marked with
yellow colour suggesting that those columns are selected.
Selection means selecting set of rows from a table. In the below table, 3 rows marked with yellow
colour suggesting that those rows are selected.

A Typical SELECT statement may consists of six clauses.

Syntax:
SELECT column_name [, column_list]
FROM table_name
[WHERE search_condition]
[GROUP BY grouping_column_name]
[HAVING aggregated_search_condition]
[ORDER BY sorting_column]
1. The SELECT and FROM clauses of the statement are mandatory. The remaining four clauses are
optional.
Consider the following table
SELECT Statement (Projection & Selection)

To display all records from table SELECT keyword with asterisk(*) is used:
The above query displays all the records from customer_details
To retrieve selected columns from the table, specific column names separated by commas(,) are
used
The above query displays only id, name and salary columns from customer_details

SELECT Statement (selection)

The where clause can be used to refine selection results by adding a search criteria.
Restricting Selection using comparison operators:
SELECT name, age FROM customer_details WHERE salary>50000;

The above query displays name and age of customers whose salary more than 50000 From
customer_details table
Restricting Selection using IN keyword:
SELECT name,location FROM customer_details WHERE location IN ('Kolkata','Delhi');
The above query displays name and location of customers who are from Kolkata and Delhi
Restrict based on pattern matching:
SELECT name,location FROM customer_details WHERE name LIKE '_a%';
The above query displays name and location of customers whose name's second character is a.
'_' identifies that one character can appear before 'a' and ' % ' identifies that any numbers of
character can appear after 'a'.
Restricting Selection using BETWEEN AND keyword:
SELECT name,location FROM customer_details WHERE age BETWEEN 20 AND 40;
The above query displays name and location of customers whose age ranging from 20 to 40
Restricting based on NULL value:
In Database terminology NULL is referred as value which is unspecified or unavailable
Based on database configuration, NULL value may not display anything but it should not be
misunderstood as zero or blank space.
Condition on NULL value can be given using the keyword IS.
SELECT name, age FROM customer_details WHERE location IS NULL;
The above query displays name and age of customers whose location not specified
SELECT name, age FROM customer_details WHERE age IS NOT NULL;
The above query displays name and age of customers whose age available
DISTINCT Keyword
To eliminate duplicate rows DISTINCT keyword is used in the SELECT statement.

The above query displays only the different age values.

ORDER BY Clause
ORDER BY clause in the SELECT statement is used to sort the results.
1. Name, age and salary of the customers displayed as per the ascending order of their salary.
2. DESC keyword can be used to display the list in descending order
GROUP BY Clause
The GROUP BY statement is used to group the result-set by one or more columns.
The above query displays number of customers present in particular age group.
Note: Group By Statements will be discussed in detail later
Concatenation Operator

The concatenation( || ) operator can be used to combine character strings and values from table.
The Name, age and the strings are displayed as single output columns
Column Alias
Column heading in the result set can be changed with Column aliases using the keyword AS.
1. The columns name and id are displayed as customer_name and customer_id in the result set.
2. Column headings in the table is unchanged.

4.3. Data Definition Language

DDL statements define the data structure such as tables, views etc.. that make up the database. All
DDL statements are auto committed means the changes will become permanent and database
objects created are available to all users.
Commonly used DDL statements are:
CREATE
ALTER
DROP
RENAME
TRUNCATE

Data Types
A data type identifies or classifies a particular type of information or data.
Some commonly used data types are:
CHAR (size) - Used to store character strings values of fixed length.
VARCHAR2 (size) Used to store variable length string data.
NUMBER (size, precision) Used to store numbers(fixed or floating point)
DATE Used to represent date and time.
LONG Used to store large variable length strings(upto 2GB).

DDL statement: CREATE

The CREATE keyword is used for creating database objects like tables, views, triggers, and indexes.
Syntax:
CREATE TABLE table_name
(
column_name1 DATATYPE(Size) ,
column_name2 DATATYPE(Size),
column_name3 DATATYPE(Size)
);
Ex: Create Table Employee
(

Emp_id number(4) NOT NULL,

Name varchar2(20) NOT NULL,
Salary number(8),
E_Mail varchar2(30),
Country varchar2(20),
);
Table created.
The above statement creates a table named Employee with columns Emp_id, Name,Salary,E_Mail
and Country.

DDL statement: ALTER

Alter statement is used to modify the structure of database or database objects like tables, views
etc..
Alter table statement - to add column to a table:
The above statement adds a new column 'age' of number data type with constraint not null.
Modifying the column:
Ex: ALTER TABLE Employee MODIFY salary number(10,2);
Table Altered.
Rename and Drop a Column:
Using the alter statement we can rename a column and also the drop any column.

The above statements renames the column name salary to em_sal and drops column age.

DDL statements: TRUNCATE, DROP, RENAME

Truncate Table:
Remove all the rows and resets schema of the table.
TRUNCATE TABLE Employee;
Drop table :
Deletes table entirely from the database.
DROP TABLE Employee;
Renaming a Table:
RENAME Employee to Emp_table;

4.4. Data Manipulation Language

Introduction
1. Data Manipulation Language(DML) is a structured query language which is used for inserting,
updating and deleting data in the database objects like table or view.
2. DML comprises the SQL change statements which modifies the stored data but not the database
object.
3. DML consist of three SQL statements namely Insert
Update
Delete

INSERT statement
Insert statement is used for inserting data into table.
Insertion of data can be done in multiple ways.

Syntax:
INSERT INTO table_name[(column1, column2,...)]
VALUES(value1, value2,....);
Ex:
If values in all the columns inserted in proper order, column names are not mandatory.
Syntax-:INSERT INTO table_name VALUES(value1, value2,....);
Ex:
Insertion can also be done in interactive way.
The records can be inserted in interactive manner also
Syntax:
INSERT INTO table_name VALUES(&value1, &value2, ..);
Ex:

UPDATE statement
Update command is used to change or modify data of one or more records in a table.

 All rows will be updated if no condition is specified in where clause.

Syntax:
UPDATE Table_name SET Column_name1=value1 [,Column_name2=value2,...]
[WHERE Condition];
Ex.

DELETE statement
1. Delete statement is used to remove one or more records from a table.
2. A subset may be defined for deletion using a condition, otherwise all records are removed.
Syntax:
DELETE FROM Table_Name
[WHERE Condition];
Delete statement using WHERE condition.
Ex:

Note: Delete statement without where condition deletes all the rows from table.
Example-

4.5. Transaction Control Language

Introduction to Transaction
Oracle server ensures data consistency based upon transactions.
Transactions consist of DML statements that make up one consistent change to the data.

Transaction Start and End Scenarios:

A Transaction begins when the first executable sql statement is encountered.
The Transaction terminates when the following specifications occur.
A COMMIT or ROLL BACK issued.
A DDL statement issued
A DCL statement issued

Failure of machine or system crashes

A DDL or DCL statement is automatically committed and hence implicitly ends a Transaction.

Explicit Transaction Control Statements

COMMIT
SAVEPOINT
ROLLBACK

COMMIT:
It ends the current Transaction by making all pending data changes permanent.
Syntax:COMMIT;
Once commit is issued, data changes will become permanent.
The previous state of the data is permanently lost.
All users can view the results of the recent transactional changes.
Ex: UPDATE employee SET salary =1000 WHERE emp_id = 10;
COMMIT;
SAVEPOINT:
It marks a savepoint with in the current Transaction.
We can create multiple savepoints in single Transaction.
Savepoints can be used to control the reverting of changes.
Syntax:SAVEPOINT <NAME>;
Ex: SAVEPOINT S1;
ROLLBACK:
It ends the current Transaction by discarding all pending data changes.
The data changes are undone.
The previous state of data is restored.
The locks on the affected rows are automatically released.
Syntax: ROLLBACK or ROLLBACK to <SAVEPOINT NAME>;
Ex: UPDATE employee SET salary =1000 WHERE emp_id = 10;
ROLLBACK;
using savepoint the Transaction can be discarded up to the marker by using rollback statement.

Ex: INSERT INTO employee VALUES(10,'JHON',3000);

INSERT INTO employee VALUES(10,'KELLY',2000);
SAVEPOINT S1;
INSERT INTO employee VALUES(10,'WILSON',4000);
ROLLBACK TO S1;

4.6. Single Row Functions in SQL

Introduction to Oracle Built-in Functions
Oracle Built-in Functions are the functions supplied by Oracle that can be used to manipulate data
items and return a result.
There are two types of Built-in functions available in Oracle.
Single Row Functions: Single row or Scalar functions return a value for every row that is
processed.
Group Functions: These functions group the rows of data based on the values returned by the
query, performs the aggregate function(sum,avg etc.) on each group and return one value per group
of rows.
Single Row Functions
Single row or Scalar functions return a value for every row that is processed .
There are four different types of single row functions1)Conversion Functions: These are functions that help us to convert a value in one form to another
form. For Example: a null value into an actual value, or a value from one data type to another data
type like NVL,TO_CHAR, TO_NUMBER, TO_DATE etc...
2)Character or Text Functions: These are functions that accept character input and can return
both character and number values.
3)Numeric Functions: These are functions that accept numeric input and return numeric values.
4)Date Functions: These are functions that take values that are of data type DATE as input and
return values of data type DATE, except for the MONTHS_BETWEEN function, which returns a
number.
Consider the following table Employee:

Conversion Functions
NVL
NVL2
NULLIF
NVL: let us replace null with a string in the results of a query .
Syntax : NVL( string1, replace_with).
If string1 is null, then NVL returns replace_with .
If string1 is not null, then NVL returns string1.
Ex: SELECT NVL(emp_name,'NA') FROM Employee;
The above query will display 'NA' wherever emp_name is null.
We can also replace with another column.
Ex: SELECT NVL(emp_name,dep_name) FROM Employee;
The emp_name and dep_name should belongs to same data type family.
The above query will display dep_name wherever emp_name is NULL.
Ex: SELECT NVL(salary,0) FROM Employee;
The above query returns 0 only if the salary is defined as NUMBER and is NULL.
NVL2: NVL2 function extends the functionality found in the NVL Function.
It lets you substitutes a value when a null value is encountered as well as when a non-null value is
encountered.
Syntax : NVL2(string1,value_if_not_null,value_if_null)
if string1 is not null then NVL2 returns value_if_not_null.
if string1 is null then NVL2 returns value_if_null.
Ex: SELECT NVL2(emp_name,dep_name,'NOT AVAILABLE') FROM Employee;
NULLIF: NULLIF compares expr1 and expr2. If they are equal, then the function returns null. If they
are not equal, then the function returns expr1 .

Syntax : NULLIF(expr1,expr2)
Ex: SELECT NULLIF( dep_name,'HR') FROM Employee;
The above query returns NULL if dep_name field consists of 'HR', otherwise it returns job.
You cannot specify the literal NULL for expr1.
Character Functions
There are two types of character functions.
Character to character functions accept string as input and will give string as output.
INITCAP
LOWER
UPPER
CONCAT
LPAD,RPAD
TRIM
SUBSTR
REPLACE
Character to number functions accept string as input and will give number as output.
LENGTH
INSTR
INITCAP: This function sets the first character in each word to upper case and the rest to lower
case.
Syntax : INITCAP(expr1)
Ex: SELECT INITCAP(emp_name) FROM Employee:
Amit
Ajay
Sima
Dipa
Anuj
The above query returns all the employee names with the first letter in upper case and rest other
characters in lower case.

LOWER: This function converts all letters in the specified string to lower case. If there are
characters in the string that are not letters, they are unaffected by this function.
Syntax : LOWER(expr1)
Ex: SELECT LOWER (emp_name) FROM employee:
amit
ajay
sima
dipa
anuj
The above query returns all the characters of the employee name in lower case.
UPPER:This function converts all letters in the specified string to uppercase. If there are characters
in the string that are not letters, they are unaffected by this function.
Syntax : UPPER(expr1)
Ex: SELECT UPPER (emp_name) FROM Employee:
AMIT
AJAY
SIMA
DIPA
ANUJ
The above query returns all the characters of the employee name in upper case.
CONCAT: This function allows you to concatenate two strings together.
Syntax : CONCAT(expr1,expr2)
Ex: SELECT CONCAT(emp_name,dep_name) full_name FROM Employee;
The above query returns the emp_name & dep_name concatenated into a single string.
SUBSTR: Returns specified characters from a string, starting from specific position to required
characters length.
Syntax : SUBSTR(col/expr,m,n)
If 'm' is positive,oracle counts from beginning of string, If it is negative Oracle counts from the end of
string.

If 'n' is omitted, Oracle returns all characters to end of the string starting from m.
Ex: SELECT SUBSTR(emp_name,3,2) FROM Employee.
The above query starts searching from the third position of the employee name from the starting of
the string and displays two characters from there.
Ex: SELECT SUBSTR('abcdefg'-4,2) FROM dual;
dc
The above query starts searching from the fourth position of the given string from the end of the
string and display two characters from there.
REPLACE: It returns the every occurrence of search_string replaced by the replacement_string.
If the replacement string is omitted or null all occurrences of search string will be removed.
Syntax : REPLACE(string,search_string,replace_string)
Ex: SELECT REPLACE(branch_name,'Mumbai','Kolkata') FROM Employee WHERE dep_name =
'HR';
The above query replaces branch name to 'Kolkata' wherever 'Mumbai' is available for the HR
department .
LPAD,RPAD:
LPAD pads the character value right justified to a total width of n character positions.
Syntax : LPAD(expr1,padded_length,padded_string)
RPAD pads the character value left justified to a total width of n character positions.
Syntax : RPAD(expr1,padded_length,padded_string)
The default padding character is space.
Ex: SELECT LPAD('jhon',8) FROM dual;
jhon
Since the third parameter is not specified in the result of the above query will be by default space
padded for the previous four positions.
Ex2: SELECT LPAD('jhon',8 ,'x') FROM dual;
xxxxjhon
The above query fills the four blank spaces with 'x' left of the given string.
Ex3: SELECT RPAD('jhon',8 ,'x') FROM dual;
jhonxxxx

The above query fills the four blank spaces with 'x' right of the given string.
TRIM: It enables to trim leading or trailing characters or both from a string.
If we dont specify anything, it will trim spaces.
Syntax : TRIM( [LEADING | TRAILING | BOTH] character FROM string)
LTRIM : Removes the leading characters
RTRIM : Removes the trailing characters
TRIM : Removes both
Ex: SELECT RTRIM('s' from 'ssmithss') FROM dual;
ssmith
The above query removes 'trailing' 's' from the given string.
Ex: SELECT LTRIM('s' from 'ssmithss') FROM dual;
mithss
The above query removes 'leading' 's' from the given string.
Ex: SELECT TRIM('s' from 'ssmiths') FROM dual;
mith
The above query removes 'trailing' & 'leading' 's' from the given string.
Ex: SELECT TRIM(' smith ') FROM dual;
Smith
The above query removes 'trailing' & 'leading' spaces from the given string.
INSTR: This function returns the location of a sub string in a given string.
Syntax : INSTR( string, sub_string [, start_position [, nth_appearance ] ] ).
start_position and nth_appearance are optional. If not specified, always INSTR starts with first
position and will give first appearance.
Ex: SELECT INSTR('internet','e') FROM dual;
4
The above query returns the first position of 'e' searched from the start of the given string.
Ex: SELECT INSTR('internet','e',1,2) FROM dual;
7
The above query returns the second position of 'e' searched from the start of the given string.

Ex: SELECT INSTR('internet','e',5,1) FROM dual;

3
The above query returns the first position of 'e' searched from the fifth position of the given string.
LENGTH: Returns number of characters in a value.
Syntax : LENGTH(column)
Ex: SELECT LENGTH(branch_name) FROM Employee;
The above query returns number characters in the branch_name field for each and every record.
Ex: SELECT LENGTH('jhon') FROM dual;
4
The above query returns the number of characters from the given string.
Numeric Functions
1. Numeric functions are used to perform operations on numbers.
2. They accept numeric values as input and return numeric values as output.
3. Following are the few examples of Numeric functions available in Oracle.
a. ABS and MOD
b. POW and SQRT
c. FLOOR and CEIL
d. TRUNC and ROUND
Dual table
1. This is a single row and single column dummy table provided by oracle. This is used to perform
mathematical calculations without using a table.
2. Oracle presents the output of every operations in a tabular format so that it seems to the user that
the output comes from a table
ABS and MOD Function

The ABS function returns the absolute value of the parameter passed.
Syntax : ABS(number)
Ex: SELECT ABS(-10) FROM dual;
10
The above query returns the absolute value of the given 'number'.
The MOD function returns the remainder value of the parameter passed.
Syntax : MOD(number1,number2)
Ex: SELECT MOD(10,4) FROM dual;
2
The above query returns the remainder when 10 is divided by 4.
POWER and SQRT Function
POWER function returns the argument raised to the specified power.
Syntax : POWER(number1,number2)
Ex: SELECT POWER(4,3) As Cube FROM dual;
64
The above query returns the output when 4 is raised to the power of 3.
SQRT function returns the square root of a number passed as parameter.
Syntax: SQRT(number)
Ex: SELECT SQRT(64) As Square Root FROM dual;
8
The above query returns the square root value of 64.
FLOOR and CEIL Function
The FLOOR function returns the largest integer less than or equal to the value
passed in parameter.
Syntax: FLOOR(decimal number)
Ex: SELECT FLOOR(7.14), FLOOR(7.84) FROM dual;
77

The above query returns the largest integer nearest to 7.14 & 7.84.
Ex: SELECT FLOOR(-7.14) FROM dual;
-8
The above query returns the largest integer nearest to -7.14.
The CEIL function returns the smallest integer greater than or equal to the value
mentioned in parameter.
Syntax: CEIL(decimal number)
Ex: SELECT CEIL(7.14), CEIL(7.84) FROM dual;
88
The above query returns the smallest integer nearest to 7.14 & 7.84.
Ex: SELECT CEIL(-7.14) FROM dual;
-7
The above query returns the smallest integer nearest to -7.14.
TRUNC and ROUND Function
1) The TRUNC function truncates the value present in the column, expression up to decimal places
mentioned in first parameter.
2) If the second argument is 0 or is missing, the value is truncated to zero decimal places.
Syntax: TRUNC(decimal number,number of places)
Ex: SELECT TRUNC(137.5738,3) As Rounded FROM dual;
137.573
The above query returns the decimal number with three digits after the decimal point.
Ex: SELECT TRUNC(137.5738,0) As Rounded FROM dual;
137
The above query returns the integer value.
The ROUND function round off the value present in the column, expression up to decimal places
mentioned in first parameter.
If the second argument is 0 or is missing, the value is rounded to zero decimal places.
Syntax: ROUND(decimal number,number of places)

Ex: SELECT ROUND(137.5738,3) As Rounded FROM dual;

137.574
The above query returns the decimal number with three digits after the decimal point where 4th digit
is rounded.
SQL> SELECT ROUND(137.5738,0) As Rounded FROM dual;
138
The above query returns the integer value rounded to the next highest value.
If the second argument is negative number, the value is rounded up specified decimal places to the
left (rounded to the nearest unit of 10).
Ex: SELECT ROUND(137.5748,-1) As Rounded FROM dual;
140
The above query returns the integer value which is the nearest tens value.
Ex: SELECT ROUND(137.5748,-2) As Rounded FROM DUAL;
100
The above query returns the integer value which is the nearest hundreds value.

4.7. Aggregate / Group Functions

Group Functions, as the name suggests, are functions that operate on groups(sets) of values and
returns one result per group.
Group function returns a single result row for every group of queried rows.
Based on the query statement it may return single or multiple rows.

The functions that are used as Aggregate Functions are:

SUM
AVG
MAX
MIN
COUNT
Consider the following table: Employee

AVG: Returns an average value, ignoring null values.

Syntax: AVG([DISTINCT] column_name)
Ex: SELECT AVG(salary) as Average Salary FROM Employee;
21500
The above query displays the average salary of all the employees in the table Employee
MAX: Returns the maximum value, ignoring null values.
Syntax: MAX([DISTINCT] column_name)
Ex: SELECT MAX(salary) as Maximum Salary FROM Employee where Dep_Name='HR';
16000
The above query displays the maximum salary of all the employees in HR Department in the table
Employee.
MIN: Returns the minimum value, ignoring null values.
Syntax: MIN([DISTINCT] column_name)
Ex: SELECT MIN(salary) as Minimum Salary FROM Employee where Dep_Name='HR';
10000
The above query displays the minimum salary of all the employees in HR Department in the table
Employee.
COUNT: Returns the count of not null values ignoring null values.
Syntax: COUNT([DISTINCT] column_name)
Ex: SELECT COUNT(DISTINCT Dep_name) Departments FROM Employee;
3
The above query displays the count of different departments in the table Employee.
COUNT:(*) Count function with asterisk returns the count of total number of rows including null
values

Syntax: COUNT(*)
Ex: SELECT COUNT(*) FROM Employee;
5
The above query displays the total number of rows in table Employee.

GROUP BY clause
Creates a data set, containing several sets of records grouped together based on a condition.
Syntax: SELECT <columnName1>[,<columnName2>], AGGREGATE
FUNCTION(<expression>) FROM Table_Name GROUP BY <columnName1>[,<columName2>] ;
Ex: SELECT dep_name,COUNT(emp_id) "No of Employee" FROM Employee GROUP BY
dep_name;
HR 2
Marketing 2
Admin 1
The above query displays the number of employee in each department.

WHERE clause
Used to apply a filter condition before the Grouping the rows.
Syntax: SELECT <columnName1>[,<columnName2>], AGGREGATE
FUNCTION(<expression>) FROM Table_Name WHERE <condition_before_grouping_rows>
GROUP BY <columnName1>[,<columName2>] ;
Ex: SELECT Dep_Name,COUNT(Salary) FROM Employee WHERE Salary>15000 GROUP BY
Dep_Name;
HR 1
Marketing 1
Admin 1
The above query displays department wise count of salary more than 15000.

HAVING clause
Used to apply a filter condition on Aggregate values.
Syntax: SELECT <columnName1>[,<columnName2>], AGGREGATE
FUNCTION(<expression>) FROM Table_Name WHERE <condition_before_grouping_rows>
GROUP BY <columnName1>[,<columName2>] HAVING <condition_on_grouped_result>;

Ex: SELECT Dep_Name, SUM(Salary) FROM Employee WHERE Salary>12000

GROUP BY Dep_Name HAVING SUM(Salary)<30000;
HR 16000
Marketing 20000
The above query displays the departments for which total salary is less 30000 excluding the Admin
department, total salary for which is 40000.

5.1. Categories of Testing

Testing is broadly categorised into two namely Static and Dynamic Testing. Dynamic Testing is
again categorised into Black Box and White Box Testing.
Static Testing
Static Testing is testing of software work products either manually or by usage of tools. In this case,
the work products are not executed. It starts early in the life cycle and is a part of verification
process. It does not require a computer as there will not be execution of the software work products.
The following are the static testing techniques
Reviews
Walkthroughs
Inspections
Of the above mentioned techniques, Peer reviews and Walkthroughs are informal reviews whereas
Inspection is a formal review process.
Formal Technical Review Objectives
Uncover errors in function, logic, or implementation for any representation of the software
Verify that the software under review meets its requirements

 Ensure that the software has been represented according to predefined standards
Achieve software that is developed in a uniform manner
Make projects more manageable
Serve as a training ground, enabling junior engineers to observe different approaches to software
analysis, design, and implementation
Serves to promote backup and continuity because a number of people become familiar with parts
of the software that they may not have otherwise seen

Formal Technical Reviews

Involves 3 to 5 people (including reviewers)
Advance preparation (no more than 2 hours per person) required
Duration of review meeting should be less than 2 hours
Focus of review (walkthrough or inspection) is on a discrete work product
Review leader organizes the review meeting at the producer's request
Reviewers ask questions that enable the producer to discover his or her own error (the product is
under review not the producer)
Producer of the work product walks the reviewers through the product
Recorder writes down any significant issues raised during the review
Reviewers decide to accept or reject the work product and whether to require additional reviews of
product or not
Formal Technical Review Guidelines
1. Review the product not the producer.
2. Set an agenda and maintain it.
3. Limit rebuttal and debate.
4. Enunciate problem area, but dont attempt to solve every problem noted.
5. Take written notes.
6. Limit number of participants and insist on advance preparation.
7. Develop a checklist for each product that is likely to be reviewed.
8. Allocate resources and schedule time for all reviewers.
9. Conduct meaningful training for all reviewers.
10. Review your early reviews,
In a recap of above techniques ,
Informal - Peer Review:

 Peer Reviews are documented and uses a defect detection process that has peers and technical
specialist as part of the review process.
The Review process does not involve management participation.
It is usually led by trained moderator who is NOT the author.
The report is prepared with the list of issues that needs to be addressed.

Informal - Walkthrough:
It is not a formal process. It is led by the authors.
Author guides the participants through the document according to his or her thought process to
achieve a common understanding and to gather feedback.
Useful for the people if they are not from the software discipline, who are not used to or cannot
easily understand software development process.
Especially useful for higher level documents like requirement specification, etc.
Formal Inspection:
It is the most formal review type. It is led by the trained moderators.
During inspection the documents are prepared and checked thoroughly by the reviewers before the
meeting.
A separate preparation is carried out during which the product is examined and the defects are
found.
The defects found are documented in a logging list or issue log.
A formal follow-up is carried out by the moderator applying exit criteria.
External reference - http://www.cs.toronto.edu/~sme/CSC444F/slides/L09-Inspections.pdf
Dynamic Testing
Testing the software by dynamically executing the application is termed as dynamic testing. Dynamic
testing is a method of assessing the feasibility of a software program by giving input and examining
output (I/O). The dynamic method requires the code be compiled and run. It comes under the
validation.
Dynamic Testing Consists of Two Types:
1) White-Box testing
2) Black-Box testing

White Box Testing

White Box testing can be outlined as below.

Testing that takes into account the internal mechanism of a system or component.
Checks out the paths and statements, branches that are executed
Requires knowledge of the internal code.
For example, Unit testing can be termed as a White box testing where in the developer would test
the paths, branches that are part of code is conforming to the functionality the program is supposed
to do.
Key Note: White box tests can be designed only after Component level design ( source code ) is
available. The logical details of the program must be available
White-Box Testing Questions
The following questions need to be asked by testers to themselves before designing the white box
test cases.
Can it be guaranteed that all independent paths within a module will be executed at least once?
Can all logical decisions be exercised on their true and false branches?
Will all loops execute at their boundaries and within their operational bounds?
Can internal data structures be exercised to ensure their validity?

Black Box Testing

Black box testing is the testing that ignores the internal mechanism of a system or component and
focuses solely on the outputs generated in response to the selected inputs and execution conditions.
It is conducted to evaluate the compliance of a system or component with specified functional
requirements. Requirements are the only test basis and knowledge of the internal code is not
required.
Some of the Black box testing types:
Integration Testing
System Testing
Acceptance Testing
These testing levels will be detailed later in the course.
Black-Box Testing Questions
Following would be some of the questions that a black box tester to consider before designing the
test cases.
How is functional validity tested?

 How is system behavior and performance tested?

What classes of input will make good test cases?
Is the system particularly sensitive to certain input values?
How are the boundaries of a data class isolated?
What data rates and data volume can the system tolerate?
What effect will specific combinations of data have on system operation?

5.2. Testing Techniques

What is Testing technique
Testing technique is a procedure for selecting or designing tests. It is based on the functional or
structural model of the software. The techniques have a high success rate of finding faults. It is a
way of deriving the test cases which also helps in measuring the testing effort quantitatively.
Why to use Testing Techniques
To ease the development of test cases, we use different testing techniques that have evolved as per
different business scenarios. The reason why testing techniques are used is because there would be
large number of test scenarios and finite time which would make it impossible to test.
Hence the usage of software testing techniques reduce the number of tests to be run whilst
providing the sufficient coverage of system under test.
Categories of Testing Techniques
There are two types of test design techniques:
Black Box techniques
White Box techniques

Black Box Testing Techniques

In black box testing, the inner structure and design of the test object is unknown or not considered.
The test cases are derived from the specification, or they are already available as part of the
specification (specification by example). Black boxtechniques are also called specification based
because they are based on specifications (of requirements). A test with all possible input data
combinations would be a complete test, but this is unrealistic due to the enormous number of
combinations. During test design, a reasonable subset of all possible test cases must be selected.
There are several methods to do that, and they will be shown in the following sections.
Equivalence partitioning technique
Equivalence partitioning technique is to partitioning the input domain of a program into a finite
number of classes [sets], to identify a minimal set of well selected test cases to represent these
classes.

There are two types of input equivalence classes, valid and invalid.
Equivalence class technique can significantly reduce the number of test cases that must be created
and executed
Illustration for EP
EP may be best explained with an example of a function which has the pass parameter "month" of a
date. The valid range for the month is 1 to 12, standing for January to December. This valid range is
called a partition. In this example there are two further partitions of invalid ranges.
The first invalid partition would be <= 0 and the second
invalid partition would be >= 13.
Boundary Value Analysis technique
A selection technique in which test data are chosen to lie along "boundaries of the input domain [or
output range] classes, data structures, procedure parameters is known as Boundary Value Analysis
Technique.
Choices often include maximum, minimum, and trivial Values .This technique mainly focus on the
boundaries of the input.
Illustration for BVA
If the same example of a function which has the pass parameter "month" of a date
Valid Class is 1<= month <=12
Invalid Class 1 is month <1
Invalid Class 2 is month >12
When compared to EP, which says select any test case within a range and any on either side of it ,
in BVA the emphasis is on the edges.
1 and 12 for the edges of the Valid class
0 and 13 for the Invalid class
White Box Testing Techniques
Statement coverage technique
It is a technique to satisfy the criterion that eachstatement in a program to be executed at least
onceduring program testing. Coverage is 100 percentage whena set of test cases causes every
program statement to beexecuted at least once.

The chief disadvantage of statement coverage is that it isinsensitive to some control structures.
Example
1 int select ( int a[], int n, int x) 2 { 3 int i = 0; 4 while ( i < n && a[i] < x ) 5 { 6 if (a[i] < 0) 7 a[i] = - a[i];
8 i++; 9 } 10 return 1; 11 }
One test case n=1, a[0]=-7, x=9 covers everything ,
Flow 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 7 - > 8 - > 9 - > 10 - > 11
Branch Coverage technique
In Branch Coverage Technique execution of decisions is considered rather than execution of each
statement. The result of decisions determines which statement will be executed next.
Test every Decision Output both Then and Else part of IF, all possibilities for a CASE statement,
loops i.e execution of the loop body, bypassing of the loop body and return to the beginning of the
loop. Example:
1 int select ( int a[], int n, int x) 2 { 3 int i = 0; 4 while ( i < n && a[i] < x ) 5 { 6 if (a[i] < 0) 7 a[i] = - a[i];
8 i++; 9 } 10 return 1; 11 }
Test Data:

Flow A : 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 7 - > 8 - > 9 - > 10 - > 11
Flow B : 1 - > 2 - > 3 - > 4 - > 10 - > 11
Multiple Condition Coverage technique
A test coverage criteria which requires enough test cases such that all possible combinations of
condition outcomes in each decision, and all points of entry, are invoked at least once.
A large number of test cases may be required for full multiple condition coverage.
Example:
1 int select ( int a[], int n, int x) 2 { 3 int i = 0; 4 while ( i < n && a[i] < x ) 5 { 6 if (a[i] < 0) 7 a[i] = - a[i];
8 i++; 9 } 10 return 1; 11 }
Test Data:

Loop Coverage technique

A test coverage criteria which checks whether loop body executed zero times, exactly once or more
than once.
Example:
main ( ) {
int i, n, a[10],x; printf (Enter the values); scanf (%d %d %d %d, &i, &n, &a[i], &x); while ( i < n &&
a[i] < x ) { if (a[i] < 0) a[i] = - a[i]; i++; }printf (%d , a[i] ); }
Test Data:

Call Coverage technique

A test coverage criteria which checks whether function called zero times, exactly once or more than
once. Since probability of failure is more in function calls, each function call is executed.
Example:
main ( ) {int a, b, i ; printf (Enter the value of a, b, i); scanf ( %d %d %d , &a ,&b, &i); if ( i < 10 )
{sample ( a, b); i = i + 1; }}sample ( int x , int y ) {If ( x > 10 ) x = x + y ; break ; if ( y > 10 ) y = y + x ;
break ; }
Test Data:

Path Coverage technique

Testing to satisfy coverage criteria that each logical path through the program be tested. Often paths
through the program are grouped into a finite set of classes. One path from each class is then tested
General coverage requires executing all paths, number of paths may be infinite if there are loops
Example:
Linear Independent Paths
Path 1 -> p1 d1 d2 p4 Path 2 -> p1 d1 p2 p4 Path 3 -> p1 d1 d2 p3 p4

Sample Program:
1 sample ( int x , int y )
{ 2 If ( x > 10 ) 3 x = x + y ; break ; 4 if ( y > 10 ) 5 y = y + x ; break ; } 6 printf (%d %d, x , y);

Go to Doubts

6.1. Test Scenario

Test design is the crucial phase in the software testing process. It includes writing of test
scenarios and test cases.
Test scenario is a high level test condition. Set of test cases that ensure that the business
process flows are tested from end to end is defined as Test Scenario.
Test scenarios are derived from requirement documents or use cases. Test Scenario directly
verifies a functional/business need without getting too much granular level of testing. It can be
further broken down into many test cases. Each test scenario depend on output of the previous
one. Each level of testing has its corresponding test scenarios. Test scenarios ensure that all
process flows are tested from End to End.
Points to remember while writing Test Scenarios:
A good practice is to add both positive and negative test scenarios
Each scenario should be specific to a functional behavior
Do not club scenarios together.

Components of Test Scenario:

Requirement ID.
Test Scenario ID.
Test Scenario Name
Purpose

Assumptions
Module Name
Priority
Prerequisite.
Expected Result.

Test Scenario Template

Scenarios and Test Cases

Assurance - All Chapters
Go to Doubts

6.2. Test case

Test case is the smallest unit of Testing. It is a detailed procedure that fully tests a feature or an
aspect of feature. A test case has components that describes an input, action or event and an
expected response, to determine if a feature of an application is working correctly.
A test case is a set of conditions or variables under which a tester will determine whether an
application, software system or one of its features is working as it was originally established for
it to do.
Test cases are written to keep track of testing coverage of Software. Test cases are usually
derived from test scenario
IEEE Standard 610 defines test case as follows:
A set of test inputs, execution conditions, and expected results developed for a
particular objective, such as to exercise a particular program path or to verify compliance with a
specific requirement.
IEEE Standard 829 defines test case as follows:
Documentation specifying inputs, predicted results, and a set of execution conditions for a test
item.
Objective and Importance of Test Case.
The most extensive effort in preparing to test a software, is writing test cases
It Improves productivity during test execution by reducing the Understanding time during test

execution.

Test cases should cover valid, invalid, expected and unexpected conditions.
Writing effective test cases is a skill
It requires in-depth study of the application
Breaking down the Test Requirements into Test Scenarios and Test Cases would help the

testers avoid missing out certain test conditions

Components of Test Case:
Test Case ID.
Test Case Description
Module
Priority
Purpose
Assumptions
Prerequisite
Test Scenario ID
Test Step
Test Step Description.
Test Data
Expected Result
Actual Result
Status.

Chapter 6: Test Scenarios and Test

Cases
Assurance - All Chapters
Home
See Leaderboard

Go to Doubts

6.3. Description of Test case components

Test Case ID: A Unique Test case identification number.
Test Case Name: Summary of the test case.
Test Case Description: A brief description of the test case.
Module: Function or the Module which is impacted with the test case.
Priority: Describes the priority of the test case in order of complexity and execution. Defined

by the values High, Medium & Low.

Purpose: The intention of the Test case.
Assumptions: Assumptions if any to be included in this field.
Prerequisite: Any pre-condition that need to be satisfied for executing the test case to be

specified in this field. Example, availability of Environment & application under test, test data
appropriate to execute the test case etc.
Test Scenario ID: ID of the Scenario to which test case belongs to be provided.
Test Step: Test Step Number. Usually starts from Step 1, Step 2, Step 3 and so on.
Test Step Description: Each and every action that has to be performed to execute the test

case. Nothing but execution instruction.

Test Data: The data required for execution of the test step.
Expected Result: The expected output has to be specified in this field. Usually derived from
requirements.
Actual Result: The actual output observed while execution to be captured in this field.
Status: Status defined as Pass, Fail, Block, In progress, Not Applicable to be provided over
here.
CC India
Campus Commune
My Channels

Chapter 6: Test Scenarios and Test

Cases
Assurance - All Chapters
Home
See Leaderboard

Go to Doubts

6.4. Classification of Test Scenario and Test Case

Priority:
Test Scenarios and Cases are categorized as High, Medium & Low Priority based on the
complexity and usage of the functionality in production.
Priority is a mandatory component for Test Case and Test Scenario. It is an important field to be
captured as it helps to decide whether to give a sign-off for the product during crisis.

Previous
Description of Test case components
Next
Test Step

6: Test Scenarios and Test Cases

Assurance - All Chapters
Home
See Leaderboard

Go to Doubts

6.5. Test Step

Detailed description of Test case is a Test step. Its a mandatory component of Test case. Test
case is incomplete without a step. Each and every action that a user has to perform while
execution of a test case is a test step.
A Test case decomposes into test steps. Test step provides detailed description about test
cases, means how to perform that test case. Test step may contain either condition or execution
instructions.

Home
See Leaderboard

Go to Doubts

6.6. Test Case example

Example 1:
Rental Car Application
1. Validate that a Rental can occur.
1.1 Check Customer policy coverage
1.2 Query Car availability
1.3 Query Car rates
1.4 Open a Rental ticket
1.4.1 Validate that a customer record can be entered
1.4.2 Validate that credit card approval is obtained
1.4.3 Validate that status on the car record is changed from waiting to rented
2. Billing Function

3. Reservation Function
Lets look at the lower levels for the below one
1.4.1 Validate that a customer record can be entered
Understanding functionalities
Example: Rental Car Application
1. Validate that a Rental can occur.
1.4 Open a Rental ticket
1.4.1 Validate that a customer record can be entered
1.4.1.1 Validate that a new customer can be added to the customer table
1.4.1.1.1 Validate that the first name is all alpha
1.4.1.1.2 Validate that the age is > 21.
1.4.1.1.3 Validate that the phone number is Numeric
1.4.1.1.4 Validate area code is an existing area code number.
1.4.1.2 Validate changing an existing customer
In the above example Validate that a Rental can occur is a Business/functional Requirement.
From the business requirements, scenarios which are high level testable conditions are derived.
In this example Validate that a new customer can be added to the customer table is a
Scenario.
We have multiple conditions to be checked under this scenario like Validate that the phone
number is numeric which is nothing but a test case.
Example 2:
Consider the following set of requirements as an example:
Requirements for calculating Car Insurance Premiums:
R00101 For females less than 65 years of age, the premium is $500
R00102 For males less than 25 years of age, the premium is $3000
R00103 For males between 25 and 64 years of age, the premium is $1000
R00104 For anyone 65 years of age or more, the premium is $1500

Example: Causes & Effect

Previous
Test Step
Next
Effective way of writing Test cases

Test Scenarios and Test Cases

Assurance - All Chapters
Home
See Leaderboard

Go to Doubts

6.7. Effective way of writing Test cases

Points to be noted while writing Test cases:
Document sign off Requirements / Design / Use case document should be signed off
before starting with test case writing.
Keep test case simple Test Cases should be written in simple plain language without any
ambiguous or complicated statements.
Detail test cases Test Cases should be in detail and no generic statements should be

included. Which field has to be verified for what value has to be explained clearly.
Embed Test Data: Test Data to be used for each of the Test Step should be provided.
Track Test Case changes: Maintain Test Case history to capture changes made to Test

Cases
Others will execute your test cases: Test cases should be written presuming others will

execute them and hence test cases have to be detailed.

Test Case Naming Convention: Name Test Cases that will identify objective.

Example: TC_Login_REQ1_3. In this Test Case name, Login page is being tested and
requirements Req-01 and Req-03 are being covered.
100% Requirement Coverage is a must: Check and ensure 100% requirement coverage
and track the requirements covered. Test cases written should be tracked with a Requirements
traceability matrix.
Reusable Test Steps: Common and repeated Test Steps can be made as reusable and can

be called in other Test Cases.

Example Login, Logout and other common Test Steps can be made as reusable Test Steps and
can be called in other Test Cases.
Test Case review is a must: Ensure that all the test cases are reviewed by required stake
holders (peer reviewed or SME reviewed or client review)
Language Usage: Use Simple and Easy-to-Understand language and use Active voice while
writing test cases
Example:
o Click on OK button
o Navigate to the account Summary page.
Verify word Must: Use words like Verify for starting any sentence in Test Case description

Example:
Verify whether the account information gets displayed on clicking the
Account Summary menu
Future Tense Words for Expected Result: Use always words like Should and Must for
Expected Results.
Example:
o The application should display the account information screen

Scenarios and Test Cases

Assurance - All Chapters
Home
See Leaderboard

Go to Doubts

6.8. Requirement Traceability

Requirements in software can be defined as a group of conditions or needs which customer
expects the application to meet.
Requirements must be documented, measurable, testable, which covers all the business
needs.

Let's consider an example, If a client says that they want a system to acquire feedback from

their customers then this can be termed as their requirement which requires efforts from
technical team to convert the requirement into the application like feedback portal.
Requirement can be classified into two broad categories
Functional Requirements: These requirements are the desired functionality that the client

want us to build and delivered to them.

Non Functional Requirements: It can be described as a constraint on the system like
performance, security, reliability, accuracy, availability etc.
Requirement Analysis
Requirement analysis plays a key role in the success of any project.
This is process of discovering, analyzing, defining and documenting the requirements.
Involves measuring each and every functional requirement, non-functional requirement and

operational requirements.
Requirement analysis involves regular interaction with the client to determine their

expectations.
Analysis includes providing visual representations such as screen layouts, UML diagrams etc
for defining the boundaries of the system.
It clearly defines the in scope and out of scope of the system and helps in communicating the

end result to the stakeholders.

Domain Understanding - Understanding of application domain.
Requirement collections - The process of interacting with customers to discover the

requirements for the system.

Requirements classification - Group and classify the gathered requirements.
Conflict resolution Resolve the conflict requirements.
Prioritization Identify and list requirements according to their importance.
Requirements validation Check and validate the gathered requirements to see if they are

complete, correct, and sound.

Importance of Requirement Analysis
Lack of requirement analysis phase leads to inconsistencies in the final product. Let's checkout
the possible mistakes.

During requirement gathering, If the client is not able to provide the exact details that is

required, this will leads to a rework by the development team.

Communication gap between the teams and the customer. If there is no regular interaction
between the client and the teams involved in requirement analysis, then there is a possibility of
conflict in later phases of development. This might affect the deadlines of the project as well.
Towards the end of the project development, the client want to introduce more new features
which were not part of earlier requirements. This is also one of the reason which pushes the
team back on their schedule.
Improper documentation also enhances the possibility of unachievable tasks.
Traceability Matrix
TraceabiltyMatrix defines the mapping between customer requirements and the designed test
cases.
This is used by the testing team to verify whether the test cases prepared have covered all
the requirements to be tested.
The traceability matrix is a document, which is in the form of a table that correlates between
the requirements and the test cases.
Traceability Matrix has the following important fields, - Requirement ID/Name - Test Case
name - Name of the Tester - Defects Associated(if any)
Sample Requirements Traceability Matrix

Benefits of Traceability Matrix

Using traceability matrix, we can verify whether all the test cases for the requirements are
covered or not.
This also helps to assure that all the customer requirements have been met.

Chapter 7: Defect Management

Assurance - All Chapters
Home
See Leaderboard

7.1. Test Execution Workflow

Next
What is a defect?

Home
See Leaderboard

Go to Doubts

7.2. What is a defect?

Defect is a variance from a desired product attribute. It is the difference between actual behavior
and the desired behavior as stipulated by the requirements specifications.
A Defect that causes an error or negatively impacts a user/ customer is categorized as Failure
Defect can arise in any of the Software Test Life Cycle Phase. Defects arising from each phase
should be logged and tracked to closure.
A software bug or defect is an error, flaw, mistake, failure, or fault in a computer program that
prevents it from behaving as intended.
Defects arise on doing verification and validation of the programming products like SRS, Test
Specifications & Code. Most defects arise from mistakes and errors made by people in either a
program's source code or its design, and a few are caused by compilers which are due to
incorrect code.
A program that contains a large number of bugs that seriously interfere with its functionality, is
said to be buggy.

Chapter 7: Defect Management

Assurance - All Chapters
Home
See Leaderboard

Go to Doubts

7.3. Causes of software defects

A human error or mistake produces defects (fault ,bug) in an application, code, in a system or in
a document.

When a defect in the code is executed, the system will fail to do what it is intended to do.
Defects may result in failures, but not all defects lead to failures. Failures can also happen
because of changing hardware conditions.
Defect may occur because of the following reasons like
Fallible nature of human beings
Time pressure
Complex code
Complexity of infrastructure
Changed technologies
Many system interactions etc
See Leaderboard

7.5.Defect Life Cycle

Go to Doubts

7.4. Defect Classification

All the defects which are raised would be assigned a severity level and a priority

Go to Doubts

7.5. Defect Life Cycle

Different steps and status of a defect during its life cycle till it is tracked to closure is as below.
Execute the test and compare the actual results to the documented expected results. If a
discrepancy exists, it is logged with a status Open. Supplementary documentation, such as
screen prints or program traces, should be attached if available.
The Test Manager or tester should review the problem log with the appropriate member of the
development team to determine if the discrepancy is truly a defect.
Assign the defect to a developer for correction. Once the defect is corrected, the developer
will usually enter a description of the fix applied and updates the defect status to Fixed or
Resolved.
The defect is routed back to the testing team for retesting. Additional regression testing is
performed as needed based on the severity and impact of the fix applied.
If the retest results match the expected results, the defect status is updated to Closed. If the
test results indicate that the defect is still not fixed, the status is changed to Re-Open or
Open and sent back to the developer.
Defect Life Cycle
Defect Life Cycle and Defect Status

8.1. Introduction to Automation Testing

Manual Testing of all work flows, all fields, all negative scenarios is time and cost consuming. It
is difficult to test for multilingual sites manually. Manual Testing can become boring and hence
error prone.
Automation does not require Human intervention. Automated tests can run unattended
(overnight). Automation increases speed of test execution.
Automation helps increase Test Coverage.
Which Test Cases to Automate:
Before going for Automation it should be analysed properly as to which test cases to automate.
Factors like risk, repetative and time consuming need to be taken into consideration for
implementation of automation testing process.
The factors to consider for Automation:
High Risk - Business Critical test cases
Test cases that are executed repeatedly
Test Cases that are very tedious or difficult to perform manually
Test Cases which are time consuming

The following category of test cases are not suitable for automation:
Test Cases that are newly designed and not executed manually at least once
Test Cases for which the requirements are changing frequently
Test cases which are executed on ad-hoc basis.
Usability Test cases

Test cases that needed to be executed only once

Tests without predictable results

Automation Process:

Next
Benefits of Automation Testing
My Doubts

8.2. Benefits of Automation Testing

Fast: Automated tests run significantly faster than human users, 70% faster than the manual
testing
Reliable: Tests perform precisely the same operations each time they are run, thereby
eliminating human error
Repeatable: You can test how the Web site or application reacts after repeated execution of
the same operations. Hence automation testing ensures consistency.
Programmable: You can program sophisticated tests that bring out hidden information
Comprehensive: You can build a suite of tests that covers every feature in your Web site or
application. Wider test coverage can be achieved in Automation
Reusable: You can reuse tests on different versions of a Web site or application even if the
user interface changes

Some more advantages of automation testing over manual testing are mentioned below.
Saves Time and Cost: Automation testing is much faster than manual testing. Hence greater
benefit in saving time and cost.
Improves accuracy
Reduction in Human resources: Human Intervention is not required while execution which in
turn reduces human resources.
Increases Efficiency

Test Frequently and thoroughly

More cycle of execution can be achieved through automation
Early time to market

tion Testing
Assurance - All Chapters
Home
See Leaderboard

8.3. Choosing an Automation Tool

Selecting the right tool is a tricky task. Following criterion will help to select the best tool for the
requirement.
Assessment of organizational maturity, strengths and weaknesses and identification of
opportunities for an improved test process supported by tools.
Evaluation against clear requirements and objective criteria.
A proof-of-concept to test the required functionality and determine whether the product meets
its objectives.
Evaluation of the vendor (including training, support and commercial aspects).
Identification of internal requirements for coaching and mentoring in the use of the tool.
Environment Support and Ease of use
Testing of Database
Object identification feature of the tool and verifying against the objects of the application
Image Testing
Error Recovery Testing
Scripting Language Used and the required expertise in the team.
Support for various types of test including functional, test management, mobile, etc., and
also support for multiple testing frameworks.

Debug feature available in the tool. It should be easy to debug the automation software

scripts.
Extensive test reports and results
Previous
Benefits of Automation Testing
Next
Testing Tools

Assurance - All Chapters

Home
See Leaderboard

8.4. Testing Tools

There are different types of Test automation tools available in the market for Automation testing.
Different test tools support different test activities. Some tools support more than one test
activity. Some vendors offer suite of tools that support a large range of test activity. Some tools
are intrusive (they affect the test result)
Some of the Test Automation tools available in the market are:
Functional Testing tools: Following are the some of the tools which can be used for Functional
Automation testing:
HP Quick Test Professional
Selenium
IBM Rational Functional Tester
WinRunner

Test Management tools: Following are some of the Test Management &
Defect Management Tools
HP Quality Center
TCS Application Life Cycle Manager
IBM Rational Quality Manager
Test Link

Performance Testing tools: Following are the some of the tools which can be used for
Performance Automation testing:
LoadRunner
Silk test performer
IBM Rational performance tester
Open STA
Webload

Defect Tracking tools: Bugzilla is an example of defect tracking tool

Previous
Choosing an Automation Tool
Next
Manual Testing Vs Automation Testing

8.5. Manual Testing Vs Automation Testing

Take Chapter Quiz