This document discusses different techniques for test design. It covers: 1. The formality of test documentation, from very formal with extensive documentation to very informal with no documentation. 2. Test analysis, which identifies test conditions by looking at the test basis such as requirements or code. 3. Test design, which specifies exact test cases based on the identified test conditions. 4. Test implementation, which groups test cases and specifies the steps to execute each test. It then categorizes test design techniques as either static techniques, specification-based/black-box techniques, or structure-based/white-box techniques. Static techniques do not execute code, while the other two are dynamic techniques.

1. T e s t D e s i g n T e c h n i q u e s
T E S T I N G I M P L E M E N T A S I S I S T E M

2. INTRODUCTION

3. The Power of PowerPoint | thepopp.com 3
Program Studi S1 Sistem Informasi
Fakultas Sains dan Teknologi
UIN Sultan Syarif Kasim Riau
2017
http://sif.uin -suska.ac.id/
http://fst.uin -suska.ac.id/
http://www.uin -suska.ac.id/
REGINA KHALIDA

4. The Power of PowerPoint | thepopp.com 4
Formality of test
documentation
Test analysis: identifying
test conditions
Test design: specifying test
cases
Test implementation:
specifying test procedures
or scripts
1 2
3 4

5. The Power of PowerPoint | thepopp.com 5
Categories Of Test Design
Techniques Static testing techniques
Specification-based (black-
box) testing techniques
Structure-based (white-box)
testing techniques
5 6
7 8

6. Testing may be performed with varying
degrees of formality. Very formal testing would
have extensive documentation which is well
controlled, and would expect the documented
detail of the tests to include the exact and
specific input and expected outcome of the
test. Very informal testing may have no
documentation at all, or only notes kept by
individual testers, but we'd still expect the
testers to have in their minds and notes some
idea of what they intended to test and what
they expected the outcome to be. Most people
are probably somewhere in between! The right
level of formality for you depends on your
context: a commercial safety-critical application
has very different needs than a one-off
application to be used by only a few people for
a short time.
Formality of
test
documentation
6

7. Test analysis is the process of looking at
something that can be used to derive test
information. This basis for the tests is called the
'test basis'. It could be a system requirement, a
technical specification, the code itself (for
structural testing), or a business process.
Sometimes tests can be based on an experienced
user's knowledge of the system, which may not be
documented. The test basis includes whatever the
tests are based on. This was also discussed in
Chapter 1. From a testing perspective, we look at
the test basis in order to see what could be tested
– these are the test conditions. A test condition is
simply something that we could test. If we are
looking to measure coverage of code decisions
(branches), then the test basis would be the code
itself, and the list of test conditions would be the
decision outcomes (True and False). If we have a
requirements specification, the table of contents
can be our initial list of test conditions.
Test
analysis:
identifying
test
conditions
7

8. Test conditions can be rather vague, covering
quite a large range of possibilities as we saw
with our mobile phone company example (e.g.
a teenager in the mid-west), or a test condition
may be more specific (e.g. a particular male
customer on pay-as-you-go with less than $10
credit). However when we come to make a test
case, we are required to be very specific; in
fact we now need exact and detailed specific
inputs, not general descriptions (e.g. Jim
Green, age 17, living in Grand Rapids,
Michigan, with credit of $8.64, expected result:
add to Q4 marketing campaign). Note that one
test case covers a number of conditions
(teenager, male, midwest area, pay-as-you-go,
and credit of less than $10).
Test design:
specifying test
cases
8

9. The next step is to group the test cases in a
sensible way for executing them and to specify
the sequential steps that need to be done to
run the test. For example, a set of simple tests
that cover the breadth of the system may form
a regression suite, or all of the tests that
explore the working of a given functionality or
feature in depth may be grouped to be run
together.
Some test cases may need to be run in a
particular sequence. For example, a test may
create a new customer record, amend that
newly created record and then delete it. These
tests need to be run in the correct order, or
they won't test what they are meant to test.
Test
implementatio
n: specifying
test
procedures or
scripts
9

10. C a t e g o r i e s o f
Te s t
D e s i g n
Te c h n i q u e s
10
Each testing technique falls into one of a
number of different categories. Broadly
speaking there are two main categories,
static and dynamic. Static techniques
were discussed in Chapter 3. Dynamic
techniques are subdivided into three
more categories: specification-based
(black-box, also known as behavioral.

11. As we saw in Chapter 3, static testing techniques
do not execute the code being examined and are
generally used before any tests are executed on
the software. They could be called non-execution
techniques. Most static testing techniques can be
used to 'test' any form of document including
source code, design documents and models,
functional specifications and requirement
specifications. However, 'static analysis' is a tool-
supported type of static testing that concentrates
on testing formal languages and so is most often
used to statically test source code.
Static testing
techniques
11

12. The first of the dynamic testing techniques we
will look at are the specification-based testing
techniques. These are also known as 'black-
box' or input/output-driven testing techniques
because they view the software as a black-box
with inputs and outputs, but they have no
knowledge of how the system or component is
structured inside the box. In essence, the
tester is concentrating on what the software
does, not how it does it.
Specification -
based
(black-box)
testing
techniques
12

13. Structure-based testing techniques (which are
also dynamic rather than static) use the
internal structure of the software to derive test
cases. They are commonly called 'white-box'
or 'glassbox‘ techniques (implying you can see
into the system) since they require knowledge
of how the software is implemented, that is,
how it works. For example, a structural
technique may be concerned with exercising
loops in the software. Different test cases may
be derived to exercise the loop once, twice,
and many times. This may be done regardless
of the functionality of the software.
Structure-based
(white-box)
testing
techniques
13

14. THANK YOU!