Types of Testing.

Testing Life
cycle, Bug Life cycle

Day 4-Session 1
Lavanya.M
 Software Testing Life
cycle
Test Plan

Test Design

Test Execution

Test Log

Defect Tracking

Report Generation.
 Testing Plan
During this phase Test Strategy, Test Plan, Test Bed will
be created.
A test plan is a systematic approach in testing a system or
software.
The plan should identify:
• Which aspects of the system should be tested?
• Criteria for success.
• The methods and techniques to be used.
• Personnel responsible for the testing.
• Different Test phase and Test Methodologies
• Manual and Automation Testing
• Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc
• Evaluation & identification – Test, Defect tracking tools
 Test Design
During this phase

• Test Scenarios will be identified.

• Test Cases will be prepared.
• Test data and Test scripts prepared.
• Test case reviews will be conducted.
 Test Execution

Testers execute the software based on the plans

and test.
Test cases will be executed.

Test Scripts will be tested.

 Test Log

A chronological record of all relevant details about

the execution of a test.

Test Results will be analyzed

 Defect Tracking

Capture, review and analyze Test Results

Raised the defects and tracking for its closure

 Report Generation.

Test summary reports

Test Metrics and process Improvements made

Build release

Receiving acceptance
Bug Life Cycle
 Types of Testing
List of the different types of testing that can be implemented are listed below which
will be followed by explanations of the same

Black Box Testing
Usability Testing

White Box Testing
Install / Uninstall Testing

Unit Testing
Recovery Testing

Incremental Integration Testing
Security Testing

Integration Testing
Compatibility Testing

Functional Testing
Exploratory Testing

System Testing
Ad-hoc Testing

End-to-End Testing
Comparison Testing

Sanity Testing
Alpha Testing

Regression Testing
Beta Testing

Acceptance Testing
Mutation Testing

Load Testing
Conformance Testing

Stress Testing
Quality Assurance Testing

Performance Testing
 Black Box Testing
It can also be termed as functional testing
Tests that examine the observable behavior of software as
evidenced by its outputs without referencing to internal
functions is black box testing
It is not based on any knowledge of internal design or code
and tests are based on requirements and functionality
In object oriented programming environment, automatic code
generation and code re-use becomes more prevalent, analysis
of source code itself becomes less important and functional
tests become more important
Test if a component conforms to specification
 White Box Testing

It can also be termed as Structural Testing

Tests that verify the structure of the software and require complete
access to the object’s source code is white box testing
It is known as white box as all internal workings of the code can be
seen
White-box tests make sure that the software structure itself contributes
to proper and efficient program execution
It is based in of the internal logic of an applications’ code and tests are
based on coverage of code statements, branches, paths, conditions
In this type of testing code needs to be examined by highly skilled
technicians
Test if a component conforms to design
 Functionality
Testing

It is black-box testing geared to functional requirements and should be

done by testers
Testing done to ensure that the product functions the way it is designed to
according to the design specifications and documentation
This testing can involve testing of product’s user interface, database
management, security, installation, networking, etc.
 Sanity Testing

Initial testing effort to determine if a new software version is performing well

enough to accept it for a major testing effort.
For example, if the new software is crashing systems every 5 minutes,
bogging down systems to a crawl, or destroying databases, the software
may not be in a 'sane' enough condition to warrant further testing in its
current state.
 Regression Testing

This is re-testing of the product/software to ensure that all reported bugs

have been fixed and implementation of changes has not affected other
functions
It is always difficult to the amount of re-testing required, especially when the
software is at the end of the development cycle
These tests apply to all phases wherever changes are being made
This testing also ensures reported product defects have been corrected for
each new release and that no new quality problems were introduced in the
maintenance process
 Load Testing

Testing an application under heavy loads

For example, testing of a Web site under a range of loads to determine at
what point the system’s response time degrades or fails
Accurate pre-determination of performance can be determined through this
testing
 Stress Testing
This term is more often used interchangeably with ‘load’ and
‘performance’ testing.
It is system functional testing while under unusually heavy loads, heavy
repetition of certain actions or inputs, input of large numerical values,
large complex queries to a database system
Always aimed at finding the limits at which the system will fail through
abnormal quantity or frequency of inputs.
Examples could be:-

higher rates of inputs

data rates an order of magnitude above ‘normal’

test cases that require maximum memory or other resources

test cases that cause ‘thrashing’ in a virtual operating system

test cases that cause excessive ‘hunting’ for data on disk systems

This testing can also attempt to determine combinations of otherwise
normal inputs can cause improper processing
 Performance
Testing

This term is more often used interchangeably with ‘stress’ and ‘load’ testing
To understand the applications’ scalability, or to benchmark the performance
in a environment or to identify the bottlenecks in high hit-rate Web sites, this
testing can be used
This testing checks the run-time performance in the context of the integrated
system
This may require special software instrumentation
Ideally, these types of testing are defined in requirements documentation or
QA or Test Plans.
 Usability Testing

This testing is testing for ‘user-friendliness’

The target will always be the end-user or customer
Techniques such as interviews, surveys, video recording of user sessions
can be used in this type of testing
Programmers and Testers are not appropriate as usability testers
 Install/Uninstall
Testing

Testing of full, partial, or upgrade install/uninstall processes The target will

always be the end-user or customer
 Compatibility
Testing

Testing whether the software is compatible in particular hardware / software /

operating system / network / etc. environment
 Alpha Testing

This is testing of an application when development is nearing

completion;mostly testing conducted at the developer’s site by a customer
The customer uses the software with the developer ‘looking over the
shoulder’ and recording errors and usage problems
Testing is conducted in a controlled environment
Minor design changes can be still made as a result of this testing
Typically conducted by end-users or customers and not by programmers
or testers
 Beta Testing

Testing conducted when development and testing are completed and bugs
and problems need to be found before final release
It is ‘live’ testing in an environment not controlled by the developer.
Customer records the errors / problems reports difficulties at regular
intervals
Testing is conducted at one or more customer sites
Typically conducted by end-users or customers and not by programmers
or testers
 Exercise
 Testing efforts should be started only after the coding
is completed. True/False

 Software testing efforts aim at preventing bugs. - True/False

 During the Construction phase in the life cycle, both

functional and structural Test data should be generated and
applied. - True/False

 The data that is generated for Statement testing, Branch

Testing and path testing is known as ____________

 Explain in your own words about

 Boundary value analysis
 Equivalence Partitioning