SDLC

Requirement Implementation UAT

Testing Life Cycle

Specification IST

Design Unit Testing

Code

Objective of Testing
 Primary role of testing is not demonstration of correct
performance but the exposure of hidden defects
 Testing is executing a program with an intend of
finding Fault/Error and Failure.
 Error: Human Action that produces an in correct
result.
 Fault: Manifestation of an error in software. (also
called defect or Bug)
  Failure: Deviation of the software from its expected
delivery or service.

Why Software Testing?

•To discover defects.

•To avoid user-detecting problems.
•To prove that the software has no faults.
•To learn about the reliability of the software.
•To ensure that product works as user expected.
•To stay in business.
•To avoid being sued by customers.
•To detect defects early, which helps in reducing the cost
of defect fixing.

What are we testing for?

Discovering defects from what is expected

There are two types of defects –
1] Variance from Specifications.
2] Variance from what is desired.

Why do we need an approach for testing?

Yes, We definitely need an approach for testing.
To over come the following problems, we need a formal
approach for Testing.
•Incomplete functional coverage
•No risk management
•Too little emphasis on user tasks
•Inefficient over the long term

What is Quality?

Here are some of the traditional definitions:

–Fitness for use (Dr. Joseph M. Juran)
–The totality of features and characteristics of a product that bear on its ability to
satisfy a given need (ASQ)
–Conformance with requirements (Philip Cosby)
–The total composite product and service characteristics of marketing, engineering,
manufacturing and maintenance through which the product and service in use will
meet expectations of the customer (Armand V. Feigenbaum)

Quality Assurance
It is a planned and systematic pattern of all actions
necessary to provide adequate confidence that an item or
product conforms to established technical requirements. A
Set of activities designed to evaluate the process by which
products are developed or manufactured.

Quality Control
Set activities designed to evaluate the quality of
developed or manufactured products.
It is the process which product compares quality with
applicable standard.

Verification
It is the process of evaluating a system or component to
determine whether the products of a given development
phase satisfy the conditions imposed at the start of that
phase.
Validation
It is the process of evaluating a system or component
during or at the end of the development process to
determine whether it satisfies specified requirements.

Static Testing
It is the process of evaluating a system or component
based on its form, structure, content or documentation
without computer program execution.

Requirement & Function

Requirement
 It is a statement of what the data and Software should
perform.
Function
It is a desirable behavior of a requirement.

Test Baselines

Business Requirement Document

Functional Specification Document
Design Specification Documents
Gap Analysis Document

2 Areas of Testing

• Black box Testing

• White box Testing

Black box Testing

Black box testing is also called as Functionality Testing. In

this testing Tester will be asked to test the correctness of
the functionality with the help of Inputs and Outputs.
Tester doesn’t require the knowledge of software code.
Approach:

•Equivalence Class

•Boundary Value Analysis

•Error Guessing

Equivalence Class:

• For each piece of the specification, generate one or

more equivalence Class.
• Label the classes as “Valid” or “Invalid”.
• Generate one test case for each Invalid Equivalence
class.
• Generate a test cases that Covers as many as for
Equivalence class.

Boundary Value Analysis:

• Generate test cases for the boundary values.

• Minimum Value, Minimum Value + 1, Minimum Value -1
• Maximum Value, Maximum Value + 1, Maximum Value – 1

Error Guessing:

Generate Test cases against to the specification.

White box Testing

White box testing is also called as Structural testing. Tester does

require the knowledge of software code.

Structure = 1 Entry + 1 Exit with certain Constraints, Conditions and

Loops
.

Why do we go for white box testing when black box testing is used
to find defects?

• Logic Errors and incorrect assumptions are most likely to be made

while coding for “special cases”. Need to ensure these execution
paths are tested.
• May find assumptions about execution paths incorrect, and so
make design errors.
• Typographical errors are random. Just as likely to be on an obscure
logical path as on a mainstream path.

Approach

Basic Path testing:

Cyclomatic Complexity.
Mc Cabe Complexity.
Structure Testing:
Conditions Testing.
 Data Flow Testing.
Loop testing.

4 Phases of Testing – The V Model

• Unit Test
• Integration Test
• System Test
• Acceptance Test

V-Model

What is Unit Testing

Unit testing involves testing the smallest software Unit of

block of code.
A Software Unit can be collection of code segment that
make up a modular or a function .It can be a Screen of a
GUI application.

Integration Testing:
The primary objective of integration testing is to discover
errors in the interfaces between Modules / Sub-Systems.

Approach:

Top-Down Approach.
Bottom-Up Approach.

System Testing:

The primary objective of system testing is to discover

errors when the system is tested as a whole. System
testing is also called as End-To-End Testing. Tester is
expected to test from Login-To-Logout by covering various
business functionalities.

Approach: IDO Model

Identifying the End-To-End / Business Life Cycles.

Design the test and data.
Optimize the End-End / Business Life Cycles.
What is UAT?
 User Acceptance testing involves having the end
users test how the software performs in their every
day business processes.
 The explanation of UAT is actually in its name.
 Taking each part separately explains what it is about.

USER
ACCEPTANCE
TESTING

What is USER?

Users means the real business users, who will have to

operate the system; normally the staff of an organization.
They are the only people who understand exactly what the
business is, and how it operates. Therefore they are the
only people qualified to check a system to see if it will
deliver any benefit to the business or organization.

What is ACCEPTANCE?

 The acceptance of a system means you are confident

it will give benefit to the organization.
  It does not mean that it only meets the original
specification as requested.
 The point is that a system may not be acceptable,
even if it meets specification.
 You may still have to pay the supplier, but you will
not incur any costs to implement it.

What is TESTING?

 Whenever people are asked what testing is, many of

them say it is to prove the system works.
 This is the key problem with the way UAT is employed
in many organizations, as it is impossible to prove
any system is correct.
 All you can prove is, if a system is wrong. Therefore a
good test is one that is designed to try and make a
system fail, so as to expose its faults before it goes
live.

Test Condition

 A Test Condition is derived from a requirement or

specification.
 It includes all possible combinations and validations
that can be attributed to that
requirement/specification.

Test Case

 A Test Case gives values / qualifiers to the attributes

that the test condition can have. Test cases, typically,
are dependant on data / standards.
 A Test Case is the end state of a test condition, i.e., it
cannot be decomposed or broken down further.
 Test case is a description of what to be tested, what
data to be given and what actions to be done to
check the actual result against the expected result.
What are the items of test case?
Test case items are:
• Test Case Number
• Pre-Condition
• Description
• Expected Result
• Actual Result
• Status (Pass/Fail)
• Remarks.

What are the characteristics of good test case?

A good test case should have the following:

• TC should start with “what you are testing”.
• TC should be independent.
• TC should not contain “If” statements.
• TC should be uniform.
E.g.. <Action Buttons>, “Links”…

Test Script

A Test Script contains the Navigation Steps, Instructions,

Data and Expected Results required to execute the test
case(s).

Type of Testing

GUI Testing
Functional Testing
Backend Testing
Regression Testing
Performance Testing
Interface Testing

Why Do User Acceptance Testing?

  The short answer is to protect the organization from
harm. Any changes in a business, and especially
installing new computer systems, expose it to many
risks
 Therefore the main reason for UAT is to find out what
a system will do to your organization before you
implement it.
 Then make the decision based on the evidence
presented by the testing.

Difference between IST & UAT

Particulars IST UAT

Baseline Functional Business
Document Specification Requirement

Data Simulated Live Data

Environment
Controlled Simulated Live

Functionality User Style

Perspective

Location Off Site On Site

Tester Tester Company Test Company & Real

Composition Users

Purpose Validation &

Verification User Need

Load Testing
  Testing a system by increasing the load i.e., by
creating many virtual users. The response time will
be calculated.
 The creation of a simulated "load" on a real computer
system by using virtual users who submit work as
real users would do at real client workstations and
thus "testing" the system's ability to support such a
workload. The virtual users are in software running
on a "driver machine" or "injector".

Stress Testing

Testing a system by varying the resources, i.e., by

reducing memory, or by increasing the duration and
calculating the response time and see at point exactly the
system breaks down.

Regression Testing

“Regression Testing is the process of testing the changes

to computer programs to make sure that the older
programs still work with the new changes.”
“When making improvements on software, retesting
previously tested functions to make sure adding new
features has not introduced new problems.”
Seven Steps Test Methodology

Key Task –1 : Risk Analysis

Risk’s associated with projects are analyzed and mitigation’s are

documented. Types of risk that are associated are –

–Schedule Risk: Factors that may affect the schedule of testing are
discussed.
–Technology Risk: Risks on the hardware and software of the
application are discussed here
–Resource Risk: Test team availability on slippage of the project
schedule is discussed.
–Support Risk: Clarifications required on the specification and
availability of personnel for the same is discussed.

Key Task –2:Test Planning

 Kick of meeting
 Developing Test Strategy
 Assigning Responsibilities
 Application Understanding
 Internal Presentation

Test Strategy

 Indicates HOW testing is to be carried out

 Indicates WHERE to emphasize so that best possible
use of resource and time can be made.
 Makes testing process manageable by providing
structured approach.
 Addresses most of the risk and different types of test.

Key Task –3 : Test Design

•Test Condition
•Test Case
•Test Script
•Data Guidelines
•Activity Schedule
•Trace ability Matrix

Key Task – 4 : Test Execution

–Set up system test environment.

–Establish test data bed.
–Identify test cases.
–Identify test cycles
–Performing necessary activities to execute testing in
accordance with the test plan and test design.
–Analyze test run results
–Logging test activities
–Documenting defects including supporting evidence.

Key Task – 5: Defect Tracking & Management

Defect Recording
•Defect recording to describe and quantify deviations from
requirements.
Defect Reporting–
•Reporting the status of Defects including Severity and
location.
•
Defect Tracking –
•Monitoring Defects from the time of recording until
satisfactory resolution has been determined
Defect Recording

Defects are recorded for following purposes -

•To correct defect.
•To report status of the application
•To gather statistics used to develop defect expectations
in future application.
•To improve the software development process.
Defect Status
Defect Status

•Raised
When defect is found, it will be in raised status.
•Authorized
When Client authorizes as a defect then the status
Will change as authorized.
•Fixed
When developer fixes the defect, then the status
Will change as fixed
•Deferred
If Client takes the call and defer it for next release,
Then it is Deferred Status.
•Re-raised
If defect reappears in re test, then it is re-raised
Status.

Defect Severity

•Critical
The impact of this defect is severe and the system cannot go
to Production Environment or for User Acceptance Testing without
resolving the defect.
• Major
The Impact of this defect is severe, however an interim solution is
available. The defect neither should nor hinder the test process.

• Minor
All defects that are not in the ‘X’ or ‘C’ Category.

Key Task – 6 : Quantitative Measurement

 Metrics specific to testing include data collected during

testing, defect tracking

Test Metrics

The following measurements generated during testing –

–Total no of tests
–Number of tests executed to date
–Total number of defects corrected in each activity
–Total number of defects detected in each activity
–Average duration between defect detection and defect correction
–Total number of defects remaining at delivery

Defect Metrics

Defects per thousand lines of Code

Defects Resolution
[Closed, Deferred, Raised, Open]
Root Cause Analysis.
Defect Distribution by Severity.
Defect distribution by Defect Type.

Key Task – 7: Test Closure

•Executive Summary
•Test Overview
•Trace ability Matrix
•Test Execution Summary
•Features not tested
•Defect Summary
•Defect Matrix
•Defect Analysis
Trace ability Matrix to be maintained

Throughout the testing life cycle of the project trace ability

matrix has been maintained to ensure the verification and
validation of the testing is complete.
 Example of Trace ability Matrix

Your role

Understanding the Application

Preparation of Clarification Document
Internal Presentation
Identify Scope of work
Estimate the number of Functional points, screens, fields
etc.
Derive Test Condition
Derive Test Case
Preparation of Test Data
Derive Test Script
Prepare Defect Log
Maintain Defect Log
Report Defects