Content deleted Content added
←Replaced content with 'hubgkybvjhfvgcvfhfvhngcfvnhcn hchngcdhfdcxhfvxcdhfhn' |
m Reverted edits by 220.227.158.108 to last revision by 69.106.253.194 (HG) |
||
Line 1:
'''Software testability''' is the degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context.
Testability is not an [[intrinsic]] property of a software artifact and can not be measured directly (such as software size). Instead testability is an [[extrinsic]] property which results from interdependency of the software to be tested and the test goals, test methods used, and test resources (i.e., the test context).
A lower degree of testability results in increased [[test effort]]. In extreme cases a lack of testability may hinder testing parts of the software or [[software requirements]] <u>at all</u>.
== Background ==
The effort and effectiveness of software tests depends on numerous factors including:
* properties of the software requirements
* properties of the software itself (such as size, complexity and '''testability''')
* properties of the test methods used
* properties of the development- and testing processes
* qualification and motivation of the persons involved in the test process
== Testability of Software Components ==
The testability of software components (modules, classes) is determined by factors such as:
* '''controllability''': The degree to which it is possible to control the state of the component under test (CUT) as required for testing.
* '''observability''': The degree to which it is possible to observe (intermediate and final) test results.
* '''isolateability''': The degree to which the component under test (CUT) can be tested in isolation.
* '''[[separation of concerns]]''': The degree to which the component under test has a single, well defined responsibility.
* '''understandability''': The degree to which the component under test is documented or self-explaining.
* '''automatability''': The degree to which it is possible to automate testing of the component under test.
* '''heterogeneity''': The degree to which the use of diverse technologies requires to use diverse test methods and tools in parallel.
The testability of software components can be improved by:
* [[Test-driven development]]
* design for testability (similar to [[design for test]] in the hardware ___domain)
== Testability of Requirements ==
Requirements need to fulfill the following criteria in order to be testable:
* '''consistent'''
* '''complete'''
* '''unambiguous'''
* '''quantitative''' (a requirement like "fast response time" can not be [[Verification|verified]])
* '''[[Verification|verifiable]] in practice''' (a test is feasible not only in theory but also in practice with limited resources)
== See also ==
* [[testability]]
== References ==
* Robert V. Binder: Testing Object-Oriented Systems: Models, Patterns, and Tools, ISBN 0201809389
* Stefan Jungmayr: [http://www.dissertation.de/index.php3?active_document=/FDP/sj929.pdf Improving testability of object-oriented systems], ISBN 3-89825-781-9
[[Category:Software testing]]
| |||