hello, This is My Presentation welcome and be happy my slideshare

1.  Nama : Suci Maisaroh
 Prodi : Sistem Informasi (S1)
 Fakultas : Sains dan Teknologi
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/
Test design techniques
UNIVERSITAS ISLAM NEGERI SULTAN SYARIF KASIM RIAU

2.  Formality of test documentation
 Test analysis: identifying test conditions
 Test design: specifying test cases
 Test implementation: specifying test procedures or scripts
 CATEGORIES OF TEST DESIGN TECHNIQUES
 Static testing techniques
 Specification-based (black-box) testing techniques
 Structure-based (white-box) testing techniques
PRESENTATION

3. A. Formality of test documentation
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.

4. B. Test analysis: identifying test
conditions
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.

5. C. Test design: specifying test cases
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, mid-
west area, pay-as-you-go, and credit of less than $10).

6. D. Test implementation: specifying test
procedures or scripts
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.

7. E. CATEGORIES OF TEST
DESIGN TECHNIQUES
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

8. F. Static testing techniques
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.

9. G. Specification-based
(black-box) testing
techniques
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.

10. H. Structure-based (white-box)
testing techniques
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 'glass-
box' 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.

11. THANK YOU FOR WATCHING!
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/