30 Days of Testability - Day 1: Define Testability

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

Testability is an interactive process: how the product is written and presented; what the valuable parts to both the user and the people that are asking for it (which may be different things!); the ability to access states and settings; the timing of when the tests are being done (test early, test often); the correctness of code and documentation; and the most important thing - communication of current and potential risks: this includes feedback to make sure that neither the product nor the test get off-track.


For me, testability level depends on how much effort you need to make for testing. It is about getting knowledge, writing mocks and so on

1 Like

Timing!! That’s an aspect that’s so crucial about testability but that I constantly see product managers, devs, and even testers (myself included) ignore. In my experience, if you don’t build an application or feature to be testable as early as possible then adding thorough documentation, logs, monitoring, etc won’t help much after the damage has been done.

I believe Testability is a property of a system and its components that determines how its

  • Data
  • States
  • Variables
  • Methods
  • Interfaces

can be:

  • Monitored
  • Manipulated
  • Analyzed
  • Recorded
  • Reset/Restored

in order to provide insight and tools that facilitate testing that system with the goal of preventing failure in real-life scenarios and ensuring it meets both user and business requirements.

After reading the posts in this thread, I would also include within this definition items outside of the system itself like documentation, feature specifications, and historical customer-reported issues.

In a nutshell, testability is how well (and how early) your system can respond to What, Where, Why, and How questions you throw at it.


Hi Philipp,
totally agree to point 2. and 3.

Point 1. to me seems to mean:
If we do not know for sure, what the expected behaviour of the SUT shall be, e. g. because it’s an old legal system and there is no documentation available, we cannot test it? Is it that, what you want to say?


wow, a huge amount of good ideas!

Testability to me means the following, too:
That SUT is available on time in a usable quality. If there would be to many bugs in it or if it does not fullfill test entry criteria I would not accept it for testing.

To me testability is the measure of being able to run through a system or program.

This is weather it is walking through the requirements to see how it will work or with the system/software up and running so it see how it is working.

Define what you believe testability is. Share your definitions on The Club.

ISTQB defines Testability as “The capability of the software product to enable modified software to be tested.”
According to ISO 9126, testability is defined as: Testability: The capability of the software product to enable modified software to be validated. NOTE - Values of this sub-characteristic may be altered by the modifications under consideration.

Testability touches upon two areas of concern:

  • How easy is it to test the implementation?
  • How test-friendly is the requirement?

These two concerns are not independent and should be considered together.

In order to be testable, a requirement needs to be stated in a precise way. In other cases we need to change a requirement to get a testable version.

" Testability is the level of support given to allow a software tester to control and observe a software application, and (if required) enable the tester to develop automated tests that can control and observe the software application."

I’ve written up how and why I decided on this definition for testability in my blog: https://louisegibbstest.wordpress.com/1-define-what-you-believe-testability-is/

1 Like

To me, Testability is how easy it is to test something.

Hi guys!
For me Testability the degree to which any any software can be tested. If there’s enough information as to verify what it should do and how it should do it.

I started my 30 days of testability challenge a bit late but here I go!



Application testability helps testers easily identify which areas of the site could be affected by regressions, makes it easy to troubleshoot both internally and externally, and ensures the site flows logically and can easily predict users paths.

Before reading any of yours, here is what I came up with:

Testability is the practical ability to observe reproducible responses to logic/inputs for a procedure or hypothesis.

I really love these answers!

One of the things that I love about testability is the challenge of building a personal paradigm of what it means and its impact on testing for many different roles and disciplines. It’s a wide subject, as evidenced by the 10 P’s of testability by Rob Meaney.

Seeing a diverse set of definitions makes me very happy. :slight_smile:


I’m late to the game but about to catch up!

I understand testability as:

  • clarity as to what the goal of the tested piece is
  • at least some information about realistic usage scenarios
  • clarity as to what sort of oracles the tester is expected to use, if any (not that these would be the only ones but if you want to investigate an aspect specifically or evaluate against specific criteria, do tell)
  • the tester being able to isolate the behaviors to be tested (ideally, the components as well but it’s rarely that clean in projects) for feeding them inputs and in order to limit dependencies on external systems which may or may not be available
  • the tester being able to observe and access the results of their actions in a clear manner, traceable against inputs/actions and across media (e.g. database entries, logs, API/GUI)
  • the tester having not just the technical means but also the freedom to do the above (this is more a process thing, like roles, access rights, access to other stakeholders for questions/support)

Catching up with the Tweets on this:

1 Like