Talk:Software testability

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.

Systems

	Systems science portal This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.SystemsWikipedia:WikiProject SystemsTemplate:WikiProject SystemsSystems articles
???	This article has not yet received a rating on the project's importance scale.
	This article is within the field of Software engineering.

What are the typical ways in which software testability can be measured ?

ISO 25010

Latest comment: 7 years ago1 comment1 person in discussion

ISO 25010 (2011-03-01), chapter 4.2.7.5 testability:

"degree of effectiveness and efficiency with which test criteria can be established for a system"

I miss a reference to that --80.146.228.75 (talk) 14:22, 30 October 2017 (UTC)Reply

Section on testability hierarchy recently removed: a volunteer to review its suitability?

Latest comment: 9 months ago2 comments1 person in discussion

User MrOllie has recently removed my contributions about the testability hierarchy arguing citation spam. I would like to ask a volunteer to review the relevance to this article of that testability hierarchy section existing before it was reverted by MrOllie at 22:27, 20 February 2024(UTC). EXPTIME-complete (talk) 00:49, 21 February 2024 (UTC)Reply

In particular, this is the text of the section I would like to introduce again:

Testability hierarchy

Based on the number 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:^[1]^[2]

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.

EXPTIME-complete (talk) 09:04, 21 February 2024 (UTC)Reply

References

^ Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo (2014). "A General Testability Theory: Classes, properties, complexity, and testing reductions". IEEE Transactions on Software Engineering. 40 (9): 862–894. doi:10.1109/TSE.2014.2331690. ISSN 0098-5589.
^ Rodríguez, Ismael (2009). "A General Testability Theory". CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1–4, 2009. Proceedings. pp. 572–586. doi:10.1007/978-3-642-04081-8_38. ISBN 978-3-642-04080-1.

Add topic

[RodriguezLlanaRabanal-1] Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo (2014). "A General Testability Theory: Classes, properties, complexity, and testing reductions". IEEE Transactions on Software Engineering. 40 (9): 862–894. doi:10.1109/TSE.2014.2331690. ISSN 0098-5589.

[Rodriguez-2] Rodríguez, Ismael (2009). "A General Testability Theory". CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1–4, 2009. Proceedings. pp. 572–586. doi:10.1007/978-3-642-04081-8_38. ISBN 978-3-642-04080-1.

[1]

[2]