Showing posts with label Testability. Show all posts
Showing posts with label Testability. Show all posts

Testability

ISTQB Glossary definition 

The capability of the software product to enable modified software to be tested.     [ISO 9126] See also Maintainability.

In simple english,

  it is a measure of how much a software system is suitable for testing.


Field Notes:

  • it is a measure that is mostly on a qualitative scale rather than a quantitative scale. 
  • It is normal for this to be expressed as just as an Yes or No.
  • Sanity test or smoke test is conducted to determine this.
  • Most often this measure is found using a experienced test analyst or test lead to check the system.
  • It is however, advised to have a list of test cases that can be used to determine testability.


Testability review

ISTQB Glossary  definition 
"A detailed check of the test basis to determine whether the test basis is at an adequate quality level to act as an input document for the test process. " [After TMap]

In Simple English,
A review of all documents based on which you are going to test to check if they are good enough to start testing activities.
Field Notes 


  • Another way to say this would be: A review of requirement documents for completeness.
  • Even simpler to understand is the question you ask in a testability review, "Is requirements frozen?"
  • Remember, requirements do not limit to the functional requirements document of the software being build.
  • Requirements include other things like the style guide which defines do's and don't of how a screen can be designed, Performance expectations and internationalization requirement.
  • Broadly you can classify these requirements as below 
    • Stated and documented Functional Requirements
    • Stated and documented non functional requirements
    • stated and documented guidelines, legal limitations, compliance requirements.
    • Un stated yet expected non functional requirements like no spelling errors.
    • Stated and documented special requirements unique to the application being built

For Example:

        Say for example, you are asked to test an application. The first thing you would ask the team is "So, what is this application about?" and they might send you a requirements document. You review it and you find that the requirements document does not define the modes of payment accepted to buy a ticket. in this case the requirement document is not complete. 


Your testability review in this case would resulting in you deciding and declaring that the application is not testable as you do not have a established basis to test for

Not that even if the requirements document is complete and test basis is established it might fail the testability review if you find in the review that it is not approved or frozen yet.