Testing Principles

1. Testing shows presence of defects i.e. testing reduces the probability of undiscovered defects
remaining in the software but even if no defects are found, it is not proof of correctness.
2. Absence of error is a Fallacy
 Software is 99% Bug – Free
 Software meets the customer’s needs and requirements.

3. Early Testing

Testing should start as early as possible in the Software Development life Cycle.

4. Exhaustive testing is impossible

5. Defect Clustering
A small number of modules contain most of the defects.

6. Pesticide Paradox
If same tests repeated over and over again, eventually the same test cases will no longer find
new bugs which is called Pesticide Paradox

7. Testing is context dependent

Basically means that the way you test the e-commerce site will be different from the way you
test a commercial application.

Waterfall method of the SDLC

Requirements
There are 5 stages

Requirements Stage
Gather as much information as possible about the details & Design
specifications of the desired software from the client.

Design Stage
Build
Plan the programming language like JAVA, PHP, .NET; Database
like Oracle, mysql etc which would be suited for the project. Also some
high level functions & architecture.
Test
Build Stage
Actually code the software.

Testing Stage Maintenance

Test the software to verify that it is built as per the specifications
given by the client.
Maintenance
Once your software product is ready, you may require doing the code changes to accommodate
enhancements requested by the client. This would be Maintenance Stage

All these levels constitute the waterfall Method of Software Development Life Cycle. As you observe,
that testing in the model starts only after implementation is done

Mistake in
Requirements
Requirements

Design Design to Meet

Requiremnet

Build
Built to meet
Design
Test

Wrong product
Maintenance

But, if you are working in large project, where systems are complex, it’s easy to miss out key details in
the requirements phase itself. In such cases, an entirely wrong product will be delivered to the client.
You will have to start a fresh with the projects.

Or if you manage to note the requirements correctly but make serious mistakes in design and
architecture of your software, you will have to redesign the entire software to correct the error.

Assessments of thousands of projects have shown that defects introduced during requirements and
design phase make up close to half of the total number of defects.

Also, the costs of fixing a defect increases across the SDLC. The earlier in life cycle a defect is detected,
the cheaper it is to fix it.
 $16,000
Cost
$14,000
$12,000
$10,000
$8,000 Cost
$6,000
$4,000
$2,000
$0
Requirements Design Coding Testing Maintenance

V – Model of testing

To address this concern, the V – Model of testing was developed. In the V-Model, for every
phase in the development life cycle, there will be a corresponding testing phase. The left hand side of
the model is Software Development Life Cycle model (SDLC) and the right side of the model is Software
Testing Life Cycle model (STLC). The entire figure looks like a V, hence the name V- model.

You find few stages of V-model will be different from Waterfall Model.

SDLC STLC

a User Acceptance Testing

Requirement Analysis

System Testing
Functional Specification

High Level Design Integration Testing

Detailed Design/Pseudo Unit Testing

code functions

Code
SDLC

Requirement analysis

During Requirement analysis phase, after series of meetings the customer decides he wants the
following 5 functionalities into his system Login on Valid Credentials, View Current Balance, Deposit
Money, Withdraw Money, Transfer Money to a 3rd party account

Functional Specification

In the Functional Specification stage architecture, database, and operating environment design are
finalized

High level Design

In High level Design, stage the application is broken down in module & programs

Detail Design

In Detail Design Stage, the pseudo code for functions for each module is documented

Code

Actual Coding Begins. This is the software development cycle of the V-model.

During all these phases, the tester is not sitting idle for the coding to complete

But is doing corresponding testing activities

STLC

Unit Testing

It is also called Component Testing. It is performed on standalone module to check it is developed

correctly. For the Login Module, typical unit test cases would be

 Check response for Valid Login & password

 Check response for invalid Login & password
 Check response when login id is empty and login button is pressed

Developers do unit test. In practical world, developers are either reluctant to test their code or do not
have time to unit test .Many a times, much of the unit testing is done by testers
Integration Testing

In this phase of testing, individual modules are combined and tested as a group.

Integration Testing is carried out by Testers. Data transfer between the modules is tested thoroughly.

Consider this Integration Testing Scenario. Customer is currently in Current Balance Module. His balance
is 1000. He navigates to the Transfer Module. And transfers 500 to a 3rd part account

Customer navigates back to the Current Balance Module & now his latest balance should be 500.

The Modules in the project are assigned to 5 different developers to reduce coding time

Coder 2 is ready with Current Balance module. Coder 5 is not ready with Transfer module required to
test your integration scenario. What do you do in such a situation?

On approach is to use Big - Bang Integration Testing - where you wait for all modules to be developed
before you begin integration testing. The major disadvantage is that it increases project execution time,
since testers will be sitting idle unless all modules are developed .Also it becomes difficult to trace the
root cause of defects.

Alternatively, you can use Incremental approach were modules are checked for integration as and when
they are available.

Consider that the Transfer module is yet to be developed but Current Balance module is ready .You will
create a Stub which will accept and give back data to the current balance module.

Note that, this is not a complete implementation of the Transfer module which will have lots of check
like 3rd party account # entered is correct, amount to transfer should not be more than amount to
available in account and so on. But it will just simulate the data transfer that takes place between the
two modules to facilitate testing

On the contrary, if transfer module is ready but current balance module is not developed you will create
a Driver to stimulate data transfer between the modules

To increase the effectiveness of the integration testing you may use -

Top to down approach where higher level modules are tested first .This technique will require creation
of stubs

Bottom Up approach -where lower level modules are tested first. This technique will require creation
of drivers

Other approaches would be functional increment & Sandwich - which is combination of top to down
and bottom to up.

The choice of approach chosen depends on the system architecture and location of high risk modules.

System Testing

Unlike Integration testing, which focuses on data transfer amongst modules, System Testing checks
complete end to end scenarios, as the way a customer would use the system.

A good example of Test Case in the phase would be - Login into the banking application, Check Current
Balance, Transfer some money, Logout

Apart from Functional, NON-FUNCTIONAL requirements are also checked during system testing. Non-
functional requirements include performance, reliability.

User Acceptance Testing

Acceptance test is usually done at client location, by the client, once all the defects found in System
testing phase are fixed.

Focus of Acceptance test is not to find defects but to check whether meet their requirements .Since
this is the first time, the client sees their requirements which is plain text into an actual working system

Acceptance Testing can be done in two ways

Alpha Testing – A small set of employees of the client in our case employees of the bank will use the
system as the end user would

Beta Testing – A small set of customers in our case bank account holders will use the software and
recommend changes

That’s all to the various testing levels in the V- model

Iterative Life Cycle

Apart from V- Model, there are iterative development models, where development is carried in
phases, with each phase adding a functionality to the software.

Each phase comprises of, its own independent set of development and testing activities.

PHASE 1 PHASE 2 PHASE 3

Requirements Requirements Requirements

Design Design Design

Build Build Build

Test Test Test

Good examples of Development lifecycles following iterative method are Rapid Application
Development, Agile Development

You must note that,

 There are numerous development life cycle models. 

 Development model selected for a project, depends on the aims and goals of that project
 Testing is not a stand-alone activity and it has to adopt with the development model chosen for
the project.
 In any model, testing should performed at all levels i.e. right from requirements until
maintenance.

Scenario

Consider a scenario, when after fixing defects of integration testing, the system is made available to the
testing team for system testing

You look at the initial screen, system looks fine and delay system test execution for the next day since
you have other critical testing requirements to attend to

Next day say you plan to execute the scenario login > View Balance > Transfer 500 > logout. The
deadline is 4 hours.

You begin executing the scenario , enter a valid login id , password, click the login button and boom you
are taken to a blank screen with absolutely no links , no buttons & nowhere for you to proceed with
succeeding steps of your scenario

This is not a figment of any imagination but a very practical condition which could arise due to developer
negligence, time pressures, test environment configuration & instability

To fix this developer requires atleast 5 hours & deadline would be missed

In fact, none of your team members would be able to execute their respective scenarios, since view
balance is start point to perform any other operation and the entire project will be delayed

Had you checked this yesterday itself, the system would been fixed by now and you were good for
testing

To avoid such situation sanity also know SMOKE testing is done to check critical functionalities of the
system before it is accepted for major testing. Sanity testing is quick and is non- exhaustive. Goal is not
to find defects but to check system health
Types of Testing

In general there three testing types 1) Functional 2)  Non - Functional 3) Maintenance.

Under these types, you have multiple TESTING Level's but usually people call them as Testing Types.

You may find some difference in this classification in different resources but the general theme remains
the same.

This is not the complete list as there are more than 150 types of testing types and still adding. No need
to bother or worry, you will pick them up as you age in the testing industry.

Also, note that not all testing types are applicable to all projects but depend on nature & scope of the
project.

Functional Testing

Regression Testing:

Suppose that in our banking application your current balance is 2000.

Using the new enhancement, you check your balance for a year ago that comes out to be 500.

You enter the transfer module and try to transfer Rs 1000.In order to proceed the transfer module
checks for the current balance.

Instead of sending the current balance, it sends the old balance of 500 and transaction fails

As you may observe, code changes were in Current Balance module only but still transfer module is
affected. Regression testing is carried out to check modification in software has not caused
unintended adverse side – effects

Sanity also know SMOKE testing is done to check critical functionalities of the system before it is
accepted for major testing. Sanity testing is quick and is non- exhaustive. Goal is not to find defects but
to check system health

Non – Functional Testing

Apart from Functional testing, non – functional requirements like performance, usability, and load factor
are also important.

Performance Testing

How many times have you seen such long load time messages while accessing an application - (pic in
video) I am sure many.
To address this issue, performance testing is carried out to check  & fine tune system response
times. The goal of performance testing is to reduce response time to an acceptable level.

Load Testing

Load testing is carried out to check systems performance at different loads i.e. number of users
accessing the system

Depending on the results and expected usage, more system resources may be added

 Maintenance Testing:

Suppose in the current Balance module instead of just showing the current balance the client now wants
customized reports based on date & amount of transaction

Obviously, any such change needs to be tested. Once deployed, testing any further system changes ,
enhancements or corrections forms part of Maintenance Testing

 Test scenario & Test Prioritization

Test Scenario - A Scenario is any functionality that can be tested. It is also called Test Condition, or
Test Possibility.

For the Flight Reservation Application a few scenarios would be 1) Check the Login Functionality 2)
Check that a New Order can be created 3) Check that an existing Order can be opened 4) Check that a
user, can FAX an order 5) Check that the information displayed in the HELP section is correct 6) Check
that the information displayed in About section, like version, programmer name, copy right information
is correct

Apart from these six scenarios try and list all the other possible scenarios for the application. Pause the
tutorial and complete the exercise

I am sure you have identified many a more like Update Order, Delete Order, Check Reports, Check
Graphs, and so on. For the time being let’s stick to these six.

Next, we have already learned exhaustive testing is not possible. Suppose you have time  to only
execute 4 out of these 6 scenarios Which two low priority scenarios of these six will you eliminate.
Think, your time starts now

I am sure most of you would have guessed scenarios 4 & 5, since they are not the core functionality of
the application. This is nothing but Test Prioritization
Test Case Design

Now, consider the Test scenario Check Login Functionality there many possible cases like  Check
response on entering valid Agent Name & Password ,Check response on entering invalid Agent Name &
Password ,Check response when Agent Name is Empty & Login Button is pressed, and many more

This is nothing but Test Case. Test scenarios are rather vague and cover a wide range of possibilities.
Testing is all about being very specific. Hence we need Test Cases

Now just consider the test case, Check response on entering valid Agent Name and password. It’s
obvious that this test case needs input values viz.Agent Name & Password

This is nothing but Test Data. Identifying test data can be time-consuming and may sometimes require
creating test data afresh. The reason it needs to be documented

Before we proceed ahead  consider a quote from a witty man who said "To ensure perfect aim, shoot
first and call whatever you hit the target" But if you do not live by this philosophy ,which I am sure most
of you do not then your Test case must have an expected result.

For our test case, expected result would be, Login should be successful

If expected results are not documented we may miss out on small differences in calculations in results
which otherwise look OK.

Consider this example, where you are calculating monthly pay for an employee which involves lots of
calculations. The need for documenting expected results becomes obvious.

Suppose the author of the test case has left the organization or is on a vacation or is sick and off duty
or is very busy with other critical tasks and you are recently hired and have been asked to execute the
test case. Since you are new, it would certainly help to have test steps documented which in this case
would be Launch application, Enter Agent Name, Enter Password, and Click OK

You may wonder that for this simple test steps, documentation is not required

But what is your test steps looked something like this? (pic in video) I think the need will become
instantaneously obvious.

That apart your test case -may have field like, Pre - Condition which specifies things that must in place
before the test can run

For our test case, a pre-condition would be Flight Reservation Application should be installed, which I
am sure 50% of the people watching this tutorial do not have

Also, your test case may also include Post – Conditions which specifies anything that applies after the
test case completes.

For our test case, a post - condition would be time & date of login is stored in the database
During test case execution , you will document the results observed in the Actual Results column and
may even attach some screen shots and based on the results give PASS & FAIL status.

This entire table may be created in Word, Excel or any other Test management tool. That’s all to Test
Case Design

Test-Basis

Explains what "Test-Basis" is, and what test cases are actually derived from, using the V-model of testing
quoting real - world examples.

 Now, consider a scenario, where the client sends in a request to add functionality to Flight
Reservation to allow sending an order via email. He also specifies the GUI fields and buttons he
wants.
 Even though the application is yet to be developed, try and develop a few test cases for this
requirement. A few test cases amongst the many you could have thought of would be-
 Check response when Valid Email ID are entered and send is pressed
 Check response when invalid  Email ID are entered and send is pressed
 You may have also realized that to create test cases you need to look at something to base
your test. This is nothing but Test Basis
 This test basis could be the actual Application Under Test (AUT) ,or may ay be even
by experience but most of the times , like in this case would be based on documents
 In fact , this is what happens during the different phases of V- Model where test plans are
created using the corresponding documents and once the code is ready , testing is done

Traceability Matrix

 Consider a scenario where, the client changes the requirement, something so usual in the
practical world and adds a Field Recipient name to the functionality. So now you need to enter
email id and name both to send a mail
 Obviously you will need to change your test cases to meet this new requirement
 But , by now your test case suite is very large and it is very difficult to  trace the test cases
affected by the test cases
 Instead, if the requirements were numbered and were referenced in the test case suite it would
have been very easy to track the test cases that are affected. This is nothing but Traceability
 The traceability matrix links a business requirement to its corresponding functional
requirement right up to the corresponding test cases.
 If a Test Case fails, traceability helps determine the corresponding functionality easily.
 It also helps ensure that all requirements are tested.
Testing Techniques

This tutorial introduces the concept of Testing techniques and its importance. It demonstrates use of
Equivalence partitioning and boundary value analysis with a simple example.

A black box technique where the code is not visible to the tester

Equivalence Partitioning Testing Technique

It is a black box testing technique which can be applied to all levels of testing like unit, integration,
system etc.

In Equivalence Partitioning, you divide set of test conditions into partitions that can be considered the
same.

To understand this better, let’s consider the behavior of tickets in the Flight reservation application,
while booking a new flight. Ticket values 1 to 10 are considered valid & ticket is booked.

Values 11 to 99 are considered invalid and a error message "Only ten tickets may be ordered at one
time" is shown

On entering values 100 and above, the ticket # number defaults to a two digit number

On entering values 0 and below, the ticket # defaults to 1

Invalid Valid Invalid Invalid

0 1 10 11 99 100
Partition 1 Partition 2 Partition 3 Partition 4

We cannot test all the possible values , because if done , number of test cases will be more than 100 .To
address this problem we use equivalence partitioning where we divide the possible values of tickets 
into groups or sets where the system behavior can be considered the same.

The divided sets are called Equivalence Partitions or Equivalence Classes. Then we pick only one value
from each partition for testing.

Invalid Valid Invalid Invalid

0 1 10 11 99 100
Partition 1 Partition 2 Partition 3 Partition 4

-1 5 88 121
The hypothesis behind this technique is that if one condition/value in a partition passes all others will
also pass. Likewise, if one condition in a partition fails, all other conditions in that partition will fail

Boundary Value Analysis Testing Technique

In Boundary Value Analysis, you test boundaries between equivalence partitions

In our earlier example instead of checking, one value from each partition you will check the values at the
partitions like 0, 1, 10, 11 and so on

As you may observe, you test values at both valid and invalid boundaries

Boundary Value Analysis is also called range checking.

Equivalence partitioning and boundary value analysis are closely related and can be used together at all
levels of testing.

Decision Table Testing Technique

Decision Table Testing is a good way to deal with combination of inputs, which produce different results

To understand this with an example let’s consider the behavior of Flight Button for different
combinations of Fly From & Fly To

When both Fly From & Fly To are not set the Flight Icon is disabled. In the decision table , we register
values False for Fly From & Fly To and the outcome would be ,which is Flights Button will be disabled i.e.
FALSE

Next, when Fly From is set but Fly to is not set, Flight button is disabled. Correspondingly you register
True for Fly from in the decision table and rests of the entries are false

When, Fly from is not set but Fly to is set, Flight button is disabled and you make entries in the decision
table

Lastly, only when Fly To and Fly From are set, Flights button is enabled and you make corresponding
entry in the decision table

Conditions Rule1 Rule2 Rule3 Rule4

FLY FROM F T F T

FLY TO F F T T

OUTCOME F F F T
FLIGHTS BUTTON
If you observe the outcomes for Rule 1, 2 & 3 remain the same .So you can select any of them and rule 4
for your testing

The significance of this technique becomes immediately clear as the number of inputs increases.
Number of possible Combinations is given by 2 ^ n, where n is number of Inputs.

For n = 10, which is very common in web, based testing, having big input forms, the number
of combinations will be 1024.Obviously, and you cannot test all but  you will choose a rich sub-set of the
possible combinations using decision based testing technique.

State Transition Testing Technique

This technique is helpful where you need to test different system transitions.

To understand this with an example, let’s consider the behavior of ‘Login’ screen of Flight Reservation
application.

In login screen, first enter Agent Name and then enter correct password on first attempt. You are given
access to the flight application.

In case, you entered wrong password, error message will be displayed. You can make 3 attempts. But
when you enter wrong password 4th time, the application will be closed.

In case, if you enter correct password during 2 nd, 3rd, or 4th attempt, you will be given access to the
application. Close Application

Enter Agent Incorrect Password

Name

Start 1st Try 2nd Try 3rd Try 4th Try

Correct Password

Access
 The above diagram is called State Chart or Graph.
 There are 4 main components of the Graph
1) States software may occupy Start

2) Transition from one state to other

 3) Events that cause transition Correct Password

4) Actions that results from events

Close Application

State Graph is used for identifying valid transitions. But if you want to determine invalid transitions you
can use State Table.

In a state Table all the valid states are listed on the left side of the table, and the events that cause them
on the top.

Each cell represents the state system will move to when the corresponding event occurs

Correct Password Incorrect Password

S1)Start S6 S2
S2)1st Try S6 S3
S3)2nd Try S6 S4
S4)3rd Try S6 S5
S5)4th Try S6 S7
S6)Access ? ?
S7)Close Application - -

For example while in S1 state you enter correct password, you are taken to state S6

Or in case you enter incorrect password you are taken to state S2

Likewise you can determine all other states

Two invalid states are highlighted using this method which basically means, what happens when you are
already logged into the application and you open another instance of flight reservation and enter valid
or invalid passwords for the same agent.

System response for such a scenario can need to be tested.

Use Case Testing Technique

 This technique helps identify test cases that cover the entire system, on transaction by
transaction, from start to finish.
 A use case is a description of particular use of the system by an actor (user).
 Used widely in developing tests at system or acceptance level

In use case, an actor is represented by "A" and system by "S"

First we list the Main Success Scenario.

Main Success Scenario Step Description

1 A: Enter Agent Name &Password

A:Actor 2 S: Validate Password

S:System 3 S: Allow Account Access

2a Password not valid
Extensions S: Display message & ask for re-try 4 times

2b Password not valid 4 times

S: Close Application

Consider the first step of an end to end scenario for login functionality of Flight Reservation application
where the Actor enters Agent Name and password.

In the next step system will validate the password

Next, if password is correct, Access is granted.

There can be extension of this use case

In case password is not valid system will display message and ask for re-try four times

Or if Password not valid four times system will close the application

Here we will test the success scenario and one case of each extension
Static Techniques

Static techniques are testing techniques in which the code is not run.

Review: A review is the most important testing technique.

 In simple words, review is a meeting where people analyze a software work product and
recommend changes with the objective of improving quality.
 The software work product could be a design document, System Requirement
Specification (SRS), Code, Test Plan etc.
 It helps in detecting defects in early in the development life cycle and reduces costs.
 Almost always, the testing team is part of the review meetings.

The various Stages of Review are

 Planning
 Kick Off Meeting
 Review meeting
 Rework
 Follow-Up

To understand a review in detail let’s consider the same example ,

 To add email functionality to flight reservation application for which the Functional Design
Document is prepared by the technical lead.

 Technical Lead approaches his Manager and requests to initiate a review.

 The Manager will quickly go through the document and check whether the document is of
acceptable quality to request a review by other people. For example, in this case, he finds a
few spelling mistakes and asks the technical lead to correct them.

 Once corrected

The manger will send out a meeting request to all stake holders with Meeting Location
Information, Date and Time of meeting, and will mention the Agenda for the Meeting; he will
also attach the Functional Design Document itself to meeting request for reference. This is the
planning stage.

 Next stage is the Kick Off Meeting. It is an Optional Stage. Goal is to get everybody on the same
wavelength regarding the document under review and is beneficial for new or highly complex
projects.

 Next stage is the Preparation Stage where Review Meeting participants individually go through
the document to identify defects, comments and questions to be asked during the review
meeting.
 This phase is necessary to ensure that during the meeting participant’s focus of subject in hand
instead of day dreaming. This is your exercise. For this Functional Design Document think of the
details missing, this will help you test this functionality. Pause the training and think!

Add a function to send an order via EMAIL

Fields Button
-Email Id -Send
-Recipient Name

 The next stage, which is, the actual review meeting. Here, the meeting Participants are
assigned different roles to increase the effectiveness of the meeting.

 The moderator is a role usually played by the manager who leads the review meeting and sets
the Agenda.

 The creator of the document, under review plays the role of AUTHOR who reads the document
and invites comments

 The task of the reviewer is to communicate any defects in the work product.

Suppose, one of the reviewer says it would be nice to have a Reset Button. The author agrees to
this. Another review comment is that there is no mention, as to where in the menu item, the
Email Functionality will appear. Again the author agrees and accepts to make changes

 The meeting participant playing the role of the scribe (also known as recorder), will note down
this defect or suggestion.

One young review, suggests the possibility of sharing a ticket via face book, orkut and so on. The
author strongly disagrees to this and the reviewer and author enter into a heated argument. At
this juncture the moderator intervenes and finds an amicable solution which is to ask the client
whether he needs sharing via social networking.

 Finally, all comments are discussed and the scribe gives a list of Defects / Comments /
Suggestions that the author needs to incorporate into his work product.

SNo Review Comments

1 Add Reset Button

2 Add details about Menu

3 Ask the client about facility to share via Social Networking

Sites
 The moderator then closes the review meeting. That’s all to the meeting phase of review.

The important roles here are - The Moderator, the Author, the Scribe / Recorder, the
Reviewers

The moderator and scribe can also play the role of reviewer meaning they can give review
comments to the author.

Re-Work

The next phase of the review is the re-work phase, where the author will make changes in the
document, as per the action items of the meeting.

SNO Review Comment Status

1 Add Reset Button Done

2 Add detail about Menu Done

3 Ask the client about facility to Not Valid. Client

share Via Social Networking Sites does not need this

Follow-up Phase

In the Follow -up phase, the moderator will circulate the reworked document to all review
participants and ensure that all changes have been included satisfactorily.

This was a generic review.

Note that, there are three types of reviews

 Walk Through , which is led by Author

 Technical Review ,  which is led by a trained moderator with  No management
participation
 Inspection ,which is  led by trained moderator and use entry and exit criteria

All these 3 types follow the same review process and follow the same stages as discussed
earlier.
Estimating Testing Effort

Testing Effort is estimated using the various test estimation techniques.

 Let’s do an exercise -for the Flight Reservation Application prepare a Work Breakdown Structure
of the various testing tasks like - Check Login Functionality, Check New Order Functionality, Check
Fax Functionality, and other similar functionality and Estimate the effort required to test these
functionalities
 For example login functionality can be tested in 2 hours. Likewise prepare a list of all the tasks
and corresponding effort. Pause the training tutorial and complete the exercise. I hope you made an
educated guess of the effort required

Work Breakdown Structure (WBS)

TASKS Effort Duration Dependencies Resources

Check Login 2 hrs Order must exist before 1) Standard PC

Functionality Fax, Update Order and with Flight
Delete Order Reservation
functionalities can be application
checked. installed
Check New Order 3 hrs 4 Man
Functionality Days
Check Fax 1 hr 2)MS Word
Functionality installed
Check Delete Order 2 hrs
Functionality
Check Update Order 2 hr
Functionality

 This is Bottom - Up Strategy for Test Estimation. The technique is called bottom- up since based
on the tasks which is at the lowest level of the work breakdown hierarchy you estimate the
duration, dependencies and resources.

 In bottom up strategy, estimates are not taken by a single person but all
stakeholders, individual contributors, experts and experienced staff members collectively.  The idea
is to draw on the collaborative wisdom of the team members to arrive at accurate test estimates

 Now since you have considerable experience on the flight reservation system. Use this
experience to estimate the effort required for full functional testing of the website. -
http://newtours.demoaut.com/

 This site’s functionally is identical to the Flight Reservation Application, just that it is web based.
Pause the tutorial and do the exercise now

 I hope based on your experience you made a good estimate on the effort required to test the
website
 This is the Top - Down Approach to estimation which is based on experience.

 Another technique is to classify project based on their size and complexity and then seeing how
long a project of a particular size and complexity have taken in past.

 Another approach is determining Average Effort Per Test Case in past for similar projects  and
then using estimated test cases of the current project and arriving at total effort

 More sophisticated estimation models involve complex mathematical models. In practice,

majority of the projects use top-down approach for estimation.

 Test estimates can be affected by many factors like timing pressures , people factors ,
geographic distribution of the test team and so on

Test Plan
 In a earlier trainings we have already informed that there more than 150 types of testing and
you cannot possibly test your application for all the different types
 For the Flight Reservation system -you might want to test the application to examine how it
works when installed on different operating systems
 But testing it to check how it works for different browsers does not makes sense since it is not a
web based application
 Based on above, you can make a list testing types that are in scope and will be tested and out of
scope, testing types that will not be executed for flight Reservation.
In Scope Out of Scope

Cross Platform Testing Cross Browser Testing

Performance Testing Localization Testing

Functional Testing
RISK
A Risk could any future event with a negative consequence .You need to identify the  risks
associated with your project
Risks are of two types  
1) Project Risks
Risk Likelihood Impact Mitigation
Senior Team Member 5 3 Knowledge Transfer
leaving the Project
Buffer Resource
abruptly

o Example of  Project risk is  Senior Team Member leaving the project abruptly
o Every risk is assigned a likelihood i.e. chance of it occurring, typically on a scale of 1 to
10.Also the impact of that risk is identified on a scale of 1- 10 .
o But just identifying the risk is not enough. You need to identify mitigation. In this case
mitigation could be Knowledge Transfer to other team members & having a buffer
tester in place
2) Product Risk
Risk Likelihood Impact Mitigation

Senior Team Member 5 3 Knowledge Transfer

leaving the Project
Buffer Resource
abruptly
Flight Reservation 8 10 Sanity/Smoke Testing
system may not install
in testing environment

o The second types of risks are product risks. An example of a product risk would be Flight
Reservation system not installing in test environment
o Mitigation in this case would be conducting a smoke or sanity testing. Accordingly you
will make changes in your scope items to include sanity testing.

In Scope Out of Scope

Cross Platform Testing Cross Browser Testing

Performance Testing Localization Testing

Functional Testing

Sanity/Smoke Testing
 o This is risk based strategy of testing. There are many other testing strategies to help
you select testing types for your application under test.
o Most of the times your out scope times will not contain out of context testing types
but in context testing types excluded due to the test strategy chosen , budget and
timing considerations. So for example if timing considerations do not permit
performance testing it will move from in scope to out of scope list.
o That apart, a test plan will contain information about the Test Estimates, Test Team,
Schedule, and so on.
o A test Plan helps monitor the progress of various testing activities and helps  take
controlling action in case of any deviations from the planned activities. That’s a brief
overview of how to create a test plan

DEFECT
It is also known as Software bug, incident, and fault.

While executing test cases you may find that actual results vary from the expected results. This is
nothing but a defect also called incident, bug, problem or issues.

In case you find a defect, what information would you convey to a developer to help him understand
the defect?

Your Bug Report should contain following information

 Defect_ID – Unique identification number for the defect.

 Defect Description – Detailed description of the defect including information about the module
in which defect was found.
 Version – Version of the application in which defect was found.
 Steps – Detailed steps along with screenshots with which the developer can reproduce the
defects.
 Date Raised – Date when the defect is raised
 Reference- where in you provide reference to the documents like. requirements, design,
architecture or may be even screenshots of the error   to help understand the defect
 Detected By – Name/ID of the tester who raised the defect
 Status – Status of the defect , more on this later
 Fixed by – Name/ID of the developer who fixed it
 Date Closed – Date when the defect is closed

A sample bug report for your reference. This apart, your bug report will also include
 Severity, which describes the impact of the defect on the application
 Priority which is related to defect fixing urgency.

Severity & Priority could be High/Medium/Low based on the impact & urgency at which

the defect should be fixed respectively
 A defect could have a very low severity but a high priority
For example if there is an error in the text of the logo of flight reservation application, its
severity is low since its can be fixed very easily and it does not affect any functionality of
the system .But it needs to be fixed at high priority since you do not want to ship out
your product with a incorrect logo

Likewise a defect could be high severity but low priority

Suppose there is a problem with Email functionality of Flight Reservation .This defect
has high severity since it causes the application to crash but the functionality is
scheduled to release in next cycle which makes it a low priority

Defect Life Cycle

From discovery to resolution a defect moves through a definite lifecycle called the defect lifecycle

Tester finds a Defect

Status = New

Development project Manager will

analyze the Defect

Is a Valid Bug? Is it in Scope? Is it already raised?

Status = REJECTED Status = DEFFERED Status = DUPLICATE

 Suppose a tester finds a defect .The defect is assigned a status, new.

 The defect is assigned to development project manager who will analyze the defect. He will
check whether it is a valid defect.

Consider that in the flight reservation application, the only valid password is mercury. But you
test the application for some random password, which causes logon failure, and report it as
defect .Such defects due to corrupted test data, miss configurations in the test environment,
invalid expected results etc are assigned a status rejected.

If not, next the defect is checked whether it is in scope. Suppose you find a problem with the
email functionality. But it is not part of the current release .Such defects are postponed.

Next, manager checks whether a similar defect was raised earlier. If yes defect is assigned a
status duplicate.

If no, the defect is assigned to developer who starts fixing the code. During this stage defect is
assigned a status in- progress.

 Once code is fixed. Defect is assigned a status fixed.

 Next the tester will re-test the code. In case the test case passes, the defect is closed.
If the test case fails again, the defect is re-opened and assigned to the developer.

Consider a situation where during the 1st release of Flight Reservation a defect was found in Fax
order which was fixed and assigned a status closed. During the second upgrade release the same
defect again re-surfaced. In such cases, a closed defect will be re-opened.

That’s all to Bug Life Cycle