30 Days of Testability - Day 1: Define Testability

A system/feature is only testable if:

  1. I have enough information about the system/feature to determine which input should yield what output, under which conditions and when
  2. I have the possibility to get/create the needed inputs and set the state of the system to the needed conditions/state
  3. I am able to observe the outputs of the system/feature

Your definition is clear and specific–very nice. I took a broader view, which may be too general, but here goes:

Testability is a description of the availability of an application to various forms of testing. Testability takes into account the target environment of the software, how opaque it is (how much we know about it and whether not only functional but structural testing may be done), and whether the results of such interrogation can translate into quality improvements.


I think about testability like this.

The level of testability of a system/site/application is determined by how easily you can interrogate, view, alter, interact with and understand its state, data needs and outputs, functions, calls, goals and logs and where there are no hidden functions I cannot get to.


Copying from another post I did here on the Club, which was improved by @robertmeaney on Twitter :

Testing: The act of learning about a product through experimentation and exploration.
Testability: The capacity of the product to ease the process of learning, both on the “input” (act on the product) and on the “output” (understanding how to the product responded) - in the context of the environment and testers themselves*.

  • Silly example: If all logs are in Portuguese, the logs only improve testability to Portuguese-speaking people.

Testability is the degree to you can control and observe a system under operation.



My simple answer for this as I understand it is how easy something is to test. To go a bit further with it after the AMA with Ash Winter it’s how explainable a feature is. If we can’t explain it, how can we test it?


Testability is one factor in software quality. If testability get higher, the better the quality of the software.ˇ

Points of testability:

  • Software can be operated properly
  • The scope of the test can be clearly identified
  • Software can be controlled easily, so it can be automated
1 Like
  • Have good documentation and requirement
  • Easy to setup in local environment.
  • Reduce the efforts to perform automated testing.
  • Easily integrated with CI / CD.

all very good definition here, the only thing I can think of hasn’t yet covered:

“the error or error log should be helpful and meaningful, so tester can adjust the approach to explore a successful or failure state with replicable and reliable steps.”


There are a lot of great answers in this thread already. As a gamer I have always thought about testability as the cheat codes for the system under test. I.e. being able to change the state of the system bypassing the normal mechanisms for it.


Testability in my opinion is the level of our ability to test. And our ability to test is raised by the knowledge we have over the product we should test, the possibility to monitor and to understand the input and the output data, our skills on understanding what end-user expect to have/do and our creativity that will help to explore cases and cases.


I’d say it is how easy the system enables testers to test


Testability is the ability to test a feature or system considering the fact that all underlying conditions have been met, different System has different factors or conditions to be met before it’s testable;
Factors here include Resources(Human and Non-human), Environment, Documentations and so on…

Till now I have no practical experience in software testing, but I learn it and that is why I am with MOT. According to literature I read I made own conclusion about Testability. I believe testability is an opportunity to gather information about Software work by using different sources and instruments around the Software, including logs, feedbacks, consoles, code hucks etc.


Testability ->
TestAbility ->
Test - Ability

“The ease to validate a system for its intended purpose”


For me, testability is how easily software can be operated. If a developer has made changes to something, can I see or interact with the changes? If the answer is no, then the software has no testibility.

The extent to which the system behaviour can be inspected in order to validate specified requirements/acceptance criteria.


Leveraging Bach’s and Bolton’s definition of testing, I’d say testability is the degree to which something (a requirement, a manual, code, a piece of hardware, etc) allows a person to learn about itself through knowledge and experimentation (operational and hypothetical). I’m trying to convince myself that testability is an inherent quality of the thing independent of the person doing the testing, but I’m not quite there yet.


Testability to me is how well we understand and how well we can interrogate the functionality and technology that what we’re planning on testing. Also, it’s how easily we can interact with it to cover the scope of testing that we have planned. Our understanding of a feature’s testability will grow as we explore and learn and collaborate although we’ll naturally do our best to enhance testability from as early as possible in the delivery cycle.

For me, there’s some bits in here about access to certain tools. I have the ability to test the product in all relevant environments - I’m not gated away from access to certain features. If I wanted to, I could test any relevant part of the product without assistance from anyone else.

It also means that I have full access and ability to see under the covers of the application. I have access to all relevant logging and alerts for the environment I’m testing in, and I can identify the flow that I’m taking in the application and follow that through all of the relevant logging.

1 Like