Improve Your Science

1. TEST DESIGN TECHNIQUES
By : Y.A Obbi Ikhsan
Backlink ke website resmi :
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/

2. UNIVERSITAS ISLAM NEGERI SULTAN
SYARIF KASIM RIAU
FAKULTAS SAINS DAN TEKONOLOGI
Nama : Y.A Obbi Ikhsan
Nim : 11453106082
Jurusan : Sistem Informasi

3. IDENTIIDENTIFY ING TEST CONDITIONS AND DESIGNING
TEST CASES FYING TEST CONDITIONS AND DESIGNING
TEST CASES
 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. IEEE 829 STANDARD :
TEST PROCEDURE SPECIFICATION
TEMPLATE
2. 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)
• Explain the characteristics and differences between specification-
based testing, structure-based testing and experience-based testing.
(K2)

5. INTRODUCTION
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. SPECIFICATION-BASED OR BLACK-BOX TECHNIQUES
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 AND
BOUNDARY VALUE ANALYSIS
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 ?
• 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. DECISION TABLE TESTING
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
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. 2. TEST MANAGEMENT
• 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. DEFINING THE SKILLS TEST
STAFF NEEDDoing 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. TEST PLANS ,ESTIMATES AND
STRATEGIES
• 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. TEST PROGRESS MONITORING AND
CONTROL
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. 3. TOOL SUPPORT FOR
TESTING
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. EFFECTIVE USE OF TOOLS :
POTENTIAL BENEFITS AND
RISKS
• 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. RISKS OF USING TOOLS
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
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
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)