Test Analysis

1 Overview
This activity is normally performed during the requirements\design
specification phase. It allows the testing team to understand what needs
to be tested and validate the design against the user requirements.

The key task for this activity is the review of requirements, functional and\or technical
specifications in order to remove any ambiguity, ensure completeness, clarity and
consistency.

2 Inputs
• Requirements Specifications
• Functional Specifications
• Technical Specifications

Note: The above inputs might not exist for all projects. If this is the case, a
series of meetings with the Developer or Business Analyst should be
conducted to generate the Test Basis.

3 Roles
Role Role Type

Test Analyst Responsible

Business Analyst Participant

4 Task
• Identify and review Test Basis
• Conduct walkthrough with document owner
• Create Functional Hierarchy
• Prepare Test Condition Traceability Matrix
• Identify the risks level
• Confirm testing depth and coverage

5 Deliverables
• Issue Log
• Test Conditions Traceability Matrix

6 Detail Task Description

6.1 Identify and Review Test Basis
Test basis refers to the documents used to determine the expected results
of the system. A system is made of a series of functions, it is crucial for
the tester to understand how these functions support the business
processes from a user perspective.

During this task, the tester must review the test basis, also known as
static testing, and search for any inconsistencies, ambiguities or missing
information in the specification. It is believed that up to 70% of errors can
be traced back to issues that could have been picked up during static
testing.

Static testing consists of validating the document in the following ways:

• Is it ambiguous?
• Is it consistent within itself?
• Is it complete?
• Is it free of errors?
• Is it feasible?
• Is it testable?

All issues with the specifications must be logged in the issue log and sent
to the relevant Business Analyst at the end of the review process.

6.2 Conduct walkthrough with document owner

After document has been reviewed, a session should be organised with
the document owner to go through the issues\questions found during
static testing.

6.3 Create Functional Hierarchy

The system under test is broken down into high-level business functions,
in order to create a Functional Hierarchy. The functions and sub functions
are included in the TCM to group requirements and business rules.
The level or functional breakdown depends upon the level of testing being
performed. A typical Function for a unit tester may a program, or module
within a program (depending on the level of testing); for a system tester
an example of a Function would be a single business event and for a user
acceptance tester, a typical Function is a business process i.e.:

• Unit – Field validation

• System – Add account, Add customer
• User Acceptance – Transaction processing

Functional Hierarchy (Example)

1. Customer Processing
1.1 Add Customer
1.2 Update Customer
2. Account Processing
2.1 Add Account
2.2 Update Account
The level at which Functions are created depends on the level at which
you are testing
Need to ensure that Non-Functional attributes are also included such as
Performance, Security, Usability, Recovery etc.

Creating a functional Hierarchy allows the tester to break down and

organise the system into functions and sub functions for detail
analysis. Some of the benefits of doing this:

• It reflects the design of the specification document

• Allows quick identification of gaps and overlaps
• Identifies key functions quickly

6.4 Prepare Test Condition Traceability Matrix

The purpose of the TCM (Test Conditions Traceability Matrix) is to extract,
map and cross reference the testable functions specified in the Test basis.
Each function might contain a series of test conditions; this might include
some negative and positive conditions. The TCM provides the reviewer
with insight into the depth and coverage of the testing to be conducted.
Refer to section 8 Guidelines for more information on how to write test
conditions.

Example of TCM:

Document Document Section Function Test Condition Priority

Reference Description
DOC1 SEC1 Function1 TC1 H
DOC2 SEC1 Function2 TC2 H
TC3 H
TC4 M
TC5 L
DOC2 SEC2 Function3 TC6 L

Refer to the section 7 to find the TCM template.

6.5 Identify the priority level

Not all test conditions in a system have the same priority, for example,
testing that a description field does not allow more than the maximum
characters might not be as important as testing that a calculation is
performed correctly. It is important for the Test Analyst to understand the
impact a failure would have to the user if a particular function did not
work. This also allows the Test Analyst to focus on the functions with the
highest risk to ensure that the appropriate depth is included. The levels
used are High, Medium and Low. High means that a failure will stop the
user from performing a crucial business or commonly used operation
where no workaround exists; Medium means that a function is not crucial
and that a workaround exist. Low means that the failure is found in a nice
to have\infrequently used function and a workaround exists.
6.6 Confirm testing depth and coverage
After the Functions\Requirements\Business rules have been extracted and
mapped to the prioritised test conditions in the TCM, this document
should be reviewed by a Business Analyst or a Developer to ensure that
the test coverage and depth is adequate and relevant.

Guidelines for writing Test Conditions

• A Test Condition is defined as:

“A binary statement that describes a circumstance or set of

circumstances, where behaviour can be observed and validated
against expected results”

In other words a testing condition is a logical statement that when

validated and can have one of two outcomes – it passes or fails.

• A Test condition should be concise, complete and easy to

understand sentence that can be read by anyone with some
business knowledge. In most cases it should be just one sentence
(need to ensure it does not contain any assumptions)

• Literals should be avoided in Test Conditions, as they imply physical

process, a Test Condition should be purely logical. For example the
Test Condition below uses 18 as a literal, the problem occurs when
the age is changed from 18 to say 16. In this situation the Test
Condition will have to be modified. Test Data should not be included
in a Test Condition

Example:

To verify that an age of 18 is accepted by the system

To avoid this situation we use words like minimum or maximum to

define ranges and works like specified to reference other specific
examples

Examples:

To show that the minimum age is accepted by the system

To verify that the system accepts the specified input into the
customer type field.
 • Always assume that the Test Condition will be successful and that
the system will be in a particular state when the Test Condition is
tested. For example, the Test Condition below used the word IF
which implies that the system may be in various states at test time.
D

Example

If the user has the correct privileges then verify that a record can be
added

Identifying Test Conditions from specifications

All specification documents (whether User requirements, Functional

or Technical specifications) contain a series of grouped, related
requirements. As testers we need to translate these requirements
into testable items.

A specification document is made up of a number of elements,

requirements that are further broken down into rules, and from
these rules we derive Test Conditions.

Step1 – Identify the requirements

Example: The age on the c customer screen must only accept a

valid integer number. The age of the customer must be between 18
and 65. If the age is above or below this limit display and error
message. This can be overridden by a user with admin privileges.

Step 2- Identify the rules in the requirements

o Age must be between 18 and 65

o The age on the customer screen must only accept a valid
integer number.
o If age is above or below limit, display and error message
o Override error message if a user has admin privileges

Step 3 – Identify Test Conditions from rules

Age must be between 18 and 65

o To verify the system rejects an age of min-1
o To verify the system accepts an age of min
o To verify the system accepts and age of min+1
o To verify the system rejects an age of max+1
o To verify the system accept an age of max
o To verify the system accepts an age of max-1

The age on the customer screen must only accept a valid integer
number
o The system rejects a lower case alpha
o The system rejects and upper case alpha
o The system rejects a Special character
o The system rejects a lower case alpha
o The system rejects a real number
o The system rejects a negative number