Information Technology Reference
In-Depth Information
they are not, they may disturb the larger system in unexpected
ways. If one is writing the specifications, begin with a clear
statement identifying the focus areas and state where side effects
might emerge. For example, adding more validation on the screen
may slow down response time. One should not assume that the
user understands this “side effect.”
Specifications may ignore the fact that what is being delivered is
part of a larger system. How the product fits into the larger system
is as important as its internal characteristics. This larger system
includes aspects beyond
functionality and features of the
delivered product. It covers all aspects of the product — its ease
of use, security, safety, maintenance, integration, training, auxiliary
systems and processes, and upgrades. Without such coverage,
products that “pass” QA might fail in other ways.
mere
Good designers, when faced with multiple decomposition or design
choices, take the cost of testing or verification as criteria for selecting the
better design. This is common practice in manufacturing industries.
Test Plans and Cases
A test plan describes the scope, approach, and objectives of a software
testing effort. It should be created carefully. A test plan not only helps
the test team to think from requirements to final customer acceptance,
but also helps non-QA groups understand the parameters that will outline
the acceptance criteria of the product. A test plan consists of test cases.
Each test case describes an input or event and the response expected
based on the application working “correctly.” It can help find problems
in the requirements or design of an application because it requires thinking
through the usage of the application.
Extreme Programming (XP) is a software development practice for
projects based on the theory that developing test cases is useful for the
entire software life cycle and not just the testing requirements that might
change frequently, or are collectively indefinable at the start of the project.
The approach is different, with test cases driving general development.
Developers write unit and functional test cases before writing the actual
application code. Customers help develop scenarios for acceptance testing
while the source code is being written. Acceptance tests are continuously
updated and run while development iterations are going on.
