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.
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.
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.
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.
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:
- Clearly defined expectations of how it must behave, or must not behave
- Established variables that would allow us to test against the defined expectations
- Access to the appropriate testing platform(s), and any related back-end resources (or at least access to people with access)
- A developed (or at least semi-developed) project! (Otherwise, why would we test it?)
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.
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
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
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.
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/