30 Days of Testability - Day 1: Define Testability

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

Honestly, Testability is one of those things I should think on more intentionally than I do.

But having read a few of the excellent responses here, I tend to think of Testability as a dial.

There’s one end of the spectrum where you basically can’t test something well at all (there’s always some way to test a part of an application…or else it really doesn’t matter, because it can’t be observed, right?)

At the other end, there’s an obvious, clear way to test something, and it works well with your toolset.

I find that adding in testability to a program (often times making sure there are hooks to the objects for something like Selenium to grab onto easily) is a trade off for the development team as a whole.

You can also run into issues where a feature is broken down in such a way that individual chunks aren’t very testable (or at least, aren’t worth the effort to test individually), but that it keeps the whole development process moving.


Hello @tybar!

I think you make a great point around adding testability. I think testers should actively advocate for testability improvements. Advocate for testability improvements during project planning, product design, and product code reviews.

I’m enjoying the 30 Days of Testability topics and responses; advocating for testability might be an interesting topic on its own.



I’ve never been one to use “fancy” terminology when I explain things, so please bear with me. :blush:

I believe testability is what we, as testers, hope that our projects (applications, websites, etc.) will have - otherwise, how would we do our jobs? For a project to have testability, I believe there should be:

  1. Clearly defined expectations of how it must behave, or must not behave
  2. Established variables that would allow us to test against the defined expectations
  3. Access to the appropriate testing platform(s), and any related back-end resources (or at least access to people with access)
  4. A developed (or at least semi-developed) project! (Otherwise, why would we test it?)
1 Like

Testability is defined as the degree of complexity for testing software. It can be measured by the amount one knows about the system, documentation of the system, the structure of the code, the environment and the amount of code isolation. If testability is high then it should be easier to find bugs by testing easier. A high level of complexity in code or the inability to effectively isolate component testing would then mean that testability is low and it will be harder to test the product.

Sources: https://en.wikipedia.org/wiki/Software_testability and https://www.360logica.com/blog/testability-role-software-testing/

1 Like