1. CATEGORIES OF TEST DESIGN TECHNIQUES Recall reasons that both specification-based (black-box) and structure-based (white-box) approaches to test case design are useful, and list the common techniques for each. (K1)

1. Novika DamaiYanti
Fakultas Sains &Technologi

2. Novika DamaiYanti
Fakultas Sains &Technologi
FAKULTAS SAINS DANTEKONOLOGI UNIVERSITAS
ISLAM NEGERI SULTAN SYARIF KASIM RIAU

3. Differentiate between a test design specification, a test
case specification and a test procedure specification. (Kl)
Compare the terms test condition, test case and test
procedure. (K2)
Write test cases: (K3)
a showing a clear traceability to the requirements;
b containing an expected result.
Translate test cases into a well-structured test procedure
specification at a level of detail relevant to the knowledge
of the testers. (K3)
Write a test execution schedule for a given set of test
cases, considering prioritization, and technical and logical
dependencies. (K3)

4. 2. CATEGORIES OFTEST DESIGNTECHNIQUES
▪ Recall reasons that both specification-based (black-
box) and structure-based (white-box) approaches to
test case design are useful, and list the common
techniques for each. (K1)
▪ Explain the characteristics and differences between
specification-based testing, structure-based testing
and experience-based testing. (K2)

5. 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 techniques),
structure-based (white-box or structural techniques) and
experience-based. Specification-based techniques include
both functional and non-functional techniques (i.e.
quality characteristics).The techniques covered in the
syllabus are summarized in Figure 4.1

7. 1) Write test cases from given software models using
the following test design techniques. (K3)
a. equivalence partitioning;
b. boundary value analysis;
c. decision tables;
d. state transition testing.
2) Understand the main purpose of each of the four
techniques, what level and type of testing could use
the technique, and how coverage may be measured.
(K2)
3) Understand the concept of use case testing and its
benefits. (K2)

8. Equivalence partitioning (EP) is a good all-round
specification-based black-box technique. It can be
applied at any level of testing and is often a good
technique to use first. It is a common sense
approach to testing, so much so that most testers
practise it informally even though they may not
realize it. However, while it is better to use the
technique informally than not at all, it is much
better to use the technique in a formal way to
attain the full benefits that it can deliver. This
technique will be found in most testing books,
including [Myers, 1979] and [Copeland, 2003].

9.  Boundary value analysis (BVA) is based on testing at the boundaries between
partitions. If you have ever done 'range checking', you were probably using the
boundary value analysis technique, even if you weren't aware of it. Note that we
have both valid boundaries (in the valid partitions) and invalid boundaries (in the
invalid partitions).
 As an example, consider a printer that has an input option of the number of
 To apply boundary value analysis, we will take the minimum and maximum
(boundary) values from the valid partition (1 and 99 in this case) together with
copies to be made, from 1 to 99.

10. Why use decision tables?.
A decision table is a good way to deal with
combinations of things (e.g. inputs). This technique is
sometimes also referred to as a 'cause-effect' table.
The reason for this is that there is an associated logic
diagramming technique called 'cause-effect graphing'
which was sometimes used to help derive the decision
table (Myers describes this as a combinatorial logic
network [Myers, 1979]). However, most people find it
more useful just to use the table described in
[Copeland, 2003].

11. State transition testing is used where some aspect of the
system can be described in what is called a 'finite state
machine'. This simply means that the system can be in a
(finite) number of different states, and the transitions from
one state to another are determined by the rules of the
'machine'. This is the model on which the system and the
tests are based. Any system where you get a different
output for the same input, depending on what has
happened before, is a finite state system. A finite state
system is often shown as a state diagram (see Figure 4.2).

13.  TEST ORGANIZATION
▪ Recognize the importance of independent testing.
(Kl)
▪ List the benefits and drawbacks of independent
testing within an organ ization. (K2)
▪ Recognize the different team members to be
considered for the creation of a test team. (Kl)
▪ Recall the tasks of typical test leaders and testers. (Kl)

14. Doing testing properly requires more than defining the right positions and number of
people for those positions.Good test teams have the right mix of skills based on the
tasks and activities they need to carry out, and people outside the test team who are
in charge of test tasks need the right skills, too. People involved in testing need basic
professional and social qualifications such as literacy, the ability to prepare and
deliver written and verbal reports, the ability to communicate effectively, and so on.
Going beyond that, when we think of the skills that testers need, three main areas
come to mind:
 Application or business domain: A tester must understand the intended behavior,
the problem the system will solve, the process it will automate and so forth, in
order to spot improper behavior while testing and recognize the 'must work'
functions and features.
 Technology: A tester must be aware of issues, limitations and capabilities of the
chosen implementation technology, in order to effectively and effi ciently locate
problems and recognize the 'likely to fail' functions and features.
 Testing:A tester must know the testing topics discussed in this book - and often
more advanced testing topics - in order to effectively and efficiently carry out the
test tasks assigned.

15.  Recognize the different levels and objectives of test planning. (Kl)
 Summarize the purpose and content of the test plan, test design
specifi
 cation and test procedure documents according to [IEEE 829]. (K2)
 Recall typical factors that influence the effort related to testing. (Kl)
 Differentiate between two conceptually different estimation
approaches:
 the metrics-based approach and the expert-based approach. (K2)
 Differentiate between the subject of test planning for a project, for
indi
 vidual test levels (e.g. system test) or specific test targets (e.g.
usability
 test), and for test execution. (K2)
 List test preparation and execution tasks that need planning. (Kl)
 Recognize and justify adequate exit criteria for specific test levels and
 groups of test cases (e.g. for integration testing, acceptance testing
or
 usability testing). (K2)

16. Recall common metrics used for monitoring test
preparation and execution. (Kl)
▪ Understand and interpret test metrics for test
reporting and test control (e.g., defects found and
fixed and tests passed and failed). (K2)
▪ Summarize the purpose and content of the test
summary report document according to [IEEE 829].
(K2)

17. The tools described in this chapter are not the
only tools that a tester can make use of.You
may not normally think of a word processor or
a spreadsheet as a testing tool, but they are
often used to store test designs, test scripts or
test data.Testers may also use SQL to set up
and query databases containing test data.Tools
used by developers when debugging, to help
localize defects and check their fixes, are also
testing tools.

18. ▪ Summarize the potential benefits and risks of test
automation and tool support for testing. (K2)
▪ Recognize that test execution tools can have different
scripting techniques, including data-driven and
keyword-driven. (Kl)

19. Although there are significant benefits that can be achieved using tools to
support testing activities, there are many organizations that have not
achieved the benefits they expected.
Simply purchasing a tool is no guarantee of achieving benefits, just as
buying membership in a gym does not guarantee that you will be fitter.
Each type of tool requires investment of effort and time in order to achieve
the potential benefits.
There are many risks that are present when tool support for testing is intro-
duced and used, whatever the specific type of tool. Risks include:
 unrealistic expectations for the tool;
 underestimating the time, cost and effort for the initial introduction of a
tool;
 underestimating the time and effort needed to achieve significant and
con tinuing benefits from the tool;
 underestimating the effort required to maintain the test assets
generated by the tool;
 over-reliance on the tool.

20. Static analysis tools are very useful to developers, as they can
identify potential problems in code before the code is executed
and they can also help to check that the code is written to
coding standards.
When a static analysis tool is first introduced, there can be some
problems. For example, if the tool checks the current coding
standard against code written several years ago, there may be a
number of things found in the old code that fail to meet the new
coding standard now in place. If the old code has been working well
for years, it is probably not a good idea to change it just to satisfy the
new coding standard (unless changes are necessary for some other
reason). There is a risk that the changes to meet the new standard
may have inadvertent side-effects which may not be picked up by
regression testing.

21. Test management tools can provide a lot of
useful information, but the informa- tion as
produced by the tool may not be in the form
that will be most effective within your own
context. Some additional work may be needed
to produce interfaces to other tools or a
spreadsheet in order to ensure that the
informa- tion is communicated in the most
effective way.

22. Referensi : Graham et.al (2011)