Tuesday, October 30, 2012

Testing Testability


Testability, a property applying to an empirical hypothesis, involves two components:
(1) the logical property that is variously described as contingency, defeasibility, or falsifiability, which means that counterexamples to the hypothesis are logically possible, and
(2) the practical feasibility of observing a reproducible series of such counterexamples if they do exist (Wikipedia).

In plain words an item is testable if we can prove its results to be true or false.

Design for Test: 
Test-driven development (TDD) writes tests before implementing any other code. Emphasis is on Unit Testing. What do testers need from a design? Performance test engineers need the ability to predictably set up, control, and measure software execution. Sometimes this requires designing extra hooks that let them precisely configure and control characteristics affecting software performance. And sometimes these extensions work their way into products, because sophisticated customers also find performance-tuning capabilities useful.

Design for Testability: 
There are many reasons why object-oriented (OO) design and development has become the norm for software creation. Inheritance and abstraction have to be very positive tools in software design

Software Testability:
The degree to which a software artefact can be tested/the ease of performing testing Factors determining software testability:

  • Controllability - The degree to which it is possible to control the state of the component under test (CUT) as required for testing, also to control the input which is vital to testing. 
  • Observability - The degree to which it is possible to observe test results.
  • Availability - The degree to which the component under test (CUT) is available at all time. 
  • Understandability - The degree to which the component is documented to simplify and understand.
  • Automatability - The degree to which it is possible to automate testing of the component under test. 
Being able to test software, a piece of code or functionality, depends on what the user can see and control, known as observability and controllability.
Observability enables a tester to see the external and internal of the software. When a user receives the correct expected output, but the internal or the background processes are not quite what was specified in the requirements, defects are often found elsewhere. This is more important in the case of unit and integration testing rather than a simple black box testing.
Controllability is a measure of how easily a tester or a user can create difficult scenarios to test the software under extreme circumstances. For example, behavior of an application cannot be tested very easily when the hard disk is full or table overflow conditions exist.

 Requirement Testability Testability is (1) the degree that characteristics that provide for testing exist, and (2) the degree to which economically feasible tests can be devised for determining whether the developed software will satisfy the requirements. (IEEE Std 610.12). Or in Simple words verifying if a set of requirement is testable Why Requirements Testability is important 40-50% of defects typically traced back to requirements problems Requirements not analyzed sufficiently early in the development Factors determining Requirement Testability Consistent Complete Unambiguous Quantitative

No comments: