![](bg2.png)
considered for our method, such as the use of IDs
for TCs and UCs. Likewise, Lewis (2000) proposes
a template for TCs that includes conditions,
environment, version and system.
In recent years, a Model-based Testing (TDD)
approach was proposed, which provided for the
automation of the design of black-box tests.
SWEBOK (2004) defines black-box test where test
cases rely solely on the input/output behavior.
Some authors like Pinkster et al. (2006), state
that subsequent improvement in testing quality is
more than likely provided that requirements are
considered as the testing basis; this is known as
requirement-based testing.
Likewise, UML Testing Profile (2005)
introduces the integration of concepts, such as test
control, test group, and TC into the TC concept,
which can be decomposed into several lower-level
test cases and permits the easy reuse of TC
definitions in various hierarchies.
Some benefits of the requirements/test matrix
(Lewis, 2000) include: correlation of tests and
scripts with requirements, facilitation of review
status, and provision of a traceability mechanism
throughout the development cycle that includes test
design and execution.
In contrast to prior initiatives, our method
includes all the aforementioned ideas for the
purpose of obtaining a method that supports
elements comprised in a test strategy.
3 TEST CASE
A TC is a specification -usually formal- of a set of
test inputs, execution conditions and expected
outputs identified for the purpose of assessing the
particular aspects of a testing element (Leffingwell
and Widrig, 2006): (a) TCs reflect traceability with
UCs (functionality), (b) TCs include the
complementary specifications of the requirements,
and (c) TCs provide the system’s design
specifications.
All these elements ensure the compatibility of
test procedures with user/consumer requirements. In
practice, it is assumed that a UC itself is a TC and
that the project team works on the UCs without
planning the TCs in advance. As they test UCs, they
intuitively assume the test data and procedures
without making the need of documentation, which is
rather a mistake, since TCs expand or enhance the
information included in UCs. For instance, for UCs,
the values or conditions of tests are not specified.
TCs are essential for all testing activities
(Leffingwell and Widrig, 2006) due to the
following:
• They constitute the basis for the design and
execution of test procedures.
• Tests’ depth is proportional to the number of
TCs.
• Design and development, as well as required
resources, are governed by the required TCs.
If TCs are incorrect, the system quality will not
be reliable.
The method proposed herein states that testing
procedures are comprised of steps, conditions,
values, and expected/obtained results. Moreover, the
testing procedure may be automated through test
scripts. All the aforementioned concepts allow for
visualizing the test scope: What will be tested?
How, who, when, and what for? Once all TCs are
executed, the results should be fully disclosed for
the purpose of determining whether the acceptance
criteria defined by the user were satisfied upon
system validation.
In the following section you will find more
details of the proposed method.
4 METHOD TO SPECIFY TEST
CASES (MSTC)
The proposed method consists in creating a set of
TCs from a UC, since it is assumed that software
behavior must be tested based on requests or
requirements. Moving from a UC to a corresponding
set of TCs implies a reasonably wide and nontrivial
process. Leffingwell and Widrig (2006) describe
four (4) steps for achieving this process. Such steps
indicate what it is to be done, but they do not
explain in detail how to do it. Certain aspects that
were not expressed in writing were gathered and
proposed through the MSTC, based on bibliographic
review and our experience. Considering those steps
proposed by Leffingwell and Widrig (2006), we
intend to provide a method for specifying a set of
TCs from a UC.
The MSTC contribution consists in the
incorporation of tests’ traceability elements as to
the entire development process and enhancement of
the testing strategy while regulating this process.
The development process is then structured in
phases, activities, roles or individuals involved and
artifacts generated. Likewise, it helps documenting
ideas that were issued prior to tests, and explaining
how TCs were generated. This is useful for verify
ICEIS 2008 - International Conference on Enterprise Information Systems
160