Software testability: Difference between revisions

Revision as of 20:01, 10 March 2019

Latest revision as of 21:23, 4 December 2024

(17 intermediate revisions by 14 users not shown)

Line 1:

{{Short description|Extent to which software can be tested}}

{{more footnotes|date=September 2014}}

'''Software testability''' is the degree to which a software artifact (i.e.g. a software system, software module, requirements-requirement, or design document) supports [[Software testing|testing]] in a given test context. If the testability of the softwarean artifact is high, then finding faults in the system (if it has any) by means of testing is easier.

Formally, some systems are testable, and some are not. This classification can be achieved by noticing that, to be testable, for a functionality of the system under test "S", which takes input "I", a computable [[functional predicate]] "V" must exists such that <math>V(S,I)</math> is true when S, given input I, produce a valid output, false otherwise. This function "V" is known as the verification function for the system with input I.

Testability is often thought of as 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). Even though testability can not be measured directly (such as software size) it should be considered an [[intrinsic]] property of a software artifact because it is highly correlated with other key software qualities such as encapsulation, coupling, cohesion, and redundancy.

Many software systems are untestable, or not immediately testable. For example, Google's [[ReCAPTCHA]], without having any metadata about the images is not a testable system. Recaptcha, however, can be immediately tested if for each image shown, there is a tag stored elsewhere. Given this meta information, one can test the system.

The correlation of 'testability' to good design can be observed by seeing that code that has weak cohesion, tight coupling, redundancy and lack of encapsulation is difficult to test<ref name="DesignPatternsExplained2ndEd">{{cite journal | last1=Shalloway | first1=Alan | last2=Trott | first2=Jim | title=Design Patterns Explained, 2nd Ed | page=133 | year=2004 | ISBN=978-0321247148 }}</ref>.

TestabilityTherefore, testability is often thought of as 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). Even though testability can not be measured directly (such as software size) it should be considered an [[intrinsic]] property of a software artifact because it is highly correlated with other key software qualities such as encapsulation, coupling, cohesion, and redundancy.

The correlation of 'testability' to good design can be observed by seeing that code that has weak cohesion, tight coupling, redundancy and lack of encapsulation is difficult to test.<ref name="DesignPatternsExplained2ndEd">{{cite journalbook | last1=Shalloway | first1=Alan | last2=Trott | first2=Jim | title=Design Patterns Explained, 2nd Ed | page=[https://archive.org/details/isbn_9780321247148/page/133 133] | year=2004 | ISBNisbn=978-0321247148 | url-access=registration | url=https://archive.org/details/isbn_9780321247148/page/133 }}</ref>.

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>.

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>.

In order to link the testability with the difficulty to find potential faults in a system (if they exist) by testing it, a relevant measure to assess the testability is how many test cases are needed in each case to form a complete test suite (i.e. a test suite such that, after applying all test cases to the system, collected outputs will let us unambiguously determine whether the system is correct or not according to some specification). If this size is small, then the testability is high. Based on this measure, a [[#Testability hierarchy|testability hierarchy]] has been proposed.<ref name="RodriguezLlanaRabanal">{{cite journal | last1=Rodríguez | first1=Ismael | last2=Llana | first2=Luis | last3=Rabanal | first3=Pablo | title=A General Testability Theory: Classes, properties, complexity, and testing reductions | journal=IEEE Transactions on Software Engineering | volume=40 | issue=9 | pages=862-894 | year=2014 | issn=0098-5589 | doi=10.1109/TSE.2014.2331690}}</ref>

<ref name="Rodriguez">{{cite conference | last=Rodríguez | first=Ismael | title=A General Testability Theory | doi=10.1007/978-3-642-04081-8_38 | year=2009 | booktitle=CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1-4, 2009. Proceedings | pages=572-586 | ISBN=978-3-642-04080-1}}</ref>

== Background ==

Line 34 ⟶ 36:

* [[Test-driven development]]

* [[Design for testing|Design for testability]] (similar to [[design for test]] in the hardware ___domain)

== Testability hierarchy ==

Based on the amount of test cases required to construct a complete test suite in each context (i.e. a test suite such that, if it is applied to the implementation under test, then we collect enough information to precisely determine whether the system is correct or incorrect according to some specification), a testability hierarchy with the following testability classes has been proposed:<ref name="RodriguezLlanaRabanal"/>

<ref name="Rodriguez"/>

* Class I: there exists a finite complete test suite.

* Class II: any partial distinguishing rate (i.e. any incomplete capability to distinguish correct systems from incorrect systems) can be reached with a finite test suite.

* Class III: there exists a countable complete test suite.

* Class IV: there exists a complete test suite.

* Class V: all cases.

It has been proved that each class is strictly included into the next. For instance, testing when we assume that the behavior of the implementation under test can be denoted by a deterministic [[finite-state machine]] for some known finite sets of inputs and outputs and with some known number of states belongs to Class I (and all subsequent classes). However, if the number of states is not known, then it only belongs to all classes from Class II on. If the implementation under test must be a deterministic finite-state machine failing the specification for a single trace (and its continuations), and its number of states is unknown, then it only belongs to classes from Class III on. Testing temporal machines where transitions are triggered if inputs are produced within some real-bounded interval only belongs to classes from Class IV on, whereas testing many non-deterministic systems only belongs to Class V (but not all, and some even belong to Class I). The inclusion into Class I does not require the simplicity of the assumed computation model, as some testing cases involving implementations written in any programming language, and testing implementations defined as machines depending on continuous magnitudes, have been proved to be in Class I. Other elaborated cases, such as the testing framework by [[Matthew Hennessy]] under must semantics, and temporal machines with rational timeouts, belong to Class II.

== Testability of requirements ==

Line 66 ⟶ 56:

== See also ==

{{Portal|Software Testing}}

* [[Testability]]

Line 75 ⟶ 65:

* Wanderlei Souza: [http://grace-center.jp/wp-content/uploads/2012/06/GRACE-TR-2009-07.pdf Abstract Testability Patterns], ISSN 1884-0760

* Boris Beizer: [https://books.google.com/books?id=Ixf97h356zcC], Software Testing Techniques

{{Portal|Software Testingquality}}

[[Category:Software testing]]

[[Category:Software quality]]