Software testability: Difference between revisions

Revision as of 06:37, 26 February 2014

Latest revision as of 21:23, 4 December 2024

(42 intermediate revisions by 25 users not shown)

Line 1:

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

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

{{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 an artifact is high, then finding faults in the system (if 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 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).

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.

Therefore, 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 book | 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 | isbn=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>.

Line 8 ⟶ 16:

Testability, a property applying to empirical hypothesis, involves two components.

The effort and effectiveness of software tests depends on numerous factors including:

* propertiesProperties of the software requirements

* propertiesProperties of the software itself (such as size, complexity and '''testability''')

* propertiesProperties of the test methods used

* propertiesProperties of the development- and testing processes

* qualificationQualification and motivation of the persons involved in the test process

== Testability of Softwaresoftware Componentscomponents ==

The testability of software components (modules, classes) is determined by factors such as:

* '''controllability'''Controllability: The degree to which it is possible to control the state of the component under test (CUT) as required for testing.

* '''observability'''Observability: The degree to which it is possible to observe (intermediate and final) test results.

* '''isolateability'''Isolateability: The degree to which the component under test (CUT) can be tested in isolation.

* '''[[separationSeparation of concerns]]''': The degree to which the component under test has a single, well defined responsibility.

* '''understandability'''Understandability: The degree to which the component under test is documented or self-explaining.

* '''automatability'''Automatability: The degree to which it is possible to automate testing of the component under test.

* '''heterogeneity'''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[[Design for testing|Design for testability]] (similar to [[design for test]] in the hardware ___domain)

== Testability of Requirementsrequirements ==

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 and Validation (software)|Verificationverification/verified]])

* '''[[Verification and Validation (software)|Verificationverification/verifiable]] in practice''' (a test is feasible not only in theory but also in practice with limited resources)

Treating the requirement as axioms, testability can be treated via asserting existence of a function <math> F_S</math> (software)

such that input <math> I_k </math> generates output <math> O_k </math>, therefore <math> F_S : I \to O </math>. Therefore, the ideal software generates the tuple <math>(I_k,O_k)</math> which is the input-output set <math>\Sigma</math>,

Therefore, the ideal software generates the tuple <math> (I_k,O_k) </math> which is the input-output set <math> \Sigma </math>,

standing for specification.

Now, take a test input <math> I_t </math>, which generates the output <math>O_t</math>, that is the test tuple <math>\tau = (I_t,O_t) </math>. Now, the question is whether or not <math> \tau \in \Sigma </math> or <math> \tau \not \in \Sigma </math>. If it is in the set, the test tuple <math> \tau </math> passes, else the system fails the test input. Therefore, it is of imperative importance to figure out : can we or can we not create a function that effectively translates into the notion of the set [[indicator function]] for the specification set <math> \Sigma </math>.

Now, take a test input <math> I_t </math>, which generates the output <math> I_t </math>, that is the test tuple

<math> \tau = (I_t,O_t) </math>. Now, the question is whether or not <math> \tau \in \Sigma </math> or <math> \tau \not \in \Sigma </math>. If it is in the set, the test tuple <math> \tau </math> passes, else the system fails the test input.

Therefore, it is of imperative importance to figure out : can we or can we not create a function that effectively translates into the notion of the set [[Indicator function]] for the specification set <math> \Sigma </math>.

By the notion, <math> 1_{\Sigma} </math> is the testability function for the specification <math> \Sigma </math>.

The existence should not merely be asserted, should be proven rigorously. Therefore, obviously without algebraic consistency, no such function can be found, and therefore, the specification cease to be termed as testable.

Therefore, obviously without algebraic consistency, no such function can be found, and therefore, the specification cease to be termed as testable.

== See also ==

{{Portal|Software Testing}}

* [[testabilityTestability]]

== References ==

{{Reflist}}

* Robert V. Binder: Testing Object-Oriented Systems: Models, Patterns, and Tools, {{ISBN |0-201-80938-9}}

* Stefan Jungmayr: [https://web.archive.org/web/20071009021801/http://www.dissertation.de/index.php3?active_document=/FDP/sj929%2FFDP%2Fsj929.pdf Improving testability of object-oriented systems], {{ISBN |3-89825-781-9}}

* Wanderlei Souza: [http://patternsgrace-wg.fuka.info.waseda.accenter.jp/SPAQUwp-content/proceedings2009uploads/32012/06/GRACE-TR-P22009-AbstractTestabilityPatterns07.pdf Abstract Testability Patterns], ISSN 1884-0760

* Boris Beizer: [httphttps://books.google.co.incom/books?id=Ixf97h356zcC] , Software Testing Techniques

{{Portal|Software Testingquality}}

[[Category:Software testing]]

[[Category:Software quality]]