Diktat

Testing and Implementation

Lecturers Course : Padeli, M.Kom.

Compiled by :
1411483202 Winda Larasati

College of Management and Computer Science

(STMIK) Raharja
2016

PREFACE

Praise we pray to God Almighty, who has mercy abundant, so the compiler can resolve this
diktat well according to ability. This diktat entitled "Testing and Implementation" prepared to
fulfill the tasks subjects testing and implementation.
In writing this diktat, the author would like to thank Padeli, M.Kom. as the supervisor of
testing and implementation of courses as well as all those who have provided support to resolve
this diktat.
The author realizes that dictates preparation is far from perfect, hence the suggestions and
constructive criticism very authors expect to improve in the future. Hopefully the author of this
diktat hopefully useful for writers and students STMIK and AMIK College of Raharja.

TABLE OF CONTENTS

PREFACE ....................................................................................................................... i
TABLE OF CONTENTS .............................................................................................. ii
CHAPTER I

INTRODUCTION

I.1

Definition Testing ................................................................................................... 1

I.2

Simple Definition Quality ...................................................................................... 3

I.3

Relationship Testing and Quality ........................................................................... 3

I.4

Quality Factor in General ....................................................................................... 4

I.5

Software Quality Essential for Organizational Software ....................................... 5

CHAPTER II

BASICS OF TESTING

II.1 Objectivity Testing ................................................................................................. 7

II.2 The mission of Team Testing ................................................................................. 7
II.3 Psychological Testing ............................................................................................. 7
II.4 Testing Principles ................................................................................................... 8
II.4.1

Testing complete unlikely ............................................................................. 8

II.4.2

Testing is creative and difficult work ........................................................... 10

II.4.3

important reason for the holding of testing ................................................... 11

II.4.4

Testing based on risk ..................................................................................... 11

II.4.5

Testing must be planned ............................................................................... 12

II.4.6

Testing need freedom .................................................................................... 13

II.5 Moto Testing .......................................................................................................... 13

II.6 Issues around Testing ............................................................................................. 14
II.6.1

The system's "Buggy" ................................................................................... 14

II.6.2

Testing displayed with a scary picture .......................................................... 15

II.6.3

Deadline become an obstacle to testing ........................................................ 15

II.6.4

Testing is not an organization and science .................................................... 15

II.6.5

Management support for testing less than ideal ............................................ 15

II.6.6

Testing does not appear as a promising career ............................................. 16

II.6.7

Old or new technologies complicate the situation ........................................ 16

ii

II.7 Testability ............................................................................................................... 17

II.7.1

Operability .................................................................................................... 17

II.7.2

Observability ................................................................................................. 17

II.7.3

Controllability ............................................................................................... 17

II.7.4

Decomposability ........................................................................................... 18

II.7.5

Simplicity ...................................................................................................... 18

II.7.6

Stability ......................................................................................................... 18

II.7.7

Understandability .......................................................................................... 18

II.8 Tester Capabilities Expected .................................................................................. 20

II.9 Personality Tester ................................................................................................... 21
II.10 Understanding of Software Defect ......................................................................... 23
II.11 Costs Related to Testing and Defects ..................................................................... 23
II.11.1 Costs for testing ............................................................................................ 24
II.11.2 Costs defects ................................................................................................. 24
II.11.3 Balancing Cost .............................................................................................. 26
II.12 Lifecycle Software in General ................................................................................ 28
II.13 Lifecycle Testing in General .................................................................................. 29
II.14 Testing Activity in General .................................................................................... 29
II.15 Three Levels of Testing in General ........................................................................ 30
II.15.1 unit testing in general practice ...................................................................... 30
II.15.2 system testing in general practice ................................................................. 31
II.15.3 acceptance testing in general practice ........................................................... 31
CHAPTER III DESIGN TEST CASE
III.1 Definition Test Case ............................................................................................... 33
III.2 White Box Testing .................................................................................................. 33
III.2.1

Scope Statement, Branch and Line ............................................................... 34

III.2.2

Basis Path Testing ......................................................................................... 38

III.2.3

Cyclomatic Complexity ................................................................................ 40

III.2.4

Graph Matrix ................................................................................................. 42

III.2.5

Control Structure Testing .............................................................................. 43

iii

III.2.6

Data Flow Testing ......................................................................................... 49

III.2.7

Loop Testing ................................................................................................. 51

III.2.8

Lines of Code ................................................................................................ 53

III.2.9

Halsteads Metrics ......................................................................................... 53

III.3 Black Box Testing .................................................................................................. 53

III.3.1

decomposition needs to be tested systematically .......................................... 54

III.3.2

Graph Method Based Testing ....................................................................... 56

III.3.3

Equivalence Partitioning ............................................................................... 59

III.3.4

Boundary Value Analysis ............................................................................. 66

III.3.5

Cause-Effect Graphing Techniques .............................................................. 70

III.3.6

State Transition Testing ................................................................................ 72

III.3.7

Orthogonal Array Testing ............................................................................. 74

III.3.8

Functional Analysis ....................................................................................... 77

III.3.9

Use Cases ...................................................................................................... 85

III.4 Other Techniques .................................................................................................... 89

III.4.1

Comparison Testing ...................................................................................... 89

III.4.2

Test Factor Analysis ...................................................................................... 89

III.4.3

Risk Based Testing ........................................................................................ 90

III.4.4

Syntax Testing ............................................................................................... 90

III.4.5

Cross-Functional Testing .............................................................................. 91

III.4.6

Operational Profiling ..................................................................................... 93

III.4.7

Table & Array Testing .................................................................................. 93

III.5 Use of Test Methods ............................................................................................... 94

CHAPTER IV TESTING STRATEGY
IV.1 Approaches Testing Strategies ............................................................................... 95
IV.1.1 Verification and validation ............................................................................ 95
IV.1.2 Organizing testing software .......................................................................... 96
IV.1.3 software testing strategy ................................................................................ 98
IV.1.4 Criteria compliance testing ........................................................................... 99
IV.2 Issues Testing Strategies ......................................................................................... 101
iv

IV.3 Unit Testing ............................................................................................................ 102

IV.3.1 Things that need to be considered in unit testing .......................................... 102
IV.3.2 unit test procedures ....................................................................................... 104
IV.4 Integration Testing .................................................................................................. 105
IV.4.1 Rational Top-down integration ..................................................................... 106
IV.4.2 Bottom-up testing .......................................................................................... 108
IV.4.3 Regression testing ......................................................................................... 109
IV.4.4 Smoke testing ................................................................................................ 110
IV.4.5 Comments for integration testing .................................................................. 112
IV.4.6 Documentation integration testing ................................................................ 112
IV.5 Validation Testing .................................................................................................. 114
IV.5.1 Criteria validation testing .............................................................................. 114
IV.5.2 configuration Review .................................................................................... 115
IV.5.3 Alpha and beta testing ................................................................................... 115
IV.6 System Testing ....................................................................................................... 116
IV.6.1 Recovery testing ............................................................................................ 116
IV.6.2 Security testing .............................................................................................. 117
IV.6.3 Stress testing ................................................................................................. 117
IV.6.4 Performance testing ....................................................................................... 118
IV.7 Debugging Art ........................................................................................................ 118
IV.7.1 debugging process ......................................................................................... 119
IV.7.2 Consideration psychology ............................................................................. 120
IV.7.3 approach to debugging .................................................................................. 120
REFERENCES ............................................................................................................... 123

CHAPTER I
INTRODUCTION

I.1

Definition Testing
According to Hetzel 1973:
Testing is the process of strengthening of confidence in the performance of a
program or system as expected.
According to Myers 1979:
Testing is the process of executing a program or system intensely to find the error.
According to Hetzel, 1983 (Revised):
Testing is any activity that used to be able to evaluate an attribute or ability of a
program or system and determine whether it has to meet the needs or outcomes.
According to Standard ANSI / IEEE 1059:
Testing is the process of analyzing a software entity to detect differences between the
conditions that existed at the desired conditions (defects / errors / bugs) and evaluate the
features of the software entity.
Some practitioners view of testing, are as follows:
A. Conduct a check on the program specification.
B. Finding a bug in the program.
C. Determining the acceptance of users.
D. Ensure a system is ready for use.
E. Improving confidence in the performance of the program.
F. To show that the program works correctly.
G. Prove that the error does not occur.
H. Recognizing the limitations of the system.
I. Study what can not be done by the system.
J. To evaluate the ability of the system
K. Verification of documents.
L. Ensure that the job has been completed.

Here is the notion of testing associated with the process of verification and validation
of software:
Testing software is the process operate the software in a condition to control, to (1)
verify whether enacted as determined (according to specification), (2) detect an error, and
(3) validation of whether the established specifications already meet the desires or needs
from actual users.
Verification is the checking or testing of entities, including software, for compliance
and consistency by evaluating the results of the needs that have been set. (Are we building
the system right?)
Validation of the system to see the truth, whether the processes that have been
written in the specification is what is really wanted or needed by the user. (Are we building
the right system?)
Error detection: Testing must be oriented to make mistakes intensively, to determine
whether it occurs when not supposed to happen or something that does not happen where
they should exist.
From the definition above, we can see that there are many different views of the
practitioners of the definition of testing. However, in general it was found that testing
should be seen as an activity that is thoroughly and continuously throughout the
development process. Testing the activity of collecting the information needed to evaluate
the effectiveness of work.
So any activity that is used with objectivity to help us in evaluating or measuring an
attribute of software can be termed as a testing activity. Including reviews, walk-throughs,
inspection, and assessment and analysis of existing during the development process. Where
the ultimate goal is to obtain information that can be repeated consistently (reliable) on
what might be around the software with the easiest and most effective ways, among others:
1. Does the software is ready to use?
2. What are the risks?
3. What does it do?
4. What are the limitations?
5. What are these problems?
2

6. What has prevailed as expected?

I.2

Simple Definition Quality

Other definitions are found in some literature, defined as measuring the quality of
software testing.
What is the quality? Similarly, testing, quality understanding for each practitioner
can vary, because the quality is indeed a matter of subjective and abstract. Here are some
simple definition of quality:
According CROSBY:
Quality is the fulfillment of the requirement.
According to ISO-8402:
Quality is the entirety of the features that make the product can satisfy or used as
needed at an affordable price.
According W.E. Perry:
Quality is the fulfillment of the standards.
According to R. Glass:
Quality is the degree of perfection.
According to J. Juran:
Quality is appropriate.

I.3

Relationship Testing and Quality

The definition of quality software is error-free software and bugs in an objective,
timely and funds, according to the needs or desires and treatable (maintainable). Definition
of the word objective is a verification process is structured, planned and recorded /
documented.
Objective approach is necessary because the quality is something that is not real and
subjective. He depends on the customer and other things that influence overall.
Customers on a software development project may include end-users (end-users), the
tester of the customer, the clerk contracts from customers, the management of customers,

shareholders, reviewer of the magazine, and others, where each type of customer will have
the viewpoint of their own to quality.
Testing makes quality can be viewed objectively, because testing is a measure of the
quality of the software. In other words, testing means of quality control (Quality Control QC) and QC measures the quality of the product, while quality assurance (Quality
Assurance - QA) measures the quality of the process used to make a quality product.
However, testing can not ensure the quality of the software, but can provide
confidence or assurance of the software in a certain degree. Because testing is proof in a
controlled condition, in which the software functioned as expected in the test case used.
QA and product development are activities that run in parallel. QA includes a review
of the methods and the development of standards, review of all documentation (not only
for standardization but also verification and clarity). Overall QA also includes validation
code.
The task of QA is a superset of testing. Its mission is to assist in minimizing the risk
of project failure. Each individual QA must understand the causes of project failure and
help the team to prevent, detect and fix problems. Sometimes referred to as the testing team
QA team.

I.4

Quality Factor in General

One thing that is fundamental when talking about quality and how to measure it, is
what factors are becoming the benchmark for that quality. Factors of software quality in
general can be divided into three factors: functionality, engineering, and adaptability.
Whereby the three main factors can also be referred to as the dimensions of the scope of
software quality. And each of these factors will be divided again into component factors in
more detail to better explain it. The following examples illustrate some of the factors that is
often used components:
A. Functionality (Quality Affairs)
B. Truth (correctness)
C. Reliability (Reliability)
D. Usability (Usability)
4

E. Integrity (Integrity)
F. Engineering (Quality In)
G. efficiency (Efficiency)
H. testability (testability)
I. Documentation (Documentation)
J. Structure (Structure)
K. Adaptability (Quality Forward)
L. Flexibility (Flexibility)
M. Reusability (Reusability)
N. Maintainability (Maintainability)
Therefore testing nice to be able to measure all the factors relevant, of course, each
component factors will have different levels of interest between one application with
another application. For example in a common business system usability and
maintainability factor components are key factors, which are techniques for programs that
might not be the key factor.
So that testing can be fully effective, it must be run to perform the measurements of
each factor related and also makes the quality of being real and visible.

I.5

Software Quality Essential for Organizational Software

Naturally the software development is not an easy thing, even have a tendency to fail.
Therefore oriented to quality is one of the efforts in reducing the risk of project failure.
Be aware of statistical data in 1995, the company and the agent of the US
government has spent 81 billion US $ for a software project is canceled, with details as
follows:

31.1% The project was canceled before completion.

52.7% projects experiencing cost overruns amounting to 189% of the estimated

value.

9.0% Project completed on time and on budget.

From the statistical data above shows that in fact the main problem of the quality of

the software is the cost and schedule of the root causes of the problem, namely the
5

engineering capability party software developers are not sufficient, and the ability of
customers who are very poor (not even able) to provide requirements specification of
system.
With quality oriented, then the organization's software will be able to process
analysis, evaluation and continuous development to achieve a software development
process that is increasingly effective, efficient, scalable, controllable, and can be repeated
consistently in producing a product (software) quality , timely and funding.
Where it will provide a guarantee for customers / clients to obtain the product as
expected, so it will increase their confidence in the ability of the developer, it is necessary
for the organization of software for client relations and the development is for the long
term and continuous (marital status).

CHAPTER II
BASICS OF TESTING

II.1 Objectivity Testing

In general, the objectivity of the testing is to do the verification, validation and error
detection to find the problem and the purpose of this invention is to fix it. But there are also
some opinions from practitioners who can also be seen as part of the objectivity of the
testing, among others:
A. Increase the confidence that the system can be used with the level of acceptable risk.
B. Provide information to prevent the repetition of errors that have occurred.
C. Provides helpful information for early error detection.
D. Looking for error and weaknesses or limitations of the system.
E. Looking to what extent the ability of the system.
F. Providing information on the quality of software products.

II.2 The mission of Team Testing

The mission of the testing team is not only to do the testing, but also to help
minimize the risk of project failure.
Tester looking manifestation of product problems, potential problems, and the
presence of the problem. They explore, evaluate, track, and report on the quality of
products, so that more of the project team can make decisions on product development. It
is important that the tester does not make corrections or surgery code, do not embarrass or
make complaints on an individual or a team, just inform. Tester is an individual who
provides the measurement results of the quality of the product.

II.3 Psychological Testing

Testing is an interesting psychology. Where if development is done constructively,
then the testing is destructive. A developer in charge of building, while a tester were
attempting to destroy. Mental like this is important for a tester.

If a designer must instill in his mind deep will testability, programmers should be
oriented to the "zero defect minded", the tester must have a desire that is fundamental to
"prove the code fails (fail), and will do anything to make it fail." So if a tester just want to
prove that the code to act in accordance with its business functions, then the tester has
failed in his duty as a tester.
It is not a statement that conduct testing from a business standpoint is wrong, but in
fact is very important disclosed, because most testing that exist in the organization just
looked at from the point of "proving that the code is working as specified."

II.4 Testing Principles

There are six key principles of testing, namely:
1. Testing is complete is not possible.
2. Testing is creative and difficult work.
3. The reason is important the holding of testing is to prevent the occurrence of errors.
4. Testing based on risk.
5. Testing must be planned.
6. Testing requires independence.
II.4.1

Testing complete unlikely

Testing complete overall it is not possible to do, because the number of
possible combinations of test cases is very great that these possibilities include
considerations of things as follows:
Domain Input:
Domain of possible inputs are numerous, which must be tested all the inputs
valid, all entries were not valid, all entries are edited, all variations of the input
based on the time of the incident, therefore it takes priority in the selection of
domain input from the system to be tested.
Let's say the testing program carried calculator with 10-digit integer, there
will be 1010 and 1010 positive feedbacks negative feedback, for testing against
invalid input. And for no valid input, for example handling of keyboard typing
input alphabet.
8

Complexity:
User interface and design is very complex to do a complete testing. If a
design error occurs, how a tester can declare a bug is a bug when it is in the
specification, and more than that how a tester can recognize that the behavior of
the system is a bug. Validating the program is based on logic is also not possible
because it would be time-consuming, and there are time limits.
Paths Program:
There will be so many paths that may be passed to a program for a complete
test. Eg will be testing the program code as contained in Figure 2.1. Plot all the
lines from the beginning (START) to the end (END). X will be able to go to END
or perform loop back to the A 19 times. There are five Path from A to X, namely:
ABCX, ABDEGX, ABDEHX, ABDFIX, and ABDFJX. Then the whole
combination of lines to be tested is 5 + 52 + 53 + ... + 520 = 1014 (100 trillion).

Therefore realistically test planning was dominated by the need to select a

small number of test cases from around the possibility that very, very much.
Testing is not to validate the program / system, it only proves the existence
of an error with the conditions that have fundamental similarities with the test.
The number of errors in the system can be predicted with a certain accuracy,
but can not guarantee it will be no longer any other error on products other than
had been predicted.
Thorough testing so it is not possible. Calculations that occur in the program
is very large and complex. So it may not perform testing on each possible
combination of the overall calculation. Which probably is doing testing the logic
of the program and make sure all conditions from all levels of the components
have been checked.
II.4.2

Testing is creative and difficult work

Just as the words of Philip Crosby in 1979, according to which the quality
has much in common with sex, so it happened with testing. There is a myth that
one of Testing, wherein:
A. Testing is easy.
B. Each person will be able to do the testing themselves.
C. There is no need of training or experience.
10

Although there is no explicit recognition, but of the actions shown there is a

tendency of practitioners to admit it (implicitly).
When in fact the testing is not a simple matter, because to do effective
testing, should know the whole system. The system is not simple or easy to
understand.
Therefore it is not an exaggeration to say that testing is a difficult job. And
to be successful in doing the testing required important matters as follows:
1. Creativity.
2. Knowledge of business.
3. Experience testing.
4. Testing Methodology.
II.4.3

important reason for the holding of testing

An important reason holding of testing is to prevent error. The concept of
cycles of testing:
A. Testing is not a single phase of development alone.
B. Results of Testing associated to each phase of development.
All testing must be traceable and meet the needs of consumers. As we can
see one of the objectivity of the testing is to fix the error.
It also includes a fault in the eyes of consumers because it does not suit your
needs.

II.4.4

Testing based on risk

Although the overall testing is not possible, but it does not mean that an
effective testing can not be done.
Therefore, testing is the result of the risks and economic considerations,
where practical testing is the result of a push-pull consideration of four main
factors:
1. The resources and costs required to perform testing based on the priority
scale, complexity and difficulty of testing.
2. The cost of delay in delivery of the product (where one is most likely cause
is testing).
11

3. The possibility of the existence of a defect (based on operational experience

and a history of high priority defect).
4. The costs caused by the defect, if the defect causes error that will bring
harm either directly or indirectly to customers (related to business
obligations for developers to losses incurred by the customer).
II.4.5

Testing must be planned

Testing was good need of thought with the overall approach, the design of
the test and the determination of the desired results for each test cases (test case)
are selected.
A document that covers the whole of the purpose of testing and testing
approach called Plan Test (Test Plan), while a document or statement that defines
what you have chosen to be tested and describe the expected results called Design
Test (Test Design).
test plan
Statement testing objectivity

design test
Specification test developed

Description of the test approach

Description grouping tests

A group of tasks to achieve the

objectives of testing

Test plan was made after the model has been created that need. And details
of the test case definition was made after the design approved model. Or in other
words tests are planned and designed before the code is created.
Testing should start from small to large and increasing. The first test plans
and execute focused on the individual components. Implementation of testing
focused on finding errors in the cluster related to the components and the overall
system.
What are the ratings of a particular test correct? Belief in what they can produce
opponents charge that they use for testing.
The discovery of problems and defects. Planning is very important test,
because:
12

A. In order to maintain the direction of the execution of tests in order not to

deviate from the purpose of the test itself, which is to measure the quality
of software.
B. To maintain the appropriateness of using the resources and schedule of the
project, to establish what will be tested and when to stop.
C. To make a good test case (appropriate), to establish what is expected so that
will help the tester to focus on what will be tested.
II.4.6

Testing need freedom

When you want a measurement that is not biased then also needed a tester
that is not biased. What is called Tester independent (non dependent /
independent):
Observers are not biased
People who aim to accurately measure software quality
The most effective testing must be conducted by a third party. Very
effective means of testing found the possibility of errors is very high.
From the description of the 6 principles of testing above, it can be concluded
that the key that affect the performance of the testing are as follows:
1. Insight and creativity of each individual involved.
2. Knowledge and understanding of the application being tested testing
experience.
3. The testing methodology used effort and resources used.

II.5 Moto Testing

Testing is an experiment and requires a specific approach. Experiments began with a
hypothesis experiment designed to be verified or rejected. A good practice is to design the
experiment so that the number of conditions that changed from one moment to the
minimum. The experimental conditions are stored, and the data is processed so that the
experiments can be repeated if needed. Finally, the test data is analyzed to see whether the
hypothesis is proven.

13

Hypothesis tests noticed the types and quantity defect of the program. Then designed
experiments to verify or assess this amount. The views will be reflected in the motto of this
testing testing declared by Myers in 1976:
A good test case that has a high possibility to detect defects that previously
undiscovered and not to show that the program has worked correctly.
One of the most difficult problems in testing is the knowledge of when to stop. It is
impossible to test your own programs.
Parts needed for each test case is a description of the expected output. Avoid testing
unproductive or in the air. Write a test case for a valid condition and is not valid.
Inspection results of each test.
The increasing number of defect detected from a part of the program, the possibility
of the existence of undetected defect also increases. Point your best programmers to do the
testing.
Make sure that the testability is a key objectivity in the design of your software. The
design of the system should like each module is integrated into the system only once.
Never change the program to make testing easier (except the permanent change).
Testing, as every activity of most of the others, testing should also start with objectivity.

II.6 Issues around Testing

Other matters related to testing is as follows:
II.6.1

The system's "Buggy"

This is caused by :
A. System unfavorable development and planned.
B. System inferior services and planned.
C. analysts, designers and programmers do not know how to build a quality
into existing systems.
D. Tester is not much affected by the definition of needs, development or
service process.

14

II.6.2

Testing displayed with a scary picture

It is undeniable that the testing is expensive and requires a great time
activities, and it's true - really scary. Moreover, the error that occurred (such as
determining the measurement attribute incorrect) can backfire, where activities of
testing that has been done will be a thing useless and even make the situation even
more confusing.

II.6.3

Deadline become an obstacle to testing

It is most commonly caused by:
1. Management wants a product launched as soon as possible (ASAP - As
Soon As Possible)
2. There are many ways and things to do in testing within a short time.
Deadline sometimes unrealistic, and the pressure between the launches of
products with faster than with making the correct product.
3. Testing is sometimes too little, too late and unplanned.

II.6.4

Testing is not an organization and science

There is no single person who sure what the testing, who is responsible and
when to do testing, as discussed earlier testing is a matter of subjective and
relative, even just for the definition of testing each practitioner has their own
opinion.
Testing in the implementation and development is highly dependent on the
creativity and experience of each individual.
Each testing approach is new and unique. As the cycle of new discoveries
and greatly influenced by the experience of the previous testing.
This lack of clarity of how to access the effectiveness of testing and quality
resources, and how to calculate the time and resources required by the testing.

II.6.5

Management support for testing less than ideal

There's not much that management put more attention on testing, in fact
most of them consider testing only with one eye. It is caused by a lack of
awareness of the importance of testing for the creation of quality software, or even

15

not aware of the qualities. Besides other cause is the myth that one of the testing
as described above.
II.6.6

Testing does not appear as a promising career

Surely ignorance of the importance of this testing also continues with the
gulf that clearly will award function testing and the culprit, and this happens
especially in the developing countries as well as in Indonesia. So most of the
functionality testing will be attached to the functions of development
(development) with programmers as the culprit, and so it is often equated with
debugging testing figure.
But in an article in ACS (Queensland), April - June 1998, states that request
tester position in IT was ranked top in the same period of last year (144%).

II.6.7

Old or new technologies complicate the situation

The development of computing technologies so rapidly, both from
hardware, software and jarinngan, adds to the difficulty in stabilizing the concepts
of testing both theoretically and practically. This relates to the principles of testing
that has been stated above, which is necessary to perform testing of the knowledge
and understanding of the applications tested.
With the increasingly rapid changes due to the development of computing
technology, it is very difficult to grasp the details of the technology of
applications used, coupled with the tendency of software vendors (eg Microsoft)
that implement strategies versioning of the product launch into the market, the
release version is not necessarily a bug free or have a little bug, not uncommon for
the release version still contains many bugs are quite difficult process of testing
applications that are built based on it.
Similarly, the old technology, it is usually a lot going on in the client's
environment, where the application is implemented. The existence of old
technology is still owned and used by the client, often creates new problems not
found when testing is performed in a developer environment, ultimately the
implementation phase was so delayed accordingly.

16

II.7 Testability
Ideally, software engineers design computer program, system or product by putting
the testability in mind. This will allow the testing to assist in designing a test case effective
and easier.
Simply put, according to James Bach, the testability of software is how easy (a
computer program) can be tested.
Sometimes programmers willing to help the process of testing and a list of items that
may design, features, and others, would be very helpful if it can work with them. Here's a
list of a set of characteristics that can lead to software that can be tested.
II.7.1

Operability
"The better the software works, will make software testing more efficiently."
1. The system has a new bug (bug added indirect costs in the testing process,
with analysis and reporting).
2. No bug that stopped the execution of tests.
3. Product changes in functional phase (allowing simultaneous development
and testing).

II.7.2

Observability
"What you see, is what you test."
1. Results of each output should show the results of the input.
2. Condition and variable system can be viewed or queried during the
execution took place.
3. Conditions and the old system variables can also be viewed or queried.
4. All of the factors that influence the outcomes can be seen.
5. Output wrong can be easily identified.
6. Internal error can be automatically detected by a thorough test mechanism.
7. An internal error is automatically reported.
8. Source code can be accessed.

II.7.3

Controllability
"With the better we can control the software, the more testing can be
automated and optimized."
17

1. All possible output produced from various combinations of inputs.

2. All code is executed from multiple input combinations.
3. Conditions of hardware and software, and variables can be controlled
directly by the test engineer.
4. Input and output formats must be consistent and structured.
5. Testing can be easily specified, automation, and remade.
II.7.4

Decomposability
"By testing the limits of control, we can more quickly isolate problems and
perform testing the better."
1. System software is built from independent modules.
2. The software modules can be tested independently (alone).

II.7.5

Simplicity
"The less tested, the sooner we do it."
1. Simplicity functionality (features that have made a minimum to meet the
existing needs).
2. Simplicity structures (architecture as simple as possible to avoid errors).
3. Simplicity code (standard code is made to be easily inspected and treated).

II.7.6

Stability
"The fewer the changes, the fewer problems / disorders testing."
1. Amendment of the software happens sometimes.
2. A change of software uncontrollable.
3. Amendment of the software can not be validated on an existing test.
4. Software can make improvements to resume running well (recovery) of the
failure of the process.

II.7.7

Understandability
"The more information we have, we will be able to do a better test."
1. The design is easy to understand and well understood.
2. The linkage between internal, external and share component is well
understood.
3. The design changes are communicated.
18

4. Technical documentation can be easily accessed.

5. Technical documentation well organized.
6. Technical documentation contains specifications and details.
7. Technical documentation is accurate.
The attributes above suggested by Bach can be used by software engineers
to develop a software configuration (such as programs, data and documents) that
will be able to help testing.
And what attributes associated with testing itself? Kaner, Falk, and Ngunyen
[KAN93] provide attributes as a good marker testing, namely:
A good testing has a high probability of determining the error. To achieve
this goal, the tester must understand the software and trying to develop a picture in
his mind of how roughly the software will be able to fail (fail). Ideally, classes of
failure sought. For example, one class of failure on a GUI (Graphical User
Interface) is the failure to recognize the position of a certain mouse. A set of tests
designed to run the mouse with the hope to demonstrate an error that has been
identified from the position of the mouse.
A good test is not overlapping (redundant). Time and resources limited
testing. No single point in the implementation of testing that have the same goal
with other testing. Each testing should have different objectives. For example,
SafeHome software modules designed to recognize the user's password from
mengaktifasikan or mandeaktifasikan system. In his efforts to get an error from
the input password, tester design a series of tests to include a password in a
sequential manner. A valid password is not valid and included in the different
tests. However, each password is valid / invalid should find a different failure
modes. For example, an invalid password is 1234 shall not be accepted by the
computer system is programmed to recognize 8080 as a valid password. If this is
accepted, an error occurred. Put another test, ie 1235, would have the same goal
by 1234 is called redundancy. However, the input is not valid 8081 or 8180 have
different objectives, seeks to demonstrate the existence of error for the password
that is almost close / close but not identical with a valid password.
19

A good test should provide the best results [KAN93]. In a test group that has
a limit intentions, the time, the same resource, will execute only a subset of these
tests. In certain cases, the test that has the highest probability of obtaining error
class should be used.
A good test should not be too simple, but not too complex. Although
sometimes makes it possible to combine a series of tests into a single test case, the
possible side effects associated with this approach is that the error is not detected.
Generally, each test must be executed separately.

II.8 Tester Capabilities Expected

When talking about a career testing, although at the moment still lacking a major
concern in any organization based on information technology, but along with the
development of the software development process maturity level, it can be said to have
testing career prospects are quite promising. Ability tester into demand in general:
Ability in general

Have strong analytical skills and focused

Have good communication skills

A background QA

Understanding of the methodology

Development of test plan

Creation and maintenance of the test environment

Standard tests

Documentation of tests (such as test cases and test procedure)

Knowledge of testing approaches

Integration testing

Acceptance Testing Stress / Volume Testing Regression testing

Functional testing

End-To-End Testing

GUI Testing

20

Knowledge of the system (corresponding to the market of the organization concerned)

Banking / Finance

Commercial Products Telecom

Internet Y2K

Knowledge and experience will use testing tools

Tools capture or playback (like WinRunner)

Load testing tool (such as LoadRunner, roboTest)

Ability to testing environments

Mainframe (such as MVS, JCL)

Client - Server (such as WinNT, UNIX)

Ability to application

Documentation (such as office, excel, word, Lorus Notes)

Database (such as Oracle, Access, 3GL, 4GL, SQL, RDBMS)

Programming (such as C ++, VB, OO)

Collard [COL97A] stated that the ability tester can be divided into three major

groups, namely:
1. functional ability of the subject is the reference
2. Basis Technology
3. Engineering - engineering testing and QA

II.9 Personality Tester

The market needs to be a tester other than as disclosed above, should also have more
personality qualities. It is very closely related to the attainment of the success of the testing
process itself, where a tester would be a lot to do with psychology among humans in
cooperating and communicating within a team (especially with developers (developers)), in
addition to his job as a tester that also requires a level of maturity (self-development) are
quite high. Existence of testing will be able to become a boomerang that can destroy the
integrity of teamwork in the organization if they do not get attention and good
management.

21

For that it is necessary to know the attributes of personality that is expected for a
tester, namely:
A. Positive attributes that should be developed
B. Planned, systematic, and be careful (not frivolous) - a logical approach to testing
C. Mentality champions - such as the application of high quality standards in working
on a project
D. resolute - no quitter
E. Practical - be aware of what can be achieved to a certain time limit and budget
F. Analytical - have intiusi in taking an approach to digging errors. Morality - striving
for quality and success, understand and aware of the costs that occur to a lowquality
Negative attributes that should be avoided:
A. A little empathy for developers (developers) - easily affected emotionally childish in
conjunction with developers (developers).
B. Less diplomacy - creating a conflict with developers (developers) to show the face
of a hostile. A tester will smile when face to face with the developers (developers) to
discover the defect, and report defects that accompanied statistical calculations
occurrence of defects and bugs.
C. Skeptics - asking for information from the developers (developers) with suspicion
(not believe).
D. Stubborn - can not be flexible in discussing a proposal.
Besides a tester needs to know the obstacles to be faced in working with developers
(developers), where developers (developers) will generally tend to run away and hide from
it, if they feel things as follows:
A. Believing that the tester would interfere with their work and adding complexity to
the problems caused by the presence of the tester.
B. Fear to discuss matters relating to the development that is being done, where it will
be used to drop them.

22

II.10 Understanding of Software Defect

According to Kaner, Falk and Nguyen [KAN93], there are 13 major categories of
software defect, namely:
A. User interface errors - the system gives a different view of the specification.
B. Error handling - recognition and treatment of error when it occurs.
C. Boundary - related errors - the treatment of the value limits of the reach of those
who might not be true.
D. Calculation errors - arithmetic calculations and logic that may not be true.
E. Initial and later states - function fails at the first use or after it.
F. Control flow errors - the choice of what to do next is not suitable for the current
status.
G. Errors in handling or interpreting the data - skip and convert data between systems
(and possibly a separate component of the system) can lead to error.
H. Race conditions - if the two events will be processed then one will be accepted on a
priority basis until the work is completed well, the new next job. However
sometimes the other events will be processed in advance and can produce something
unexpected or incorrect.
I. Load conditions - when the system is forced to the maximum extent, the problem
will begin to appear, such as arrays, overflow, diskfull.
J. Hardware - interface to a device may not operate properly on a particular condition
such as device unavailable.
K. Source and Version Control - programs that have expired may be unusable if there is
a revision to fix it.
L. Documentation - users are unable to view the operations that are described in the
guidance document.
M. Testing errors - tester made a mistake during testing and think that the system does
not behave properly.

II.11 Costs Related to Testing and Defects

Here are today's costs associated with testing and defects, and balancing these costs.
23

II.11.1 Costs for testing

The costs associated with testing can be seen as contained in the table, below:
Defects Prevention Costs
training staff

Cost Assessment and Evaluation of Defects

analysis of needs

code inspection

Making an initial prototype

Glass-box testing

Design of fault-tolerant

Black-box testing

Defensive programming

training tester

usability analysis

Beta testing

A clear specification

test automation

Internal documentation is accurate

Usability testing

design review

The evaluation of the reliability of Pre-release out-box testing by customer

tools development (before you
staff
buy) or any other component of the
product potential.

Most attribute testing costs spent about 25% of the development. Some
projects may even reach approximately 80% of the development funds (for
reasons outlined below).
II.11.2 Costs defects
Especially for software developers, the costs of defects can be things as
follows:
1. Readiness support technician.
2. Getting Started FAQ guide books.
3. Investigation of customer complaints.
4. Indemnity and take back the product.
5. Coding or testing of revamping bugs.
6. Delivery of products which have been repaired.
7. The addition of costs to support various versions of the product that has
been in release.
8. Public Relations task to explain the review of defects.
24

9. The loss of share sale.

10. The loss of customer confidence.
11. Providing a rebate on the seller to keep them selling products.
12. Warranty.
13. Liability.
14. Investigation government.
15. Penalty.
16. And the other costs associated with the law.
Of research costs Boehm [BOE76A] states that for an air force computer:

The cost of initial software development of $ 75 perinstruksi

Maintenance costs amounted to $ 4,000 perinstruksi
According to the study of Martin and MC Clure [MAR83a] concluded that
the relative costs in each stage of development, as seen in the graph below:

25

Figure 2.3 Costs relative to each phase of development

In this study, testing accounted for 45% of the initial development costs.
Testing is also an integral part of the treatment as well, but the discussion is not
distinguished in particular.
II.11.3 Balancing Cost
Feigenbaum (1991) estimated the cost of each quality for prevention
(prevention) in companies generally costs $ 0.05 to $ 0.1, while for performance
evaluation (appraisal) of $ 0.2 Samapa $ 0.25 and the remaining $ 0.65 to $ 0.75
for the cost of the failure of internal and external.

Figure 2.4 Allocation of costs (in dollars) of quality in general.

The need to balance the cost, so that the expenditures are not on the internal
or external failure is needed. The way to compare the costs of eliminating defects
in relation to the improvement of the overall system.

26

It would be very expensive to do than to correct the defect test, therefore

testing needs to be simplified - usually by applying for an important part of testing
before they become problems.
Defect assumed to be always associated with the cost of repairs, so the total
cost of defect repair increases linearly with the number of defects that exist in the
system. While testing efforts will increase exponentially with the increasing
proportion of defect repaired. This reinforces the view that eliminates the defect is
one hundred percent is not possible, so that complete testing can not be done (as
has been discussed on the principle of testing above

Figure 2.5 Graph relationship testing effort towards the cost of failure.
The graph above can be correlated to the allocation of costs, based on
experience and estimation, or internal measurement and data analysis.
The higher level of critical projects, the cost of defect also increased. This
indicates a lot of resources can be allocated to achieve the proportion of higher
defect removal. As shown below:

27

Figure 2.6 Graph business relationship testing to variations in the cost of failure.

II.12 Lifecycle Software in General

Figure 2.7 software life cycle model

The methodology is a set of phase or task. Most organizations use a standard for
developing software that defines a life cycle model (life cycle model), and the required
stages or methodology in its implementation.
The idea of the division in the form of phases / stages used in all software
methodology, where each phase has a final product which is a sign of deliverables and
completion of the process in each phase.
Distribution of these phases can be different across one organization to another, but
they all have the basic stages of the same, namely Analysis, Design, Implementation and
Maintenance, as shown in Figure 2.7.
28

II.13 Lifecycle Testing in General

Figure 2.8 The life cycle testing

Stages for testing is a component of the overall methodology. In practice, much less
didiskripsikan testing and has quickly moved to the point where most organizations testing
procedures are outdated and ineffective.
At the beginning of testing is one of the sub-phase of the development phase
(development), after the coding phase. The system was designed, built and then tested and
debug. Along with the establishment of testing in practice, gradually we found the proper
testing standpoint is to provide a complete life cycle testing, which is a part and become
one entity in the overall software life cycle, as shown in Figure 2.8.

II.14 Testing Activity in General

If we dig more deeply from the life cycle of testing, about what activities are going
on in it, in general, simple consists of:

Planning

Plan for a common approach

Determine objectivity testing

Clarify the general plan

Acquisition Design tests

29

Applying the test

Measurement

Execution of tests

Check termination

Evaluation of the results

II.15 Three Levels of Testing in General

While the kind or type of testing in general there are three kinds, which if we are
mentioned in the order based on the time of use, as follows:
unit testing
Testing writing program codes in the smallest unit individually.
system Testing
The process of testing the integrated system to verify that the system has the appropriate
specifications.
Acceptance Testing
Formal testing conducted to determine whether the system has met the acceptance
criteria and empowers the customer to determine whether the system can be accepted or
not.
II.15.1 unit testing in general practice
Aim
Confirm that the module has been coded correctly.
Doer
Usually programmers.
What are tested
Function (Black Box).
Code (White Box).
The extreme conditions and restrictions.
When is finished
Usually when programmers have been satisfied and no longer known errors.
AIDS
30

 Not used.
Data
usually not recorded.
II.15.2 system testing in general practice
Aim
Assembling modules into a system that works.
And determine readiness to do Acceptance Test.
Doer
The team leader or group of tests.
What are tested
The need for and function of the system.
Interface system.
When is finished
Usually, if the majority requirement is appropriate and there are no major
errors were found.
AIDS
System test case libraries and library.
Generator, the comparator and the data simulator testing.
Data
Data errors are found.
Test case.
II.15.3 acceptance testing in general practice
Aim
Evaluate readiness for use.
Doer
The end user or dealer.
What are tested
major functions.
Documentation.
Procedures.
31

When is finished
Normally when a user has been satisfied or test runs smoothly / success.
AIDS
comparator.
Data
Formalities document.

32

CHAPTER III
DESIGN TEST CASE

III.1 Definition Test Case

Test case is a test that is based on an initialization, input, condition or outcome
predetermined. The usefulness of this test case, are as follows:
To continue testing the suitability of a component of the specification - Black Box
Testing.
To continue testing the suitability of a component of the design - White Box Testing.
Things to keep in mind that testing can not prove all the possible execution of a
program. However it can be approached with the planning and design of a good test case so
as to guarantee the effectiveness of the software to a certain extent as expected.

III.2 White Box Testing

Sometimes called glass box testing or clear box testing, is a test case design method
that uses the control structure of the procedural design. This test case design method can
guarantee:
All paths (path) of independent / separate tests can be tested at least once.
All of the decision logic can be tested with the wrong path or the right path.
All loops can be tested to the limit and bonding operations.
All the internal structure of the data can be tested to ensure its validity.
Often white box testing associated with the measurement of test coverage (test
coverage metrics), which measures the percentage of lines of type are selected for
each to be executed by the test cases.
Why do white-box testing when the black box testing function for testing compliance
with the requirements / specifications?
Logic errors and incorrect assumptions mostly done when coding for the "specific
case". It takes a certainty that the execution of this pathway has been tested.
The assumption that the possibility of the execution path that is not true.
With white box testing can be found these errors:
33

 Error writing random.

Such logic is on track to confuse the normal path.
The above argument is the mistakes that can not be found by using black box testing
the best ones.
III.2.1 Scope Statement, Branch and Line
Statement coverage, branch and path is a white box testing technique that
uses the logical flow of the program to create test cases. What is meant by the
logic flow is the way in which a part of a specific program is executed while
running the program.
The logic flow of a program can be represented by the flow graph, which
will be discussed further in the next section (base path testing). As an example can
be seen in the image below.

Figure 3.1 Example of flow graph of a program code.

A flow graph is formed from:
Nodes (point), representing the statement (or sub-program) which will be
reviewed when the execution of the program.
Edges (arrows), representing the program logic flow path for connecting a
statement (or sub-program) to another.
Branch nodes (branch point), points that have more than one dart output.
Branch edges (arrows branch), arrows out of a branch.
Paths (paths), a possible pathway for moving from one point to another in
line with the presence of arrows.
34

The execution of a test case causes the program to execute certain forwardpernyaan, relating to specific paths, as illustrated in the flow graph. Branch
coverage, statements and lines formed from the execution path of the program
relating to the review points, arrows, and lines in the flow graph.
Scope Statement
Statement coverage determined by assessing the proportion of statements
reviewed by a set of test cases to be determined. 100% statement coverage is
when every statement in the program is reviewed at least at least once a test.
Scope statements regarding the review of the points (nodes) on a flow
graph. 100% coverage occurs when all the spots visited by the paths traversed by
the test cases.

Figure 3.2 Example of statement coverage.

Flow graph in the example image above there are 10 points. Suppose a
program execution path passes through the points A, B, D, H, K. Means there are
five points of the 10 points were visited, then the statement coverage of 50%.
Since a single point on the flow graph can be a group of several statements,
therefore the extent of coverage is different from the statement of the actual level
of coverage points (nodes), depending on the way of defining flow graph.

35

Branch coverage
Branch coverage determined by assessing the proportion of branch decisiontested by a set of test cases that have been determined. 100% branch coverage is
where each branch of the decision on the program is reviewed at least at least once
a test.
Branch coverage with regard to the review of arrows branch (branch edges)
of the flow graph. Coverage 100%, when all the arrows branches reviewed by the
paths traversed by the test cases.

Figure 3.3 Example of branch coverage.

Based on the flow graph example image above, there are 6 arrows branches.
Suppose a program execution paths run through the points A, B, D, H, K, then the
line is reviewing 2 of 6 arrows existing branches, so the coverage of 33%.
coverage Path
Coverage of pathways determined by assessing the proportion of program
execution paths are tested by a set of test cases that have been determined. 100%
path coverage is where every track on the program visit at least a minimum of
once a test.
Coverage of pathways associated with the review along the lines flow graph.
Coverage 100%, when all the path traversed by the test cases.

36

Figure 3.4 Example of path coverage.

Based on the sample flow graph above, there are four lanes. When an
execution path of the program through the points A, B, D, H, K, then the
execution reviewing one of the four existing lines, so the coverage of 25%.
Differences Between Scope Statement, Branch & Trails
Achievement of 100% statement coverage can occur without having to
create branch coverage to 100% as well.
Example program:

Figure 3.5 Example of branch coverage 100% but not 100% path coverage.
Can also make 100% branch coverage, by reviewing all of the arrows
branches without having to review all the existing path (path coverage 100%).
Example program:

37

Figure 3.6 Example of arrows branch 100% but not 100% path coverage.
From the example above, it can be seen that it only takes two lines to visit all
the arrows branches, from four lanes that exist in the flow graph.
So if 100% path coverage, it will automatically branch coverage of 100%
anyway. Similarly, if the branch coverage of 100%, then automatically the
statement coverage of 100%.
Design Coverage Tests
To design the scope of the test, please note the following stages:
1. Analyzing the source code to create a flow graph.
2. Identify a test track to achieve compliance tests based on flow graph.
3. Evaluate the test conditions to be achieved in each test.
4. Provide input and output values based on the condition.
III.2.2 Basis Path Testing
Is a white box testing techniques were introduced by Tom McCabe [MC76].
This method allows the designer of test cases to take measurements of the
procedural logic complexity of the design and use it as a guide in determining the
basis of group execution path, where it will ensure the execution of each statement
in the program at least once during testing takes place.
Identification method based on lines, the structure or the existing connection
of a system is commonly referred to as branch testing, because the branches of
code or logic functions are identified and tested, or also known as control-flow
testing. Base path comes in two forms, namely:
38

Zero Path: Path connecting unimportant or shortcut that exist on a system.

One Path: Path key liaison or a process on a system.
The main concept of the base path:
Each base path must be identified, there should not be neglected (at least 1
time tested). Combinations and permutations of a base path does not need to be
tested.

Figure 3.7 Notation flow graph.

Structural construction in the flow graph, where each cycle symbolizes one
or more of the code (source code statement).
Based on Figure 3.7, the image flow graph notation. As an illustration of the
use of a flow graph notation can be seen in Figure 3.8, 3.9 and 3.10 are trying to
show the conversion of the flow chart (Figure 3.9), which is a representation of
the source code (Figure 3.8) to flow graph (Figure 3.10).
Based on Figure 3.9 and Figure 3.10, each circle, called a flow graph node,
which represents one or more procedural statements. A sequential process that is
described in the form of a box on the flow chart or a decision that is depicted in
the form of a rhombus flow chart can be represented by a single node.
The arrows on the flow graph, called edges or links (relationships),
representing a delivery flow control and are analogous to the arrow on the flow
chart. An edge must end with a node, even if the node does not represent a
procedural statement though (see symbols to form IF-THEN-ELSE).
Area bounded by edges and nodes called regions. When counting the
regions, should also include areas outside of the chart as part of the regions.
39

Figure 3.8 Source code.

Figure 3.9 Flow chart

Figure 3.10 Flow graph

III.2.3 Cyclomatic Complexity

Is a measurement software that provides a quantitative measurement of the
complexity of the program logic.
In the context of the basis path testing method, the calculated value for
cyclomatic complexity determine the number of independent paths in the basis set
a program and provide a minimum number of tests that must be done to ensure
that all statements have been executed at least once.

40

Independent path is any path to a program that shows the first group of new
processes or new condition statement.
[Region / Complexity] V (G) = E (edges) - N (nodes) + 2
Sample Flow Graph view (Figure 3.10):
V (G) = 11-9 + 2 = 4
V (G) = P (predicate node) + 1
Sample Flow Graph view (Figure 3.10): V (G) = 3 + 1 = 4
Based on the sequence of the plot, found a group of base flow graph (Figure
3.10):
Line 1: 1-11
Line 2: 1-2-3-4-5-10-1-11
Line 3: 1-2-3-6-7-9-10-1-11
Line 4: 1-2-3-6-8-9-10-1-11
Stages in creating test cases using cyclomatic complexity:
Use the design or code as a base, draw a flow graph
Based on the flow graph, determine cyclomatic complexity
Determine the base group of linearly independent paths
Prepare test cases that will carry out the execution of each path in the group
bases
Examples of test cases from Figure 3.10
Test case path (Path) 1
Value (record.eof) = input is valid, where record.eof = true
Expected results: System out of the loop and the sub program.
Test case path (Path) 2
Value (field 1) = input is valid, where field 1 = 0
Value (record.eof) = input is valid, where record.eof = false
Value (counter) = value (counter) + 1
Expected results: The system did [process record], [store in buffer] and
[increment counter].
Test case path (Path) 3
41

Value (field 2) = input is valid, where the field 2 = 0

Value (record.eof) = input is valid, where record.eof = false
Value (counter) = 0
Expected results: The system did [reset the counter].
Test case path (Path) 4
Value (field 2) = input is valid, where the field 2 <> 0
Value (record.eof) = input is valid, where record.eof = false
Expected results: The system did [process record] and [store in file]. Note:
Some paths may only be executed as part of other tests. Recommended to
avoid the complexity of each unit / system smallest component exceeds a value
of 10 [V (G)]. Some practitioners use the average value of V (G) of each unit /
komponenn smallest to provide an assessment of complexity.
The reason why the smallest components of each system is recommended to
have a value V (G) exceeding 10:
The more components, interconnections between components and the
intersection point (the decision) will further increase the overhead (costs), making
the code becomes more complex and can degrade system performance.
Placing functions in large quantities to a module will increase the number of
interfaces (interfaces) of each module to other modules. When the first module
has little function, will make the components becomes simple and the potential
defect would also dwindle, as well as construction costs will also be reduced
efficiently.
III.2.4 Graph Matrix
Matrix is a rectangular equilateral, where the number of rows and columns
equal to the number of nodes, and the identification of rows and columns with
node identification, and data content is the existence of a link between nodes
(edges).
Some properties that can be added as a weighting in the connection between
nodes in the graph matrix, as follows:
Possible pathways (Edge) will be passed / executed.
42

 When the process is expected at the track during the transfer process is
done.
Memory required during the transfer process is done on line.
Resources (resources) are required during the transfer process is done on line.

Figure 3.11 Conversion flow graph to graph matrix

III.2.5 Control Structure Testing
Control structure testing include:
Testing conditions (Condition Testing)
A test case design method that checks the condition of the logic
contained in the program module. Here adalaha some definitions related to
the testing conditions:
Simple condition is a boolean variable or a relational expression,
which may be processed with one operator NOT (-). Shaped operational
expression E1 <relational operator> E2, where E1 and E2 are arithmetic
expressions and <relational operator> is one of: <, , =, (inequalities), ,>.
Conditions compound (compound condition) composed of two or
more simple conditions, boolean operators, and parentheses. Boolean
operators can be used in a complex condition is OR (|), AND (&) and NOT
(-).
A condition without relational expression can be referenced as a
boolean expression. While the element types that may exist in a condition
are:
43

A. Boolean operators
B. Variable Boolean
C. A pair of parentheses boolean (as found on the condition of simple or
complex)
D. Expression Relational operators Arithmetic
If a condition is not true, then at least one component of these
conditions is not true. These types of errors on the conditions are as follows:
1. Error Boolean operators
2. Errors Boolean variables
3. Errors parentheses Boolean
4. Errors relational operators
5. Errors arithmetic expression
The test method focuses on testing the condition of each condition in
the program. Conditions test strategy has two advantages, namely:
a. Measurement conditions coverage test is simple.
b. Coverage of the conditions tested program providing guidance for the
preparation of additional tests for the program.
Objective tests to detect errors in addition to the conditions of the
program conditions also for other errors of the program. Some strategies test
conditions:
Testing Branch
Test strategy is the simplest conditions. For a complex condition C,
right and wrong branch of C and each simple condition in C should be
executed at least once [MYE79]. As an illustrative example of use, it is
assumed there is a piece of code below:

44

When testing program code statements can be satisfied with a test, by

giving a value (X, Y, Z) = (1,1,1). And the results expected condition is true.
However, for the testing branch takes two tests, namely:
By providing value (X, Y, Z) = (1,1,1), to evaluate the true condition
(true).
And by providing value (X, Y, Z) = (2,1,1), as the representative to
evaluate the condition of one (false).
Domain Testing [WHI80]
Requires three or four tests conducted on a relational expression. For a
relational expression of the form:
E1 <relational operator> E2 three tests required values, so that E1 is
greater, equal to, or less than E2 [HOW82].
If <relational operator> is not true, and E1 and E2 is true, then the three
tests this ensures error detection relational operator.
To detect errors on E1 and E2, a test for the values, so that E1 is
greater or smaller than E2, whereby the difference of these values are kept
to a minimum. example:

Where E1 is represented by (X + 1) and E2 are represented by (Y - Z).

There are three tests, namely:
The first test with E1 and E2 represents the values 5 and 2, which is
obtained from the input (X, Y, Z) = (4,5,3), so that E1> E2. And the
results expected condition is true.
The second test with E1 and E2 represents the values 2 and 2, which is
obtained from the input (X, Y, Z) = (1,4,2), so that E1 = E2. And the
results expected condition is false.

45

The third test with E1 and E2 represents the values 1 and 2, which is
obtained from the input (X, Y, Z) = (0,4,2), so that E1 <E2. And the
results expected condition is false.
For a boolean expression with n variables, it takes all possible tests 2n
(n> 0).
This strategy can detect an error of the operator and the parenthesis
boolean boolean variable as well, but this was practiced only if n is small.
example:

Where X and Y is a boolean variable, it will do tests as many as 22 = 4,

that is by giving the X and Y {(t, f), (f, t), (f, f), (t, t)} with results
expected conditions of boolean operators AND {f, f, f, t}.
For a boolean expression alone (a boolean expression which each
boolean variable occurs only once) with the n boolean variables (n> 0), we
can easily create a set of tests that are less than 2n test where a set of tests
ensures error detection of multiple carriers boolean and also effective for
detecting other errors. example:

Then the domain of testing does not require 22 = 4 tests, but quite two
tests, namely the value (X, Y) = (t, t), to evaluate the conditions are right
(true).
And (X, Y) = (f, t), as the representative of the rest of the input
possibilities for the evaluation of the condition is false (false).
BRO (Branch and Relational Operators) Testing [TAI89]

46

This technique ensures the detection error of the branch and relational
operator in a condition that is where all the variables boolean and relational
operators contained in the condition occurs only once and no more variables
are used together.
BRO strategy testing using boundary conditions for a boundary
condition C. A condition for C with n simple condition is defined as (D1,
D2, ..., Dn), where Di (0 <i n) is a symbol of the me-specification-kan an
existing boundaries on the simple condition to i to a condition C.
A range of conditions to ensure C D has been covered with an
execution C if, during the execution of C, the result of each simple condition
on C satisfy limits dikorespondesikan in D.
For a boolean variable, B, our me-specification-kan a result of the
restriction D which states that B is true (T) or false (f). similarly, for the
relational expression, the symbols <, =,> used to me-specification-the
boundaries of the result of the expression. As an illustration given examples
as follows:
Example 1:
A condition C1: B1 & B2
Where B1 and B2 is a boolean variable.
C1 range of conditions in the form (D1, D2), and D1 and D2 are t or f.
Value (t, f) is a range of conditions C1 and covered by tests that make the
value of B1 to B2 become true and false values.
BRO testing strategies require a set of constraints {(t, t), (f, t), (t, f)}
covered by the execution of C1.
If C1 is not correct to one or more boolean operator error, at least one of
a set of restrictions will make the C1 wrong.
Example 2:
A condition C2: B1 & (E3 = E4)
Where B1 is a boolean expression, E3 and E4 are arithmetic expressions.

47

C2 range of conditions in the form (D1, D2), and is t or f D1 and D2

are>, =, <.
When C2 = C1, except for simple conditions both in C2 is an expression
of relational, can be built a set limit to C2 by modifying a set of
constraints {(t, t), (f, t), (t, f)} defined for C1.
Where t (E3 = E4) symbolizes = and f for (E3 = E4) symbolizes <or>.
By replacing (t, t) and (f, t) (t =) and (f, =), and by replacing (t, f) and (t,
<) and (t,>), generates a series of restrictions for C2 is {(t, =), (f, =), (t,
<), (t>)}.
Coverage for a set of restrictions above will guarantee error detection
from boolean and relational operators in C2.
Example 3:
A condition C3: (E1> E2) and (E3 = E4)
Where E1, E2, E3, and E4 are arithmetic expressions.
C3 range of conditions in the form (D1, D2), and D1 and D2 are>, =, <.
When C3 is equal to C2 except simple conditions first in C3 is an
expression of relational, can be built a set limit to C3 by modifying the
set limits for C2 by replacing t with>, and f with = and <, in order to get
{(>, =), (=, =), (<, =), (>,>), (>, <)}
Scope set this limit will ensure the detection error of relational operators
on C3.
Example 4:
In this example, given as examples of the actual implementation,
by displaying the following code fragment:

48

Wherein X, Y and Z is a boolean variable. Then it can be rewritten,

according to Branch and relational operator testing (BRO), which
diterdapat on [TAI89]: C4: X & Y & Z
With C4 is the identity of the conditions representing the predicate of this
piece of code above.
It takes eight tests with a range of conditions C4, as follows: {(t, f, f), (t,
f, t), (t, t, f), (t, t, t), (f, f, f ), (f, f, t), (f, t, f), (f, t, t)}, with the result of the
condition C4 expected is (f, f, f, t, f, f, f, f ).
To get the amount of coverage the fulfillment of conditions in a
program module, can be used flow graph, as described in the base path
testing, which will be represented by the number of predicate (P).
Testing flow of data (Data Flow Testing)
Testing loop (Loop Testing)
III.2.6 Data Flow Testing
Method choose the path of data flow testing program based on the location
of the definition and use of variables in the program.
As an illustration of data flow testing approach, it is assumed that every
statement in a program is marked with a unique numbering its statement, as the
identity of each statement, where each function does not modify the parameters or
global variables. To a statement by S as a number of his statements:
DEF (S) = [X | S statement contains a definition X]
USE (S) = [X | S statement contains a use of X]
If the statement S is an IF statement or LOOP, then the section will be
empty DEF and USE section based on the condition of the statement S. The
definition of the variable X at the statement S is declared "live" in a statement S 'if
there is a path from statement to statement S S 'which does not contain a definition
of the X.
Bond Definition-Use (DU) of X is written in the form [X, S, S '], where S
and S' is the number of statements, this means X is in DEF (S) and USE (S '), and
the definition of X the statement S living in a statement S '.
49

A simple strategy of data flow testing should include at least once every
bond DU. Therefore the data flow testing also called DU testing strategy.
DU testing does not always guarantee the fulfillment of all branches of
program coverage. But this is a rare situation, where a branch is not a coverage of
DU testing, such as the construction of IF-THEN-ELSE, which THEN part does
not have any variable definition, and there is no ELSE part. In this situation, the
ELSE branch of an IF statement does not need to cover by DU testing.
Data flow testing strategies are very useful for determining a test track on a
program that contains nested if statements and loops. As an illustration of the
application of DU testing to choose the path of PDL test as follows:

DU testing strategy to use in selecting a test track of the control flow

diagrams, need to know The definition and use of variables in each condition or
block the PDL. It is assumed that the variable X is defined in the final statement
of the blocks B1, B2, B3, B4, and B5, and used the first statement of the block B2,
B3, B4, B5, and B6. DU testing strategy execution requires a shortest path from
each Bi, 1 <i 5, to each Bj, 2 <j 6. (A specific testing also include the use of
each variable on the X in the condition of C1, C2, C3, and C4. ) Although there
were 25 ties DU of variable X, it only takes five test track to include this DU
bond. The reason is the fifth line was needed to cover the bond DU X of Bi, 1 <i
50

5, B6 and ties to other DU can cover this by creating a fifth lane loop iterates
through the suit.
If using the testing branch strategy for selecting a test track of the PDL, as
mentioned above, no additional information is needed. To select a test track on the
diagram to BRO testing requires knowledge of the structure of each condition or
block. (After the election program track, need to determine if a feasible path for
the program; and at least one input no through lane.)
Since the statements in a program linked to each other based on the
definition and use of variables, data flow testing approach will be effective in
detecting errors. However, the problems of measurement of test coverage and the
selection of a test track for data flow testing will be more difficult than the
problems associated with the testing conditions.
It is unrealistic to assume that the data flow testing will be used extensively
when conducting tests of a system that is great. But will usually be used in certain
areas targeted as the cause of the error from the software.
III.2.7 Loop Testing

Figure 3.12 Types of loops.

Loop testing is a white box testing technique that focuses on the validity of
loop constructs exclusively. Figure 3.12 shows four different classes of loops
[BEI90], namely:
Simple Loops
51

A set of tests following can be used for simple loops, where n is the
maximum amount that can be passed in the loop:
1. Skip the overall loop, no iteration / throughput in the loop.
2. Spend just one iteration of the loop.
3. Spend two iterations in the loop.
4. Miss m iterations in the loop where m <n.
5. Skip n-1, n, n + 1 iteration in the loop.
Nested Loops
If the test approach for simple loops developed in nested loops, the
number of possible tests will grow geometrically in line with the increasing
levels of nested loops.
Beizer [BEI90], provide an approach that will help to reduce the
number of tests.
1. Start from the innermost loop. Set all other loops to minimum values.
2. Do a simple test loops to loop the most in, while maintaining the
existing loops on the outside with the minimum iteration parameter
values. Add other tests for value outside of the area or not included in
the limitation iterations parameter value.
3. Work from the inside out, doing tests for the next loop, but the loop
retaining all that is outside the minimum values and other nested
loops on common values.
4. Continue until the whole of the loops have been tested
Concatenated Loops
Concatenated loops can be tested by using an approach that is defined
for simple loops if each independent loops (not interdependent) between one
another. It said two loops are not independent, if two loops are concatenated
loops, and the value of the loop counter in the loop 1 is used as an initial
value for the loop 2. When the loops are not independent, is recommended
to use the approach as used in nested loops.
Unstructured Loops
52

Can not be tested effectively. And whenever possible loops of this

type should be redesigned.
III.2.8 Lines of Code
Measurement is simple: count the number of lines of code in a program and
use these calculations to measure complexity. Based on studies that have been
done [LIP82A]:
Small programs have an average error of 1.3% to 1.8%.
The program has a large increase in average error of 2.7% to 3.2%.
III.2.9 Halstead's Metrics
Halstead's metric is a measurement based on the use of operators (such as
keywords) and operands (such as variable names, object database) that exist in a
program.
n1 = the number of operators unique (distinct) in program operands n2 =
number of unique (distinct) in the program. The length of the program: H = n1
+ n2 log2 log2 n1 n2.
N1 = calculation of the total number of program operator.
N2 = total number of operands calculation program.
Prediction bug: B = (N1 + N2) log2 (n1 + n2) / 3000

III.3 Black Box Testing

Black box testing, done without knowledge of the details of the internal structure of a
system or component tested. Also referred to as behavioral testing, specification-based
testing, input / output testing or functional testing.
Black box testing focuses on functional requirements on software, based on the
requirements specification of software.
With the black box testing, software engineers can use a set of input conditions to
fully examine all the functional requirements of a program.
Black box testing is not a technique alternative to white box testing. More than that,
it is a complementary approach in covering errors with different classes of white-box
testing methods. Categories error which would be known by black box testing:
53

 Functions that are lost or not properly

Error of interfacial
Error of data structures or external database access
Error of performance or behavior
Error of initialization and termination
Unlike white box testing, which is used at the beginning of the testing process. Black
box testing is used at the final stage and focus on the domains of information. The test is
designed to answer the question as follows:
How is the validation function to be tested?
How does the behavior and performance of the system tested?
Category nice the inputs used for test cases?
Are some systems are sensitive to a certain input values?
How to limit an input categories defined?
The system has tolerance levels and the volume of any data?
What are the consequences of a combination of specific data that will occur in the
operating system?
By applying the techniques of black box, we can make a set of test cases to satisfy
the following criteria [MYE79]:
Test cases are reducing the number of test cases (more than one) that are designed to
achieve reasonable testing.
Test cases that can provide information about the presence of the classes of error.
Most of the techniques and examples are translated from the British Computer Society's
Standard for Component Testing [BCS97A]. This standard provides excellent guidance for
the engineering design of the test, and has been proposed as an international standard.
III.3.1 decomposition needs to be tested systematically
Most tester, when you start testing project, will face the problem of test
cases to decide what they will execute to perform tests of their systems.
To be able to create test cases to be effective, must be carried out
decomposition of tasks testing a system to activities that are smaller and to Be,
until they reach individual test case. Of course, in a test case design also used a
54

mechanism to ensure that the test case that there has been quite cover all aspects
of the system.
Test case as the design is done manually, there is no automation tools to
specify test cases required by the system, because every system is different, and
test tools can not know the rules of right and wrong from an operation. The design
of the test requires experience, reasoning and intuition of a tester.
Specifications as guidance testing
Specifications or the system model is the starting point in starting the design
of the test. Specifications or system models can be functional specifications,
performance or safety specifications, specification of user scenarios, or
specifications based on the risk of the system. The specification describes the
criteria used to determine the correct operation or unacceptable, as a reference
implementation of the test.
Many cases, usually associated with the old system, there is little or no
documentation of system specifications. In this case a much-needed role of end
users who know the system to be incorporated into the design of the test, instead
of the system specification document. Nevertheless, should remain documentation
specification, which could have been made in a simple form, which contains a set
of tests at the top level of objectivity.
Decomposition objectivity test
The design of the test focuses pas TDA specification of components tested.
Objectivity top level test is based on a component specification. Each objectivity
of this test for objectivity then decomposed into other tests or test cases using test
design techniques.
There are many types of engineering design tests that can be selected based
on the type of testing that will be used [BCS97A], namely:
Equivalence Class Partitioning
Boundary Value Analysis
State Transitions Testing
Cause-Effect Graphing
55

Figure 3.13 Decomposition of the objectivity of the tests.

Documenting the design of the test is very important. The design of the test
represented in a document called the Test Design Specification, which follows the
standard format [IEEE83A]. The existence of this document to facilitate the
conduct audits to track test cases to be applied to the design specifications of the
components. In general, the test design document is required to assess the other
party in the fulfillment of each requirement.
Design tests that systematically is the key to perform the task decomposition
of large and complex testing.
III.3.2 Graph Method Based Testing
The first step in the black box testing is to understand objects that are
modeled in the software and the connection relationships between objects, then
define a series of tests that verify that all objects have had a relationship with each
other as expected. [BEI95]
This step can be achieved by creating a chart, which contains a set of nodes
that represent objects, liaison / link that represents the relationship between
objects, weight of nodes that describe the properties of an object, and the weight
of a liaison that describes some characteristics of a liaison / link.
56

Figure 3.14 (A) Notation chart; (B) A simple example

Symbolic representation of the graph looks like on the picture 3.14A. Nodes
are represented as circles connected by a hyphen. A direct relationship (depicted
in the form of arrows) indicate a relationship that moves in only one direction.
Two-way relationship, also referred to as a symmetrical relationship, describes the
relationship which can move in two directions. Parallel connections are used when
a relationship established between the two nodes.
An illustrative example
As a simple example, can be seen in Figure 3.14B, a graph of word
processing applications, where:
Object # 1 = Select menu [New File].
Object # 2 = Display document.
Object # 3 = Text documents.
Based on the image, selecting the [New File] will produce (generate) the
display of documents. Thickness node of the document display screen presents a
list of attributes that are expected when the screen is made (generated). The
weight of the relationship indicates that the screen should have been made in less
57

than 1 second. An indirect relationship established as a symmetrical relationship

between the selection menu [New File] with the text of the document, and parallel
connections indicate the display of documents and text documents.
In reality, it needs more detailed graphic image (in the example above),
which will be used to design test cases. Software designer uses graphic images to
create a test case that covers every relationship in the graph. So the test case can
detect the error of each relationship.
Beizer [BEI95] describes a number of behavioral testing method that can
use the chart:
Transaction Flow Modeling, where the nodes represent the steps in a
transaction (eg steps for using the air ticket reservation services on-line), and
liaison to represent logical connections between steps (eg flight information input
followed by processing the validation / presence).
Modeling of Finite State, where the nodes represent the status of software
that can be observed (eg each screen that appears as the input order when the
cashier menerimaa order), and liaison to represent transitions between status (eg
order information is verified by showing the existence of inventory and followed
by input billing information customer).
Data Flow Modeling, where the nodes represent data objects (eg Tax and
Wage Data Net), and liaison to represent the transformation for me-songbirds
between data objects (eg Tax Net Salary x = 0:15).
Modelling Time / Timing, where the nodes represent objects representing
sequential program and liaison connections between these objects. Weights liaison
is used to specify the execution time required.
Testing based chart (graph based testing) begins by defining all the nodes
and weights nodes. In this case means that the objects and attributes are defined in
advance. Data models can be used as a starting point to begin, but keep in mind
that most nodes are the object of the program (which is not explicitly represented
in the data model). In order to determine an indication of the start and end point of
the graph, it is helpful to do the definition of input and output nodes.
58

When the nodes have been identified, the relationship and connection
weights will be assigned. Relationships should be named, although the
relationship between object representing the flow of control programs do not
actually need to be named.
In many cases, the graph model may have loops (ie, lines on a graph that
consists of one or more nodes, and accessed by more than one iteration). Loop
testing can be applied at the level of black box. The graph will lead in identifying
loops that need to be tested.
Here is an illustration of transisivitas, where there are three objects X, Y,
and Z, which has the following relationship:
X needed to calculate Y
Y required to calculate Z
Therefore, transisivitas relationship between X and Z, are as follows:
X needed to calculate the Z
Based on this relationship, the test to find errors in the calculation process Z,
must pay attention to the variation of both X and Y.
When you start a design test cases, objectivity is the first to achieve the
fulfillment of the node coverage. This means that the test should be designed to
not miss a single node and node weights (object attribute) is correct.
Then, the scope relationship tested based on its properties. For example, a
symmetry relationship tested to perform a two-way relationship. Transisivitas
relationship tested to prove the existence transisivitas. Reflexive relationship
tested to ensure the existence of a null loop. When the connection weights have
been specified, a test developed to prove that the weight is valid. And finally, loop
testing involved.
III.3.3 Equivalence Partitioning
Is a black box testing method that divides the input domain of a program
into classes of data, where the test cases can be derived [BCS97A].
Equivalence partitioning is based on the premise of the input and output of a
component that is partitioned into classes, according to the specifications of the
59

components, which will be treated the same (equivalent) by the component. It can
also be assumed that the same inputs would produce the same response as well.
Single value in a partition equivalence assumed as a representation of all the
values in the partition. It is used to reduce the problems that are impossible to
testing on each input value (see the principle of testing: testing is complete is not
possible).
The implementation guidelines in conducting equivalence partitioning, are
as follows:
If the input has a certain level, then define the category of valid and invalid
to the input level.
If the input requires a specific value, define categories of valid and invalid.
If the input requires a particular set of inputs, define categories of valid and
invalid.
If the input is a boolean, define categories of valid and invalid.
While several combinations are possible in equivalence partitioning, are:
The input value is valid or not valid.
The numeric value is negative, positive or zero.
String is empty or not empty.
List (list) is empty or not empty.
File data and not, which can be read / written or not.
The date that is after 2000 or before 2000, a leap year or not a leap year
(mainly on 29 February 2000 yangg has a separate process).
The date is in the month amounted to 28, 29, 30, or 31 days
Day on a weekday or a weekend getaway.
Time inside or outside of office hours.
Type of data files, such as text, formatted data, graphics, video, or sound.
The source or destination file, such as hard drives, floppy drives, CD-ROM,
network.
An illustrative example
A function, generate_grading, with the following specifications:
60

The function has two markers, namely "Test" (over 75) and "Duty" (over
25). Function performs a gradation value of the courses in the range of 'A' to 'D'.
Grade level is calculated from the second marker, which is calculated as the total
sum of values "Test" and value "Duty", as stated below:
Greater than or equal to 70 - 'A'
Greater than or equal to 50 but less than 70 - 'B'
Greater than or equal to 30 but less than 50 - 'C'
Smaller than 30 - 'D'
Where if the value is outside the expected range will result in an error (
'FM'). All input is an integer.
analysis partition
Tester provides a component model tested is a partition of the value of the
input and output components. Input and output are made from the specification of
the behavior of the component.
Partitioning is a set of values that are selected in such a way that all values
in the partition, is expected to be treated in the same manner by the component
(such as having the same process).
Partitioning for valid and invalid values should be determined. For
generate_grading function, there are two entries:
"Exam"

Figure 3.15 Partitioning equivalence of input "Test"

"Task"

Figure 3.16 Partitioning equivalence of input "Tasks"

61

The input value can be a value is not an integer. As an example :

Exam = real number
Exam = alphabetic
Task = real number
Task = alphabetic
Next, the output of generate-grading functions, namely:

Figure 3.17 Partitioning equivalence to the output of gradation.

Equivalence partition also included an invalid value. Difficult to identify
outputs that are not specified, but it should still be considered, as if it can be
generated / happening, eg:
Gradation = E
Gradient = A + Gradient = null
In this example, earned 19 partitions equivalence.
In equivalence partitioning, the tester must subjectively election. For example,
the addition of inputs and outputs are not valid. Because of this subjectivity,
then the equivalence partitions can be different for different tester.
As the design of test cases
Test cases are designed to test the partition. A test case simplifies the
following things:
Put the component.
Partition tested.
The expected outcomes of the test case.
Two approaches your test case to test the partition, is:
1. Test cases are made separately for each partition with one-to-one basis.
62

2. A set of small test cases created to include all partitions. The same test
cases can be repeated for the other test cases.
Partition one - to - one test cases
Test cases for partitioning input "test", are as follows:
Test Case

Masukan Ujian

44

-10

93

Masukan Tugas

15

15

15

Total Nilai

59

108

0 e 75

e<0

e > 75

FM

FM

Partisi yang dites

Keluaran yang diharapkan

A random value of 15 is used to input "Tasks".

Test cases for partitioning input "Tasks", are as follows:
Test Case

Masukan Ujian

44

40

40

Masukan Tugas

-15

47

Total Nilai

48

25

87

0 c 25

c<0

c > 25

FM

FM

Partisi yang dites

Keluaran yang diharapkan

A random value of 40 is used to input "Exam".

Test cases for other invalid input partition, are as follows:
Test Case

10

Masukan Ujian

48.7

40

40

Masukan Tugas

15

15

12.76

Total Nilai

63.7

52.76

Partisi yang dites

real

alpha

real

alpha

Keluaran yang diharapkan

FM

FM

FM

FM

63

Test cases for valid output partitions, are as follows:

Test Case

11

12

13

Masukan Ujian

-10

12

32

Masukan Tugas

-10

13

Total Nilai

-20

17

45

Partisi yang dites

t<0

0 t 30

30 t 50

Keluaran yang diharapkan

FM

Test Case

14

15

16

Masukan Ujian

40

60

80

Masukan Tugas

22

20

30

Total Nilai

66

80

110

Partisi yang dites

Keluaran yang diharapkan

50 t 70 70 t 100
B

t > 100
FM

The input value "Test" and "Duty" is taken from the total value of "Test" with the
value "Duty". And finally, the partition Invalid output, are:
Test Case

17

18

19

Masukan Ujian

-10

100

null

Masukan Tugas

10

null

-10

110

A+

null

FM

FM

FM

Total Nilai
Partisi yang dites
Keluaran yang diharapkan

Test cases for a minimum of multi partition

In the case of test cases over many similar, but has a different target
partition equivalence. This makes it possible to develop a single test cases which
test multi partition at a time.
This approach allows the tester to reduce the number of test cases required
to cover all equivalence partitions.
example:

64

Test Case

Masukan Ujian

60

Masukan Tugas

20

Total Nilai

80

Keluaran yang diharapkan

Test case in the above test three partitions:

0 Test 75
0 Duty 25
Results gradation = A: 70 100 Exam + Assignment
The same thing, test cases can be created to test multi partition to an invalid value:
Test Case

Masukan Ujian

-10

Masukan Tugas

-15

Total Nilai

-25

Keluaran yang diharapkan

FM

Test case in the above test three partitions:

Exam <0
Task <0
Results gradation = FM: Exam + Assignment <0
Comparative approach to one - to - one with minimization
Disadvantages of the approach of one-to-one needs more test cases. How
well the identification of a partition takes longer than the decline and execution of
test cases. Each savings to reduce the number of test cases, relatively small
compared to the cost of the use of techniques to produce partition.
Disadvantages of minimization approach is the difficulty of determining the
cause of the error. This will cause the debugging becomes more difficult, than the
implementation process itself testingnya.

65

III.3.4 Boundary Value Analysis

For a reason that can not be fully explained, the majority of the number of
errors tend to occur around the boundaries of the input domain rather than in the
"center" of his. For this reason Boundary value analysis (BVA) was developed as
a technique testing [BCS97A]. Boundary value analysis is a technique that is
useful design test cases for testing of the value of approximately from the center
of the input domain.
Mechanical boundary value analysis is the complement of technical
equivalence partitioning. After selecting each element of an equivalence class
(using equivalence partitioning), BVA make the selection of the value of grade
boundaries for test cases. BVA focuses not only on the input conditions, BVA
create test cases from the output domain also [MYE79].
Instructions for the implementation of BVA resemblance to equivalence
partitioning, namely:
1. If the input is a range of values with the limit values of a and b, test cases
designed to value a and b, above and below the values of a and b.
2. If the input is a certain value, test cases are designed with a minimum and
maximum, and the value above and below the minimum - maximum.
3. Use the no 1 & 2 for the design of test cases against the expected output
and the unexpected.
4. If the program uses the data structure array limitations with certain
restrictions, make sure the design of test cases to check the data structure to
limit the array.
Boundary-values is the value limits of equivalence classes. Example:
Monday and Sunday for the day. January and December for the month. (-32 767)
and 32767 for 16-bit integers.
One character string and a maximum length of the string. Test cases
performed to examine the values on either side of the boundary.

66

Value of each side of the boundary selected, arranged to have the smallest
possible difference to the value of constraints (eg the difference between numbers
1 to integers).

Figure 3.18 The tests selected on or next of value limits.

An illustrative example
Based

on

generate_grading

the

previous

neighbor

example

function,

(see

wherein

equivalence
the

partition

partitioning)
initialization

equivalence has been identified (together with technical equivalence partitioning),

and is used as a limit value.
For example, the partition "Exam" value restriction test to test the value of
"Test" at -1, 0, 1, 74, 75, and 76:

Figure 3.19 Value limit for entering a value Exam.

Test Case

Masukan (Ujian)

-1

74

75

76

Masukan (Tugas)

15

15

15

15

15

15

Total Nilai

14

15

16

89

90

91

Nilai Batasan
Keluaran yang Diharapkan

0
FM

75
D

A random value of 15 is used for all input values Tasks.

67

FM

As for the value Duty risk limits have value 0 and 25, which generates test
cases as follows:
In the example of equivalence partitioning also consider partitioning
Examination score and Duty for non-integer numbers and non-numeric, ie, real
numbers, and the value of the alphabet. But keep in mind that this is not an
identification of the boundaries, and therefore not to be identified from the
restrictions into consideration in making the test cases.
Partition equivalence to the results gradation value are also considered. The
limit values of the partition results gradation value is 0, 30, 50, 70, and 100.
Test Case

10

11

12

Masukan (Ujian)

40

40

40

40

40

40

Masukan (Tugas)

-1

24

25

26

Total Nilai

39

40

41

64

65

66

Nilai Batasan

Keluaran yang Diharapkan

FM

25

FM

Figure 3.20 limit value for the output gradation value.

Test cases based on the value of the output value of gradation limits
mentioned above, are as follows:
Test Case

13

14

15

16

17

18

Masukan (Ujian)

-1

29

15

Masukan (Tugas)

15

25

Total Nilai

-1

29

30

31

Nilai Batasan

Keluaran yang Diharapkan

FM

30

Test Case

19

20

21

22

23

24

Masukan (Ujian)

24

50

26

49

45

71

Masukan (Tugas)

25

25

20

25

Total Nilai

49

50

51

69

70

71

Nilai Batasan

50

Keluaran yang Diharapkan

68

70
B

Test Case

25

26

27

Masukan (Ujian)

74

75

75

Masukan (Tugas)

25

25

26

Total Nilai

99

100

101

Nilai Batasan

100

Keluaran yang Diharapkan

A FM

Partition one of the results of the gradation used in the example equivalence
partitioning, (such as E, A + and null), no limit that can be identified, and
therefore can not be made test cases based on the value limits.
For the record, there are many unidentified partitions that are bound only on
one side, such as:
Examination score> 75
Examination score <0
Values Task> 25
Values Task <0
Total Value (Value + Value Exam Task)> 100
Total Value (Value + Value Exam Task) <0
Partitions will be assumed to be bound by the type of data used as input or
output. For example, 16-bit integers and -32 768 32 767 has limitations.
Then it can be made of test cases to test the following values:
Test Case
Masukan (Ujian)
Masukan (Tugas)

28

30

31

32

33

32766 32767 32768 -32769 -32768 -32767

15

Nilai Batasan
Keluaran yang Diharapkan

29

15

15

15

32767
FM

FM

15

15

-32768
FM

FM

FM

FM

Similarly in creating test cases from value tasks and results gradation value,
is done in the same manner as in the manufacture of test cases to test the value of
the above.

69

III.3.5 Cause-Effect Graphing Techniques

An engineering design test cases to illustrate the logic of the conditions of
the action taken. There are four steps, namely:
1. Each cause (input conditions) and effect (action) that exist in a module is
registered.
2. Figure causation (cause-effect graph) is created.
3. Figure by converting to the decision table.
4. The rules contained in the decision table by converting into test cases.

Figure 3.21 Diagram logic and limits on the cause-effect graphing techniques.
An illustrative example
As an illustration, given some conditions and actions of a debit function
checks, as follows:
condition:
C1 - new loan transaction journal.
C2 - new withdrawal transaction journals, but in certain withdrawal limits.
C3 - estimates have a journal post.
action:
A1 - debit processing.
A2 - delays journal estimates.
A3 - mail delivery.
Where the debit function specification check:
70

 If funds are insufficient on estimates or new journal transactions within the

limits withdrawals are allowed, then the discharge process is done.
If the new journal transaction is outside the limits withdrawals are allowed,
then the discharge process is not performed.
If an estimate that has a post journal postponed the discharge process.
Letters will be sent to all postal transactions journals and estimates have to
estimate which does not have a post journal, if the funds are insufficient.
Cause-effect graph will show the relationship between the conditions and
actions as follows:

Figure 3.22 Graph cause-effect for debit function check.

Cause-effect graph then formulated in a decision table. All combinations
true (true) and false (false) to the input condition is entered, and the values of right
and wrong is allocated to the actions (sign * is used for any combination of input
conditions that are not feasible and consequently does not have the action that's
possible).
Results are shown as in the decision table below:
Aturan
C1: transaksi jurnal kredit baru

C2: transaksi jurnal penarikan

baru, tapi dengan batas
penarikan tertentu.
C3: jurnal yang mempunyai
pos perkiraan.
A1: pemrosesan debit.

71

A2: penundaan jurnal perkiraan.

A3: pengiriman surat.

The combination of input feasible and then covered by test cases, are as follows:
Sebab (cause)
Akibat (effect)
Nilai
Nilai
Test case
Tipe
Batas
Jumlah
Perkiraan penarikan perkiraan debit perkiraan Kode aksi
saat ini

baru

Kredit

100

-70

50

-70

Tunda

1500

420

2000

420

S&L

Kredit

250

650

800

-150

D&L

Tunda

750

-500

200

-700

D&L

Kredit

1000

2100

1200

900

Tunda

500

250

150

100

D&L

III.3.6 State Transition Testing

State transition testing using a model system, consisting of:
Status contained in the program.
Transitions between statuses.
Genesis which is the cause of these transitions.
Actions that will be generated.
The model is generally represented in the state transition diagram.
Test cases are designed to check the validity of transition between status.
Test cases will also be designed for the additional testing on the transitions that
are not included and are not specified.
An illustrative example
Suppose there is a state transition diagram that handles the input request for
the display mode of the display time of a device, as follows:

72

Figure 3.23 State transition diagram for a display device.

State transition diagram above is composed of: Status, such as displaying

time (S1). Transitions, such as between S1 and S3.
Events that cause a transition, such as "reset" during the status S1 will cause
a transition to S3.
The action is the result of the transition, such as during the transition from
S1 to S3 as a result of the incident "reset", the action "display time" will occur.
Test cases for a valid transition
Test cases are designed to check transitions are valid. For each test case,
there are the following specifications:
Status start.
Feedback.
Expected output.
The final status expected.
Based on the above example, there are six test cases:
Test cases

Status mulai

S1

S2

S3

S2

S2

S4

Masukan

CM

TS

CM

DS

Keluaran yang diharapkan

AT

AD

Status akhir

S2

S3

S1

S1

S4

S2

The above set of test cases to produce a 0-switch coverage [CHO78a].

73

Another level of coverage changes (switches) which is the result of the

merging of sequential longer than the transition:
Scope 1-switch is obtained by looking at the sequential appearance of the two
transitions are valid for each test.
N-switch coverage is obtained by looking at the sequential appearance of the N
+ 1-tansisi valid transition for each test.
Test cases for transition invalid
Status transition test designed to scope changes (switches) only for
sequential valid test of the transition. Comprehensive Testing will try to perform
tests on the transition that is not valid.
Software transition diagram above shows only valid transitions. A status
transition model that explicitly shows invalid transition is a table status (state
table).
For example, there is a status table for the time display devices such as the
following:
CM

TS

DS

S1

S2/D

S3/AT

-1

-1

S2

S1/T

S4/AD

S3

S1/T

S4

S2/D

The cells of the table status is shown in the form - symbolizing no transition
(transition null), whereby when each transition is implemented will result in
failure. The test for invalid transition was made as it has been shown to transition
valid. Table status is ideal for identifying test cases. There will be 16 test by cells
of the table status.
III.3.7 Orthogonal Array Testing
Many applications that have relatively limited input domain, which is a
small number of input parameters and values of each parameter are clearly
connected. When the number of input parameters is very small (like, three input
parameters, each of which has three discrete values), allows for testing a complete
74

(exhaustive testing) to the input domain. However, when the number of input
values increased and the number of discrete values for each item of data also
increases, the testing is complete are impossible.
Exhaustive testing is a test that covers every possible input and initial
conditions. Is an important concept as a reference to an ideal situation, but it was
never carried out in practice, due to the volume of test cases is very great.
To illustrate the difference between orthogonal array testing approach with
more conventional "one input at a time", assumed to be a system that has three
inputs, namely X, Y and Z. Each input has three discrete values associated to it.
So there will be 33 = 27 test cases. Phadke [PHA97] provides a geometrical point
of test cases that may be, associated with X, Y and Z as shown below.

Figure 3.24 geometric viewpoint of test casses.

Based on the pictures 3:24, one input at a time will vary sequentially along
each axis input. Results are expected to be in a certain coverage relative to the
input domain (represented by a cube 3:24 left in the picture). When conducting
orthogonal array testing, will be made an L9 orthogonal array of test cases. L9
orthogonal array has a "balance of nature" [PHA97], namely the test cases (which
are represented in the black dot in the figure) that didiskritkan uniformly
throughout the test domain, which is illustrated on the right in the image cube
3:24. Coverage tests on domain input will be more complete.
An illustrative example
To illustrate the use of L9 orthogonal array, given the function of "send" on
the fax application. Four parameters, P1, P2, P3, and P4 is passed to the function
75

"send". In each of these parameters there are three discrete values, eg for P1 will
have value:
P1 = 1, send now.
P1 = 2, send one hour later.
P1 = 3, sent after midnight.
P2, P3, P4 also has a value of 1, 2, 3 as contained in the value of P1.
If the strategy of testing "one input at a time" is selected, the sequential test
(P1, P2, P3, P4) to be specified as follows: (1, 1, 1, 1), (2, 1, 1, 1), (3 , 1, 1, 1),
(1, 2, 1, 1), (1, 3, 1, 1), (1, 1, 2, 1), (1, 1, 3, 1), (1 , 1, 1, 2), and (1, 1, 1, 3).
Phadke [PHA97] provides an assessment of test cases is as follows:
"A test cases will only be useful if a certain test parameters do not interact.
Can detect logic errors made by a single parameter values for the failure of
software functions, commonly called single fault mode. This method can not
detect logical errors that cause a malfunction when two or more parameters
simultaneously with a certain value, it can not detect an interaction. This is a
limitation upon ability in detecting errors ".
Based on the number of input parameters and discrete values are relatively
small, as mentioned above allows for complete testing. The number of tests
required is 34 = 81, is great, but can to Be. All the errors associated with the
permutation data items can be found, but the effort required is relatively high.
Orthogonal array testing approach allows to design test cases that provide
test coverage with the number of test cases to acceptable than a complete testing
strategy.
Test

Parameter tes

cases

P1

P2

P3

P4

76

A L9 orthogonal array testing for function "send" on a fax application, as

illustrated in Figure 3:24 and test cases in the above table.
Phadke [PHA97] provides an assessment of the results of a test that uses L9
orthogonal array testing, as follows:
Detect and isolate all single fault mode. A single fault mode is a problem
consistent with the level of each single parameter. For example, if all test cases
factors P1 = 1 causes an error condition, it can be called a single fault mode. In the
example table above tests, single-mode error occurs when the test 1, 2, and 3
generate an error. So that the causes of errors can be identified and isolated
(process logic that relates to send now (P1 = 1)).
Detect all double fault mode. If a problem arises that is consistent when
given a certain level of two parameters simultaneously, is called a double fault
mode. Thus, a double fault mode is an indication of the incompatibility of the
interaction between two parameter pairs.
Mode mistake many (multi). For this error mode can also be detected by
orthogonal test, but the type of orthogonal array testing shown above can only
ensure single and double error detection.
III.3.8 Functional Analysis
The technique most often used to identify test cases. The idea could perform
an analysis of the functions found on a system, whether these functions have
performing as expected or specified.
This technique requires answers to the following questions: The main function
of what should be on the system?
Based on existing functions, output what should be produced to prove that the
function has been fulfilled?
Any input and initialization system needs to produce output for each function
in question?
77

Therefore, the first approach is to get information on the specifications

expected functions can be provided by the system. This information is generally
contained in the functional specification documentation system.
What if there is no documentation of the functional specification of the
system? Users need to create functional specifications. The manufacturing process
can be started from the menu structure program or manual for users (eg Help File
or User Manual).
An illustrative example
As an illustrative example is given a mainframe application of the shire
council, which has the following main functions:
Finance, accounting and budget.
Management of inventory.
Purchase.
Services.
Management of data.
And as usual, there was no documentation of advanced systems.
Decomposition of the system to function - the function
Started by dividing the system into groups function for major functional
categories. example:
operator functions.
The administrative system.
Functions of installation.
The security functionality.
Function recovery / backup.
Function interface And others.
Furthermore, for each category of functional, developed a hierarchy of
group functions that define the types of functions that exist for the category.
There is specific guidance at this stage, to establish groups that depend on
the type of system. The following things can be a good starting point to build a
group hierarchy of functions:
78

 Menu of system.
The table of contents or the header section of the guide book.
The main menu provides the initial function group for operator functions:

Figure 3.25 The main menu of the system shire council.

The submenu will define the hierarchy of the group next menu:

Figure 3.26 Sub-menu buying (purchasing) of the system shire council.

For each function group, identify the set of functions that are part of the
group concerned. If a function can be composed further into sub-function, the
function will be the group functions.
In making hierarchy continuation of each function group, the following
things can be a good starting point:
The level of the bottom of the menu.
79

 Paragraph section of the guide book.

A menu will connect on specific functions rather than groups function. After
analyzing, the tester can build a hierarchy of functions and function groups:

Figure 3:27 hierarchy of system functions shire council.

Defining functions functions
For each function, providing descriptions:
What should be done by the function.
How the function is supposed to work.

Figure 3.28 Description of the purchase order entry function (puchase order entry).

80

Detailed descriptions of the functions depending on the model, sometimes a

group of functions require more detailed description.
The following will be shown in the use of sequential interaction function
purchase order:

Figure 3:29 Layer 1 on the use of purchase order function.

Figure 3:30 Layer 2 of the use of purchase order function.

81

Figure 3:31 Layer 3 on the use of the function purchase order

Figure 3.32 Layer 4 on the use of purchase order function.

Figure 3:33 Layer 5 of the use of purchase order function.

82

Figure 3:34 Model DFD for purchase order entry functions.

Disaintes use functionalanalysis
Analyzing each function separately to define a set of criteria analysis test
each input and output processing functions to determine what is needed tests.
Focus on each function to analyze:
Criteria function.
Defining the criteria that determine whether a function has worked
correctly.
No. Kriteria

Test case

Pesanan pembelian disimpan berdasarkan

1 suplier terhadap produk-produk yang
PUR-POE-01-001
dipilih dengan kuantitas berbeda.
Produk-produk disimpan dalam pesanan
2 pembelian yang ditambahkan untuk
PUR-POE-01-002
produk-produk yang menunggu pengiriman
dalam stok inventori.

The outputs functions.

Identifying outputs to be generated by the system in order to support the
functions.
a.

Identify how the value obtained.

b.

Identify how the value specified is correct.

Inputs function.
Identification of inputs required to produce the output of each function.
83

No. Masukan

1 Supplier Number

Kebutuhan

Test case

Nomor suplier digunakan untuk

menghasilkan suatu pesanan
pembelian. Pesanan pembelian
disimpan berdasarkan pada suplier
yang bersangkutan.

PUR-POE-01-001
PUR-POE-03-001

Masukan yang belum dicakup: semua kecuali nomor suplier.

Identify how inputs are invalid treated.

The conditions of internal function.

Identification of internal conditions and output is expected to be generated.

Identifying what happens when the necessary conditions are not satisfied.

84

 Status-internal status functions.

Identify how internal status changed after receiving each input. How
internal status can be observed externally to check the truth of the status
change.

III.3.9 Use Cases

Collard provide articles that are useful in making a test of the use cases
[COL99A]. A use case is a sequential action taken by the system, which will
jointly produce the needed results system users. Use cases define the process flow
throughout the system based on usability as usual (manually).
Tests were made of the use cases will help in covering defects of the process
flow during actual use of the system. Is something that is not possible to make the
transition to other parts of the system when system usage is defined by the use
cases.
Use cases also include the interaction or the features and functions that are
different from the system. For this reason, the test is made of the use cases will
help in finding errors of integration.
Definition of use cases
Each use cases have:
Preconditions that must be met in order to use cases can work successfully.
Postconditions, defines the conditions under which use cases ends. Postconditions
also identify results that can be observed and the final status of the system after
the use case has been complete.
Flow of events, which defines the action of the user and the system responds
to the action taken. Flow of events is a compressed normal scenario, which
85

defines the general behavior of the system's use case, and the branches of the
alternative, which the other parts are already available can be used by use case.
Use cases also have parts that are shared. Use cases and test cases will work
fine in two ways, namely:
If the use cases of system kompit, accurate and clear, the manufacture of test
cases can be done directly.
If the use cases are not in good shape, then your test cases will help in
debugging the test cases.
Here's an example of creating test cases from a use cases.
An illustrative example
Manufacture of test cases from use cases is relatively straightforward, and
consists of the selection of paths exist on the use case. The existence of pathways
not only for the normal pathways, but also to alternative branches.
For each test case, the path is checked to be identified first, then the input
and output are expected to be defined. A single lane can result in many different
test cases, and also design black box testing techniques, such as equivalence
partitioning and boundary value analysis, should be used to obtain the conditions
for further testing.
A large number of test cases can be created using this approach, and calls
for the assessment to prevent an explosion in the number of test cases. As always,
the selection of candidate test cases should be based on the risks associated, as a
result of the error, the discovery of errors habits, frequency of use, and the
complexity of the use case.

86

Figure 3:35 Use case for selection of products on purchase orders.

Figure 3.36 Use case for selection of products on purchase orders.

87

An example of a test case, which is based on the use case above, as shown
in Figure 3:37.

Figure 3.37 Test normal case scenario for the selection of products on purchase orders.
Test cases negative
Negative test cases used to handle invalid data, also for scenarios in which
the initial conditions (preconditions) is not satisfied. There are several types of
negative test cases that can be made, namely:
Branches of alternative uses actions invalid user, as shown in Figure 3:38.

Figure 3:38 Test negative case in the purchase order.

The existence of inputs that are not in the list of test case. Including
violations initial conditions, such as trying to use case of the purchase order does
88

not have the status of "in progress", such as the addition of new items on a
purchase order that has been closed.

III.4 Other Techniques

There are many more engineering design test cases, are as follows:
III.4.1 Comparison Testing
Comparison testing or back-to-back testing is used in applications that have
a need for reliability is very important / critical, such as brake systems in cars,
aircraft navigation systems.
For the redundancy of hardware and software could be used in order to
minimize the possibility of error, using separate teams to develop different
versions but refers to the same specifications of the software, even if henceforth
there will only be one version that was released or used [BRI87].
Test cases are built using engineering design test cases that exist, such as
equivalence partitioning.
Tests were performed on each version of the same test data in parallel and in
real time to ensure consistency (output generated from each version is identical).
When different output or defect occurs in one or more versions of the
application, each investigated to determine where it died, and which application
version to make mistakes.
The methods do not find fault based on the specifications, the assumptions
used are the specs right, because if something goes wrong on the specifics of the
comparison testing becomes ineffective or fails to identify the error.
III.4.2 Test Factor Analysis
Test factor analysis is a process to identify factors test (variables or
conditions relevant to systems that are tested and can be varied during the testing
process), and options (options), and then using the similarities and variations to
determine the preferred combination of factors that will tested.
Minimum testing: (Mi-N + 1), Mi = Number of options each factor test, N =
Number of factors test Example:
89

 Factor 1: Configure computers - operating systems Win 95 / NT (2 Options)

Factor 2: Configure your computer - the hard disk of 1.5 GB / 2 GB (2
Options)
III.4.3 Risk Based Testing
Risk-based testing is a method to determine the priority for the design of test
cases.
Effectiveness Test = Number of defects found / estimate the number of defects
The risk factors outlined priorities that determine system requirements / test
cases are:
Visibility and effect on customers.
The risk of business operations.
History of the defect area of new / modified.
Business Continuity.
The level of complexity of the development.
Condition of the expected (positive testing).
Conditions are not expected (negative testing).
Priority level testing of the developer or contractor.
The level of trust developers.
The opposite of trust developers.
Observation tester to the credibility of the developer.
The desire and feelings of testers and users.

Scope.

III.4.4 Syntax Testing

Syntax testing [BCS97A] using a model system designed input syntax
formally, which is a way of use and incorporation of the words form a phrase.
Syntax testing is very useful for systems that use command lines for access to
such information.
Tests conducted for the representation of valid and invalid based on the
model of syntax.

90

Model represents syntax using a set of rules that defines how a valid
language form of iteration, sequential, and the selection of symbols or other forms
of language.
Select models are often available in programming languages, and can be
found at the end of the textbook and manual programming.
Test cases are built on rules that use a number of criteria that have been
defined in advance.
There are four things that must be considered in performing testing, where
the first three things related to syntax and semantics associated with the fourth:
A set of characters and symbols that are legitimized, for the construction of
basic blocks of input, such as "\", "a:".
The key words and the fields are constructed of characters and symbols.
Keywords are words that have a specific purpose, eg <copy>, <help>. A set of
grammatical rules for incorporation of key words, symbols and fields, and the
development of string that have meaning (command) of the components, eg the
<copy c: \ coba.txt a:>
A set of rules for how to interpret the commands, for example from the
<copy c: \ coba.txt a:> interpreted as a command to duplicate a file that has the
identity <coba.txt> of drive <c> to a floppy disk <a>.
III.4.5 Cross-Functional Testing
Cross-functional testing [COL97A] using matrix interactions between the
features of the system. Axis of matrices X and Y is a feature of the system, and
indicates the cell component that is updated by one feature and then used by
others.
The test is designed to examine the interaction of the matrix between the
features that have been didifinisikan in the matrix. Interactions can occur in two
types of dependencies, namely: directly with the passage of messages or
transactions among the features, or indirectly by their common data shared by the
features. Each dependency can cause a change in the status and behavior of the
corresponding features.
91

The key question to identify cross-functional test cases, is "What other

features will give a new result or modify the feature?". With this approach, the
only interaction that is expected to be tested. The interaction that seems
impossible not to be tested, so the volume and regression testing can be used.
Cross-functional external testing identified by analyzing the system
requirements and descriptions of linkages between features. This technique is
usually limited, because most interactions are not visible from the perspective of
black box (external).
Cross-functional testing iinternal identified by analyzing the architectural
design of gray box and white box code and data structures. The purpose of this
analysis to look at the interaction between software components (at the level of
design and data shared) and interactions of the components (at the level of code
and data private, internal). Tools to analyze static code automatically will be very
helpful.
Timing and synchronization event (event) is critical in the interaction
between features. Incident occurred late opening which means that the initial state
can not be done for the incident. Here is an example of cross-functional glimpse
testing:
Fitur

F1

F2

F3

F1

C1

M2

F2

M3

F3

M1

Notations of cells in the table above means that the features interact as
follows:
Features F1 updating the count C1 used by F2 features.
Features F2 do not update the count C1.
Features F3 send a message M1 to F1.
Features F1 sends a message M2 to F3.
Features F2 to F3 send a message M3.
92

III.4.6 Operational Profiling

Operational profile describes who the user is, what features are used,
frequency of use and conditions on which features are used, the hardware
environment and software used, as well as operating procedures and mechanisms
of how the feature is used.
Profile of use, can be estimated based on the pattern of work, or
extrapolated from actual measurements of the existing use. Has many tools that
provide analysis of the frequency of use of the line, the data file, or software
components on the overall system.
III.4.7 Table & Array Testing
Table is a form of data that are typically located outside the program, while
the array is in the program, which is used as the transfer of data from the table
(external) to be used in the program.
Table has two main forms, namely: sequential and air-index (keyed /
indexed).
Tests sequential use of table include:
Deleting data from an empty table.
Reading data from an empty table.
Add data to a table full.
Deleting the data from a table that has the data.
Read the latest data.
Reading of data following the last data.
Storing new data after recent data appears.
Running the data sequentially on the overall table.
Inserting data outside sequential data.
Insert the same data.
While testing the use of keyed on the table include:
Deleting the data of the first logic.
Deleting the data logic in the middle.
Delete the last data logic.
93

 Adding a new logic in the middle of the data.

Adding a new logic in the initial data.
Add the same data.
Adding a data with the wrong key.
Change the key fields in the data that already exists.
Changing a non-key fields in the data that already exists.
With the data and correct authorization.
With the data is correct, but without authorization.
With the authorization but the data is wrong.
Deleting the data that does not exist.
Update and rewrite the existing data.
Reading data from a file that is not open or does not exist.
Writing data to a file that can be read only status.
Writing data to a file whose version is wrong.

III.5 Use of Test Methods

Of the many engineering design test cases, as described above, to make it easier to
understand its use, given as an illustration of use, the list is based on the area of use in
testing a system (although it does not involve the entirety of the techniques / methods
existing tests), as follows :
Area aplikasi
Teknik Tes
Functional Analysis
Diskripsi fungsi dan fitur.
Spesifikasi logika keputusan (misal If-Then-Else). Black Box Path Analysis
Unit test code.

White Box Path Analysis

Masukan (GUI, queries, transaksi).

Boundary Value Analysis

Data tersimpan.

Table / Array Testing

Sejumlah besar populasi item yang sama (data

fields of records).
Sejumlah besar variabel yang mempengaruhi
testing.

Statistical Sampling

Frekuensi penggunaan pola.

Pola resiko.
Perubahan sistem yang ada.

Operational Profiling
Risk Assessment
Localized Test
Volume Test
Regression Test

94

Test Factor Analysis

CHAPTER IV
TESTING STRATEGY

IV.1 Approaches Testing Strategies

Testing is a collection of activities that can be planned and carried out more
systematically. For this reason a software testing framework, which is a collection of stages
that are formed from the test case design techniques and specific testing methods, shall be
defined for the process of the software.
A number of software testing strategy was held to provide a testing framework for
software developers with common characteristics as follows:
Testing starts from the smallest to the component level of integration between the
components in the overall computer system is achieved.
Mechanical testing vary according to the time of use.
Testing is done by software developers and (for large projects) carried out by an
independent test group.
Testing and debugging are different activities, but debugging must be accommodated
in each testing strategy.
A software testing strategy must accommodate testing at the low levels required for
the verification of a small segment of source code, whether it has been implemented
correctly. Similarly, testing at a high level that is used to validate the functions of major
systems to the needs / demands of customers. A strategy should provide guidance for
practitioners and a set of restrictions for the achievement of the manager. Because the
stages of testing strategies usually occurs at a time when pressure of a deadline began to
emerge, the development of performance should be measured and the problem should be
identified as early as possible.
IV.1.1 Verification and validation
Testing software is often associated with the verification and validation (V
& V). Where verification is a set of activities that ensure the software has been
performing a specific function correctly. While validation is a collection of

95

different activities of verification to make sure that software built is traceable to

the needs / demands of customers. According to Boehm [BOE81]:
Verification
"Are we building the product right?"
"Do we have made the products correctly?"
Validation
"Are we building the right product?"
"Do we have to make the right product?"
V & V covers most of the SQA activities, namely: formal technical review,
audit and quality configuration, performance monitoring, simulation, feasibility
studies, review documentation, review database, analysis algorithms, testing
development, qualification testing, and installation testing [WAL89]. Although
testing plays a very important role in V & V, but still needed other activities.
Testing is the last base where quality can be assessed and the error can be
identified. But testing should not be viewed as a safety net. As saying that, "You
can not perform tests on quality. If the quality was not there before you start
testing, then the quality will not be there when you are finished testing."
Quality is built into the software throughout the software engineering
process. The application of methods and aids, effective formal technical review,
management and measurement of solid leads to quality confirmed at the time of
testing takes place.
Miller [MIL77] linking software testing to quality assurance by stating that
"motivation is worth underscoring of the testing is to provide support for software
quality with methods that can be applied economically and effectively both on
large scale systems or small-scale systems."
IV.1.2 Organizing testing software
In any software project, there will be a conflict of interest is usually
different when testing begins. Generally, software testing is done by a software
developer itself. This will certainly make software testing becomes less functional
and creates confusion between testing itself with debugging.
96

From the psychological point of view as described in Chapter 2, there is a

very fundamental difference between psychology-oriented developers to build,
with the tester oriented psychology to ruin. So when developers are also given
responsibility for testing, then the developers will tend to design and execute
testing in order to prove that the program is working, rather than to look for errors.
In fact, this error is not covered will inevitably arise. And if it is not found by the
developer, the customers or users will find it.
There are a number of misconceptions, which will affect the previous
discussion it one way, namely:
Software developers do not need to perform testing at all. Software given to
another person (unidentified credibility), which will conduct tests on the software
without understanding and misdirected. The new tester work or participate in the
project, only where the testing phase on the project began.
Software developers are always responsible for testing unit (components)
program, ensuring every unit is working on the design. In many cases, developers
also perform integration testing - a testing step that leads to the construction and
testing of the overall program structure. Only after the software architecture are
complete, independent test group (Independent Test Group - ITG) will be
participating in it.
The aim of the group of independent tests is to avoid the problems
associated with allowing the manufacturer to test it has itself created. In addition a
group of independent tests to avoid conflict of interest. And personnel of the
group of independent tests are paid to find errors.
In any case the developer can not cast their responsibilities in an
independent test group for granted. They were with a group of independent tests
have to work together throughout the project to ensure the tests have been done
well. And when the tests have been performed, the developer should be able to
correct the errors found.

97

Groups of independent tests are part of a software development project team

will be involved during the specification and continue to participate in activities
(planning and specification of test procedures) throughout a large project.
Report of the independent test group (ITG) in many cases given to
organizations SQA, and independence will not be achieved if they were inside
part of software engineering organization.
IV.1.3 software testing strategy
Software engineering process can be seen as a spiral as illustrated in Figure
4.1. At first, the system defines the task of software engineering and software
leads to a needs analysis, which identifies the information domain, function,
behavior, performance, constraints, and validation of the software has been set.
Moving into the whole spiral, from design to end on coding. In the development
of computer software, the process moves from outside to inside to follow a spiral
path that will lower the level of abstraction at every turn.

Figure 4.1 Strategy testing.

The process from a procedural standpoint, testing in the context of software
engineering is actually a series of four stages, which are implemented
sequentially, as shown in Figure 4.2. At first, the focus lies in the test each
component individually, determine whether the function of these components can
be categorized as a unit. Therefore, given the name of unit testing. Unit testing
will be very much use of white box testing techniques, examine certain path in a
control structure of modules to ensure complete coverage and the maximum error
detection. Furthermore, the components must be arranged or integrated to the
98

complete software packages. Integration testing with regard to matters relating to

problems of verification and construction program. Test case design technique is
dominant black box used for integration, however a certain number of white-box
testing will also be used to ensure coverage of the major control lines. Once the
software has been integrated (constructed), a set of high-level tests performed.
Validation criteria (set out in the analysis of needs), to be tested. Validation
testing is the final part is to make sure the software has met all functional,
behavioral, and performance, as expected. Black box testing techniques used
exclusively for validation.
The last stage, high-order testing, are outside the area of software
engineering and fit into the larger context of computer systems engineering. When
validation software, must be combined with other system elements (such as
hardware, human, databases). System testing verifies that all elements are bound
to one another as they should be, and the overall functioning / performance of the
system is achieved.

Figure 4.2 Stages of software testing.

IV.1.4 Criteria compliance testing
Classic questions that arise every time when discussing testing software,
"When will we be able to complete the testing - how can we know what you've
tested enough?" Unfortunately, there is no definitive answer to this question, but
there are some responses pragmatic and empirical guidance.
99

One response pragmatic, stating: "You never finish testing, simple way, is
transferring the responsibility of testing of your (engineers, software) to your
customers." Every time a customer / user executes a computer program, then the
program has been tested. Because of this there needs to be other activities of the
SQA.
Musa and Ackerman [MUS89] develops a model of a software error
(obtained during testing) as a function of the execution time, based on statistical
modeling and reliability theory. This model is called a logarithmic Poisson
execution-time model, taking the form of:
f (t) = (1 / p) ln (l0 p t + 1)
Where :
f (t) = Number of expected cumulative error occurred when the software in a
test for an execution time, t.
l0 = initials of the intensity of a software error (error per unit time) at the
beginning of testing.
P = Reduction exponentially intensity error when an error has been fixed.
Intensity error, l (t) can be reduced by lowering the derivation of f (t): l (t) = l0
/ (l0 p t + 1)
With equation l (t) above, the tester can predict drop in errors of the results
of the performance testing process. The intensity of the actual error can be plotted
against the prediction curve (figure 4.3). If, for some reason that makes sense, the
actual data obtained during testing and logarithmic Poisson execution-time model,
contiguous between each other at each point of the data, then the model can be
used to predict total testing time is needed to reach the intensity error low and
acceptable. By collecting measurement data during testing software and modeling
the reliability of the existing software, allowing it to develop guidance means to
answer the question: "When will we be able to complete the testing?" Although
there is still a debate, but the empirical approach that there is better to consider its
use, rather than just based on intuition roughly.

100

Figure 4.3 Intensity of error as a function of the execution time.

IV.2 Issues Testing Strategies

No matter how good testing strategy will fail if a series of issues following testing
strategy is not well considered. Tom Gilb [GIL95] provide arguments against these issues,
so that software testing strategy can be successfully implemented:
Specifications of product needs to be quantized, must be determined long before
testing begins. Although objectivity of testing is to find errors, a good strategy is also
assessing the quality characteristics, such as portability, maintainability, and reusability.
Where it should be specified in a way that can be measured, so that the testing is not
confusing.
Stated explicitly testing objectivity. Objectivity specific testing must be expressed in
a form that can be measured. For example, the effectiveness of the test, test coverage,
while the average error, the cost of finding and fixing errors, the frequency of occurrence
of the error, and the working hours per test regression tests, all of which must be stated in
the test plan [GIL95].
Understanding the software and develop a profile for each user category. Use-cases
that describe interaction scenarios for each class of users can reduce the overall testing
effort with a focus on the actual use of the product.

101

Develop a testing plan that is based on a "rapid cycle testing". Gilb [GIL95]
recommends a software engineer team to learn to do a test on a strict cycle (2 percent of
project effort) of customer use. The resulting feedback can be used to control the level of
quality and test strategies are concerned.
Create software which is strong (robust), which is designed to test himself. Software
should be designed using techniques antibugging. So the software can diagnose certain
error classes. In addition, the design should accommodate automated testing and regression
testing.
Use Formal Technical Review (FTR) which is effective as a filter specific testing.
FTR can be as effective as testing in covering error. For this reason, reviews can reduce the
amount of testing effort, which is needed to produce high-quality software.
Make Formal Technical Review to assess the test strategy and test cases themselves.
FTR may include inconsistencies, irregularities and errors of approach to testing. This will
save time and improve the quality of products.
Develop a sustainable development approach to the testing process. Test strategy
should be measured. Measurements collected during testing should be used as part of a
statistical process control approach to testing software.

IV.3 Unit Testing

Unit testing focuses pad verification effort on the smallest unit of software design software components or modules. The use of component-level design descriptions as a
guide, an important control lines were tested to find errors, limited to the module. The
relative complexity of the tests and errors that are covered are restricted by the limits of the
coverage has been assigned to the unit testing. Oriented unit testing white box, and stages
can be performed in parallel on many components.
IV.3.1

Things that need to be considered in unit testing

Tests found in unit testing:
Interface modules are tested to ensure the flow of information has been
running as expected (in and out of the unit tested program).

102

Local data structure is checked to ensure the integrity of data storage has
been taking care of temporally during the execution phase of the algorithm.
Range of conditions tested to make sure the module is operating correctly on
the limitations defined for processing limitations or restrictions.
All independent paths (basis paths) in the control structure is inspected to
ensure all statements within the module has executed at least once.
All error handling lines tested. Test data flow between modules initialization
is required before other tests. If the data is not in and out properly, all the other
tests doubt. In addition, the structure of local data to be checked and determined
as a result of the global data (if possible) during unit testing.
Selection of the execution path testing is an essential task for the unit tests.
Test cases shall be designed to include errors of computation is wrong, the
comparison is not correct or control flow that is not right. Base path and loop
testing is an effective technique for this.
Computing common mistakes:
Error arithmetic priority.
The operation mode mixture. Initialization is not true.
Inaccuracy precision.
untruth symbolic representation of expression.
Comparison and flow control is a unity.
Usually change the flow of control occurs after comparison.
Test case should include error:
Comparison of different data types
Logical operators and the priority that is not true
The possibility of the equation if the error precision, making the results of
the equation is not as expected.
Error comparison between variables.
Termination loop inconsistent or improperly.
Failure exit iteration when conflict occurs.
Modify the loop variable undue.
103

Good design includes anticipated error conditions and error handling path is
set to be reusable or termination of the cleaning process at the time the error
occurred. This approach is referred to as antibugging by Yourdon [YOU75].
Potential errors that should be tested during the evaluation of error handling:
Description of the error is not clear.
Note the error does not function to calculate the error.
Error conditions causing interference to the system specific error handler.
processing exception conditions are not right.
Description of the error does not provide enough information to direct cause
of the error.
Limitation of testing is the final task of unit testing. Software has sometimes
failed to limitations. Mistakes sometimes happen when the element to n of ndimensional array to be processed, when repetition i of the loop is done, when the
maximum and minimum values are calculated.
IV.3.2 unit test procedures
Unit testing is generally seen as a continuation of the process of coding
stages, with the following procedures:
Once the code is developed and verified against the relevant componentlevel design, test case design of the unit test begins.
Review design information provides guidance to define test cases in order to
approach the overall fault coverage in each category, as discussed
previously.
Each test case should be linked with the expected results.
Because the component is not a stand-alone program, or stubs drivers and
software must be developed for each unit test.
In most applications drivers no more than a "major program" which received
data is test case, enter data into the component that is being tested, and print the
results in question.
Stubs apply to replace modules that are subordinate (called by) the
component being tested. Stub or "dummy subprograms" using the interface
104

module subordinate, may perform data manipulation minimal, print verification

input, and returns control to the module being tested.
Drivers and stubs incurring the overhead. Because the software must be
additional code (usually not based on formal design), which was not included
when the software product is released. When drivers and stubs is quite simple, the
actual overhead becomes relatively low. But in fact, most of the components is not
enough just to do a test with low overhead (simple). In certain cases, testing can
be delayed completion (complete condition) until the integration test stage (where
drivers or stubs are also used).
Unit testing is simplified when a component is designed with high cohesion.
When only one function is addressed by a component, the number of test cases
can be reduced and errors can be easier to predict and covered.
There are some situations where resources are not sufficient to perform a
complete unit testing. For that we need an election critical modules and having a
high cyclomatic complexity, for unit testing.

IV.4 Integration Testing

When each module in a software as a whole has escaped from unit testing, will arise
the question: "If all the software modules have worked well individually, why should there
be any doubt whether the modules can work together as one entity?" problems must be
available at the interface. Data will be lost on an interface, a module may still be
irregularities or errors that affect other modules, the lack of precision may be able to
enhance the error rate calculation results are not acceptable (outside the tolerance limit),
and so on, list- the list of possible problems that may occur on the interface of integration
between these modules will continue to multiply along with the increasing number of
modules that will be integrated into the software.
Integration testing is a systematic technique for the construction of the structure of
the program, while at the same time doing testing to get the errors associated with the
interface. Objectivity is to follow up the components that have been through unit testing
and build a program structure in accordance with a design that has been written before.
105

There is a tendency to do that is not gradual integration, using an approach of "Big

Bang". This approach combines koomponen-components together to form a program.
Testing performed on the entire course simultaneously. And chaos is the usual result
obtained. A set of errors will be obtained, and the repair is difficult, because there were
complications when performing the isolation of the cause of the problem. Coupled with the
emergence of new errors when the errors previously addressed, thus creating a cycle of
unending.
Integration is achieved in stages is the opposite of the use of the strategy of "Big
Bang". The program is constructed and tested in gradually, gradually increased, which in
case of errors can be easily isolated and corrected, the interface can be tested as a complete
or at least closer to complete, as well as a systematic approach to testing can be used.
IV.4.1 Rational Top-down integration
Is a phased approach to structure the program. The modules are integrated
from top to bottom in a hierarchy of control, starting from the main control
module (main program). Module sub-ordinate of the main control module can be
connected to the structure of the most deep (depth-first integration) or the most
extensive (breadth-first integration) first.
Based on Figure 4.4, depth-first integration, will integrate all the
components of the structure of the major control lines. Eg been the left side first,
then the components of M1, M2, M5 will be integrated first, then M8 or M6 will
be integrated Breadth-first integration, will integrate all the components directly to
each level, moving horizontally. Examples of components M2, M3 and M4 will
be integrated first and then the new M5 and M6, and so on.

106

Figure 4.4 Top-down integration.

Five-step integration process:
1. The main control module is used as a test driver and stubs test is substituted
for all components directly into a sub-ordinate main control module.
2. Depending on the selected integration approach, subordinate stubs are
replaced with actual components.
3. The tests were conducted as each component is integrated.
4. When the fulfillment of each test, the other stubs are replaced with actual
components.
5. Regression Testing is done to ensure that new errors do not happen again.
6. The process continues from step 2 to the overall structure of the program
passed.
Top-down integration strategy verifies major control or decision points early
in the testing process. In a program structure that is factored well, decisionmaking occurs at the top level in the hierarchy and therefore taken into account in
advance. If major control problems, it takes the initial introduction. If depth-first
integration is selected, a complete functionality of the software will be
implemented and demonstrated.
This approach looks complex, but in reality, logistical problems would arise,
because the bottom level of the hierarchy is needed to test the upper level. Stubs
replace the module below levels at the commencement of top-down testing; hence
no data is flowing upward from the structure of the program.
107

Tester has only three choices:

Snooze most tests until stubs are replaced with the actual module, this
causes the loss of some control related inter certain tests and certain modules.
Surely it would be difficult to determine the cause of the errors and the tendency
of violation of the limitations of top-down approach.
Develop stubs that have limited functionality to simulate the actual module,
may be done, but will add to overhead costs with increasing complexity stubs.
Integrate software from the ground up in the hierarchy, is referred to as
bottom-up integration.
IV.4.2 Bottom-up testing
As the name implies, this integration starting from the smallest module.
Because the components are integrated from the ground up, sub-ordinate to the
respective levels of components are always needed to be processed, and the need
for stubs can be eliminated.
The steps of this strategy are:
1. The lower level components combined into clusters (sometimes called builds)
which represents a sub-function of certain software.
2. Driver written to coordinate test case input and output.
3. Cluster tested.
4. Driver removed and combined cluster, moving upward in the program
structure. The integration follows the pattern as illustrated in Figure 4.5.
Components are combined to form a cluster 1, 2 and 3. Each cluster tested
using the driver. Components in cluster 1 and 2 are subordinate Ma. Driver D1
and D2 is eliminated and the cluster is connected directly to Ma, and so on.

108

Figure 4.5 Bottom-up integration.

When the integration is increasingly moving to the top, the need for a
separate test drivers will also be less. In fact, if the two upper levels of the
structure of the integrated program from top to bottom, the number of drivers will
be considerably reduced, and the integration of clusters would be greatly
simplified.
IV.4.3 Regression testing
Every time a new module is added as part of the integration testing, there
will be changes of software. The new channel from the data stream (data flow)
that has been set, the presence of the I / O of new, and the new control logic.
These changes will allow the problems with functions that previously had worked
well. In the context of strategy integration testing, regression testing is the
execution back from a subset of the tests that have been carried out to ascertain
whether the changes made are correct and does not cause the side effects are not
expected.
In a broader context, if a test result (of any kind) succeeded in finding
errors, and errors must be corrected. When the software is corrected, some aspects
of the configuration software (programs, documentation or supporting data)
modified. Regression testing is an activity that helps to ensure that the changes
109

that occur tealah correct and does not cause unwanted behavior or additions
errors.
Regression testing can be done manually, by executing the back of a subset
of the overall test cases or use automation tools capture / playback. Tools capture /
playback software allows technicians to record test cases and results for both
reusable and compared at certain sequences or entire sub. Sub-set of tests
executed consists of three classes of different test cases:
Representation of examples of tests that will check all functions of the
software.
Additional tests that focus on software functions that may be affected by the
changes.
The test focuses on software components changed.
When integration tests conducted, the number of regression tests will
increase to quite large. Therefore, regression tests should be designed to cover
only the same tests or some classes of errors in each of the major functions of the
program. Is impractical and inefficient to execute the back of each test for each
function program when a change occurs.
IV.4.4 Smoke testing
Smoke testing is integration testing approach that is often used when a
software product "limited small" was made. Designed as a mechanism to deal
with the critical time of a project, enabling software teams to run the project with
a base frequency. Fundamentally, the approach consists of testing smoke-activity
following activity:
Software components that have been translated into code, be integrated to
"build", which consists of all data files, libraries, modules are used again, and
components are developed that are needed to implement one or more functions of
the product.
A series of tests designed to generate an error that would make "build"
continues to function as it should. Intention must include a "show stopper" errors
that have the greatest likelihood of making a software project experienced delays
110

of schedule. "Build" integrated with "build" and a whole other products that do
smoke tests daily. Integration approach can be top-down or bottom-up.
Daily frequency of testing the entire product may surprise some readers. In
any case, the tests are often done this will provide a realistic assessment of the
work process integration testing for managers and practitioners. According to Mc
Connell [MCO96], smoke tests are as follows:
"Smoke tests should check the entire system from end to end. We need not
complete, but is able to show major problems. Smoke tests should be fairly
systematically run "build", it can be assumed that he is stable enough to perform
the test fairly systematically. "
Smoke testing can be characterized as an integration strategy that rotates.
Software rebuilt (with the new components were added) and checked daily.
Smoke testing provides a number of advantages when used in an engineering
project for time-critical and complex, as follows:
Minimizing the risk of integration. Because it is done per day, mismatch and
a "show stopper" Other errors may be seen per day, so a change in the schedule
due to the occurrence of serious errors can be reduced.
Increasing the quality of the final product. Because of the integrationoriented approach, smoke tests encompass functional errors and architectural and
component level design errors. This error can be corrected as soon as possible, the
better quality is obtained.
Simplified fault diagnosis and correction. As with all approaches integration
testing, errors were found during smoke testing associated with "an increase in
new software", where the software has been added to "build" that might lead to
the discovery of new errors.
Assessment work processes easier. With the passing of days, the software
has been integrated more and more that have been demonstrated to work. This
increases the morale of the team and give the manager a good indication that the
work processes have been implemented.

111

IV.4.5 Comments for integration testing

Has been much discussion (such as [BEI84]) about the strengths and
weaknesses of top-down than bottom-up integration testing. In general, the
benefits of the strategy tends to produce a weakness for other strategies. The main
drawback of the top-down approach is the need stubs and the difficulties of testing
incurred in connection with it. The problems associated with the stubs will be
offset by the advantage of testing the functions of major control early. The main
drawback is the bottom-up integration where "program as an entity will not be
there until the last module added" [MYE79]. This weakness was offset by the
simplicity in the design of test cases and the lack of use of stubs.
Selection of the integration strategy depends on the characteristics of
software, and sometimes in the project schedule. In general, the combination
approach (sometimes called sandwich testing) that uses a top-down integration
testing for the upper level of a program structure, combined with bottom-up
integration testing for the subordinate level is the best thing.
If integration testing is performed, the tester must identify critical modules.
Characteristics of critical modules:
Depending on some software needs.
Have a high degree of control.
Have a high complexity (cyclomatic complexity is used as an indicator).
Have specific performance requirements defined.
Critical modules should be tested as early as possible. In addition,
regression testing should focus on critical module function.
IV.4.6 Documentation integration testing
Overall software integration plans and specific description of the test is
documented in test spesification. This document contains the test plans and test
procedures. Is a product of the work on the software process and become part of
the configuration software. Test plan describes the overall integration strategy.
Testing is divided into phases and "build" indicating functional
characteristics and certain behavior of the software. Each phase and sub-phase
112

determines the overall functional categories in the software and are generally
linked to a particular domain of the structure of the program.
Hence "build" program was created based on each phase. Criteria and things
- matters relating to the tests used in all phases of the test:
Integrity interface. Interface on the internal and external tests each module
(cluster) is connected to the structure.
Validity functional. The test is designed to find functional errors committed.
Fill in the information. The test is designed to find the error associated with
a local or global data structures.
Performance. The test is designed to verify the performance of relevant predefined during the design of the software is done.
A schedule for the integration, development of software overhead, and
related topics are also discussed as part of a test plan. Start and end dates for each
phase of the set and the "availability windows" for modules that do the test unit is
defined. A brief description of the software overhead (stubs and drivers) to
concentrate on those characteristics that may require special effort. Finally, the
environment and resources didiskripsikan test. The hardware configuration of
unusual, exotic simulators, and tools or special test technique is a piece of the
many topics that will be discussed.
Detailed testing procedures required to complete the test plan are described
next. The order of integration and testing are concerned at each stage of
integration are described. A list of all test cases and results are expected to be put.
A history of test results, problems, real-time items recorded in the test
specifications. The information contained in this section can be vital during
treatment (maintenance) software. References and Appendix Appendix-used are
also displayed.
Like all the other elements of a software configuration, test specification
format allows to be created and tailored to local needs rather than a software
engineering organization. It is important to note, however, an integration strategy

113

(covered in a test plan) and detailed testing (test procedures are described in a) are
elements that are essential and necessary.

IV.5 Validation Testing

When integration testing reached its culminating point, the software has been
assembled into a complete package, interface errors have been covered and addressed, and
a series of final tests of the software, the validation testing can begin. Validation can be
defined in many ways, but simply (Albeit Hash) defines that the validation is successful if
the functions of the software can meet customer expectations and be accountable.
Expectations can be accounted defined in the Software Requirements Specification
document, which describes all of the attributes of software that can be viewed by the user.
The specification includes a section called validation criteria. The information contained in
the section membantuk elementary approach to validation testing.
IV.5.1 Criteria validation testing
Validation software is accomplished through a series of black-box testing,
which tests the fulfillment of needs.
Plans and procedures designed to ensure that the functional demands have
been satisfied, all the characteristics of behavior has been achieved, all the
performance demands are met, correct documentation and design as well as other
requests have been fulfilled (transportability, compatibility, error recovery,
maintainability)
Each test case validation is done, there will be one or two possible
conditions:
1. Characteristics of function or performance meets specifications and is
accepted or
2. A deviation from the specification has been covered and made a list of
deficiencies. Deviation or error is found at this stage, in a project, it is very
rare to be corrected on time in accordance with the time deliverables that
have been scheduled. Sometimes the necessary negotiations with customers
to establish a method of solving the problem of deficiency.
114

IV.5.2 configuration Review

An important element in the validation process is a review of the
configuration. Which aims to make sure all of the configuration software has been
developed correctly, has been cataloged correctly and sufficiently detailed to
increase support to the phases of the software life cycle. Review configuration
commonly called auditing.
IV.5.3 Alpha and beta testing
It is impossible for the developer of software for virtual, predict how users
or customers will use the program. Instructions that can be used may be
interpreted wrongly, combinations of odd data out of the ordinary, it seems clear
output for the tester may be not the case for the user.
When the software was custom made for the customer, a series of
acceptance testing will be done to help customers perform validation on all needs.
Mostly done by the end user rather than by software engineers, an acceptance
testing may be in a range from an informal "test drive" to a series of tests planned
and executed systematically. In fact, acceptance testing can be done for weeks or
months, so search cumulative errors will make the system degradation over time.
If the software was developed as a product to be used by many customers, it
is not practical to undertake formal acceptance testing for each of these customers.
Generally the product makers will use a process known as alpha and beta testing
to get errors, which seems to be just the end user can find it.
Alpha test was conducted on a developer environment. Software used in the
natural setting is seen from the side of the developer. And storing errors and
usability issues. Alpha test was conducted in a controlled environment.
Beta test carried out on one or more of customer environments by the
software. Beta testing is a software application in a real environment can not be
controlled by the developer, the user save all the problems that occurred during
the beta testing and reported it to the developer within a certain time. And the
result of the problems reported during the beta test, software engineers make
modifications and then release a software product to the entire customer base.
115

IV.6 System Testing

In fact, the software is just one element of a computer-based system is greater. And
software associated with elements of other systems (such as: hardware, human and
information), as well as a series of integration and system validation tests performed. This
test is outside the limits of the software process and not done alone by software engineers.
However, the steps taken during the design and testing of software can greatly increase the
chances of successful software integration in a larger system.
Problems occur when the classic system testing error is not covered and every
element of the system blame the developer. To deal with this nonsense, software designer
must anticipate problems - potential problems to be faced:
error handling path designed to handle all the information that comes from the other
elements in the system,
perform a series of tests that simulate me incorrect data or other potential errors at
the interface software,
store the test results as evidence, and use it as evidence in case occurs recriminations
who is at fault,
and participate in the planning and design of a system to ensure that the software has
been tested properly.
System testing is actually a series of different tests from the main purpose to check
the computer-based systems in full. Although each test have different objectives, all
working to verify that the system elements have been integrated properly and perform
functions that have been determined. In the following section, we will clarify the types of
system tests [BEI84] common for computer-based systems.
IV.6.1 Recovery testing
Most computer-based system repair faults and restart the process at any
given time. In certain cases, the system must have fault tolerance that processing
errors did not cause the whole system to stop functioning. In other cases the
system error must be corrected within a certain time or economic loss will occur.
Recovery testing is a test system that forces the software to fail in many
ways, and verify that the recovery system is running well. When automatic
116

recovery is done by the system itself, you should evaluate the validity of the reinitialization, checkpointing mechanism, data recovery, and restart. If the recovery
requires human intervention, the mean-time-to-repair (MTTR), average time of
repair, is evaluated to determine whether it is still within acceptable limits.
IV.6.2 Security testing
Each computer-based system that is managing sensitive information or
cause actions that could hurt the people as a target of penetration unhealthy or
illegal, requiring safety management system of the system.
Security testing is used to verify the protection mechanism, built into the
system will protect the system from unwanted penetration. Security systems
should be tested for direct attacks (frontal) and indirect (way back). During
security testing, the tester plays tasks as those who want to penetrate the system.
With time and adequate resources, good security testing will penetrate the
system with very great. The task is to make the system designer penetration costs
more than the value of the information observed.
IV.6.3 Stress testing
During the initial stages of testing software, technical white-box and blackbox produced by the evaluation of the functions and performance of normal
programs. The stress tests are designed to expose the program to an abnormal
situation.
Stress Testing executing the system in a condition where the resource needs
are not normal in quantity, frequency or volume, for example:
Special tests designed to make ten interrupts / sec in which one or two
intrupsi an average value.
Test cases requiring maximum memory or other resources executed. In
essence, the tester must try to stop the system.
Variations stress testing is sensitivity testing. In some situations (most often
mathematical algorithms), data is very small interval will cause extreme
conditions even a process error or performance degradation.

117

Sensitivity testing is used to include a combination of data in classes of

valid inputs that might cause instability or undesired processing.
IV.6.4 Performance testing
For systems with real-time and embedded, although the software has been
providing necessary functions, but does not perform according to what was
requested, the software remains unacceptable.
Performance testing is done to test the performance of the software in
runtime in the context of an integrated system. Performance testing occurs at all
stages of the testing process. Even at the unit level, the performance of individual
modules will be assessed simultaneously at the time of white-box tests were
performed. However, not all elements can be fully integrated, so that the actual
system performance can be sure.
Performance testing combined with regular stress testing and usually
requires instrumentation software and hardware. Therefore, often need to measure
the utility of resources (such as processor cycles) are exact. External
instrumentation can monitor the execution interval, log events (such interupts)
when they occur, and the status of the machine on a regular basis. With
menginstrumentasikan system, the tester can cover situations that may have a
tendency to lead to degradation and system failures.

IV.7 Debugging Art

Testing software is a process that can be planned and systematically specified.
Design test case can be done, a strategy can be defined, and results can be evaluated
against the expectations that have been written previously.
Debugging occurs as a consequence of successful testing. That is when the test case
found the error, debugging is the process of removing error.
Although debugging can and should be a sequential process, debugging is still an art.
Software engineers in evaluating the results of a test, sometimes faced with the problem
indication of symptom causes of the problem of the software in question. Namely, the

118

external manifestation of the internal causes of the error and error that may not have a
direct relationship with each other.
IV.7.1 debugging process
Debugging is not testing but always occurs as a consequence of testing.
Based on Figure 4.6, the debugging process starts from the execution of the test
case. The results are assessed and the lack of correspondence between the
expected performance with actual performance calculated. In many cases, data
corresponding to an indication of a hidden cause. The process of debugging is the
process to match inidikasi with the cause so it can direct the error correction.

Figure 4.6 The process of debugging.

Debugging process always has two results:
1. The cause is found and corrected.
2. The cause is not found.
Debugger will estimate the cause, and design the test case to assist in the
validation of estimates of the cause, and correcting errors in a form that iterates
through the process.
Why debugging very difficult? Human psychology is the main reason that
more technology than the software itself. Here are a few characteristics of bugs
provide some clues:
119

Indications and the cause may be triggered geographically. That indication

will appear as part of the program, where the actual cause is located elsewhere.
Indication may disappear temporarily when another error corrected.
Indications may be caused by non rounding error eg inaccurate. Indications
are caused by human error that can not easily be tracked. Indications are caused
because of the time rather than the process. It would be difficult to accurately
reproduce input conditions, such as the real time applications. Indications may be
influenced by the interaction of the system software and hardware. Indications
may be due to the way tasks are distributed among different processors.
IV.7.2 Consideration psychology
It is unfortunate some evidence suggests that debugging capabilities
depending on the talent of the man. Although experimental evidence against
debugging is open to many interpretations, but most variants of the experiment in
debugging capabilities that have reported using sampling data, programmers who
have the same education and experience.
Shneiderman [SHN80] states that: "Debugging is one of the few parts of the
programming frustrating. He has elements of problem solving or sense of the
brain, coupled with matching the experience of the mistakes that have been made
previously. The level of nervousness and inability to accept the possibility of
errors increases the difficulty of the task of debugging. Fortunately, there is a
sense of relief and a big reduction in tension, when a bug in the end ... .. has been
corrected."
IV.7.3 approach to debugging
There are generally three categories of debugging approaches [MYE79], namely:
Brute force is the most common method and is not efficient for the isolation
of a software error causes. The application of brute force, is only done when other
approaches have failed. Using the philosophy of "let the computer find the error,"
such as the lack of memory, etc., which is expected in a chaos of information
generated, will be able to find clues that may lead to the cause of an error.
Although a lot of the information generated will make the process of debugging
120

successful, will be many things to spend effort and time in vain. Intellect must be
used first.
Backtracking is a fairly common method that is usually used for small
programs. Starting from where indications have been covered, source codes
manually traced back to the place where the cause is found. Unfortunately, along
with the increasing number of lines of code, the number of potential paths to the
back tracking will become more and more also and not termanajemeni.
Cause Elemenation is a manifestation of induction or deduction and using
the concept of binary partitioning. Data related to the error was organized to
isolate potential causes. Developed a hypothesis about the cause and the data
needed to prove or thwart this hypothesis.
Alternatively, a list of all the possible causes of developed and do tests to
eliminate each of these possibilities. If the initial test indicates that a portion
hypothesis about the cause looks potentially, the data formed in order to isolate
the bug.
When a bug is found, then the correction should be done about it. Van Vleck
[VAN89] gives three simple questions, each of which software engineers must ask
first before making corrections and eliminate the cause of a bug:
1. What is the cause of the bug is generated again in another part of the program?
In many situations, the program defect caused by an incorrect logic
pattern that may be generated again in another tempat.Pertimbangan explicit
logic pattern, is the possibility that the result in the discovery of other errors.
2. Is the next bug is the result of the improvements that have been made?
Before the correction is done, the source code (or design) should be
evaluated to assess pair data structure and logic. If the correction is performed
on parts that have a high level of engagement in the program, must pay special
attention when any change is made.
3. What can be done to prevent the occurrence of bugs in the beginning?

121

If the process is corrected then the product will automatically corrected.

The bug can be eliminated from the current program and will be removed
from all future programs.

122

REFERENCES
[AMB95] Ambler, S., Using Use Cases, Software Development, July 1995, pp. 53-61.
[BCS97A] British Computer Society Specialist Interest Group in Software Testing (BCS
SIGIST), Standard for Software Component Testing, Working Draft 3.2, 6 Jan 1997.
[BEI84] Beizer, B., Software System Testing and Quality Assurance, Van Nostrand-Reinhold,
1984.
[BEI90] Beizer, B., Software Testing Techniques, 2ndPP ed., Van Nostrand-Reinhold, 1990.
[BEI95] Beizer, B., Black-Box Testing, Wiley, 1995.
[BER92] Berson A., Client Server Architecture, McGraw-Hill, 1992.
[BER93] Berard, E.V., Essays on Object-Oriented Software Engineering, Vol. 1, AddisonWesley, 1993.
[BIN92] Binder, R., Case Based Systems Engineering Approach to Client-Server
Development, CASE Trends, 1992.
[BIN94] Binder, R.V., Object-Oriented Software Testing, Communications of the ACM, Vol.
37, No. 9, September 1994, p. 29.
[BIN94A] Binder, R.V., Testing Object-Oriented Systems:A Status Report, American
Programmer, vol. 7, no.4, April 1994, pp. 23-28.
[BIN95] Binder, R., Schenario-Based Testing for Client Server Systems, Software
Development, Vol. 3, No. 8, August 1995, p. 43-49.
[BOE76A] B. W. Boehm, Software engineering, IEEE Transactions on Computer, Dec 1976.
[BOE81] Boehm, B., Software Engineering Economics, Prentice-Hall, 1981, p.37.
[BRI87] Brilliant, S.S., J.C. Knight, and N.G. Levenson, The Consistent Comparison Problem
in N-Version Software, ACM Software Engineering Notes, vol 12, no. 1, January 1987, pp. 2934.
[Col97A] R. Collard, System Testing and Quality Assurance Techniques, Course Notes, 1997
[Col99A] R. Collard, Developing Test Cases from Use Cases,Software Testing and Quality
Engineering, Vol 1, Issue 4, July/August 1999
[CUR86] Curritt, P.A., M. Dyer, and H.D. Mills, Certifying the Reliabililty of Software,IEEE
Trans. Software Engineering, vol. SE-12, no. 1, January 1994.
123

[CUR93] Curtis, B. etc. Capability Maturity Model, Version 1.1. Technical Report. Software
Engineering Institute. Carnegie-Mellon University. 1993.
[DYE92] Dyer, M., The Cleanroom Approach to Quality Software Development, Wiley, 1992.
[FAR93] Farley, K.J., Software Testing For Windows Developers, Data Based Advisor,
November 1993, p. 45-46, 50-52.
[HOW82] Howden, W.E., Weak Mutation Testing and the Completeness of Test Cases, IEEE
Trans. Software Engineering, vol. SE-8, no. 4, July 1982, pp. 371-379.
[HUM94] Humphrey, Watt S. Managing the Software Process. Addison-Wesley: Reading. MA.
1994.
[IEEE83A] IEEE Standard, Standard for Software Test Documentation, ANSI/IEEE Std 8291983, August 1983
[JON81] Jones, T.C., Programming Productivity: Issues for the 80s, IEEE Computer Press,
1981.
[KAN93] Kaner, C., J. Falk, and H.Q. Nguyen, Testing Computer Software, 2ndPP ed., Van
Nostrand-Reinhold, 1993.
[KIR94] Kirani, S. and W.T. Tsai, Specification and Verification of Object-Oriented
Programs, Technical Report TR 94-64, Computer Science Department, University of
Minnesota, December 1994.
[LIN94A] Linger, R., Cleanroom Process Model, IEEE Software, vol. 11, no. 2, March 1994,
pp. 50-58.
[LIP82A] M. Lipow, Number of Faults per Line of Code, IEEE Transactions on Software
Engineering, Vol 8, pgs 437 439, June, 1982.
[MCG94] McGregor, J.D., and T.D. Korson, Integrated Object-Oriented Testing and
Development Processes, Communications of the ACM, Vol. 37, No. 9, September 1994, p. 5977.
[MCO96] McConnell, S., Best Practices:Daily Build and Smoke Test, IEEE Software, vol. 13,
no. 4, July 1996, 143-144.
[PHA97] Phadke, M.S., Planning Efficient Software Tests, Crosstalk, vol. 10, no. 10, October
1997, pp. 11-15.

124