TL;DR
In the previous post, I explained that the nontestable program is a program with no oracles, or there is a theoretical oracle that is not possible to use in practice. Yesterday I read a great blog by Ash Winter, Testability Power Hour. I realized that testers too often put a focus on the program project aspects of testability, but they often forgot about other aspects, for example, the oracle problem.
The Problem
Testability is a metric about how hard it is to test the program. In Ash blog, only one question touched oracle problem:
Whom should we ask for testability?
Ash pointed, among others, to Business(Data) Analysts because they can provide more insights into the product. It is essential to state that testability is not only driven by technical aspects of the program under test.
The Solution
I Asked Michael Bolton following question via Twitter (please, do not mind my spelling errors):
1) The availability of oracles is only one factor in testability. Current popular lore focuses on visibility (logging) and controllability (APIs); those are important, too. To me, though, the big deal is that testability is a set of relationships.
— Michael Bolton (@michaelbolton) July 13, 2019
2) Testability is marked by the gap between what we know and what we need to know about a product ("epistemic testability"); by our shared understanding of value and what might threaten it (“value-related testability"); by factors in the product itself ("intrinsic testability”);
— Michael Bolton (@michaelbolton) July 13, 2019
3) by factors in the development project that make testing easier or harder ("project-related testability"); and by the tester’s own knowledge, skills, experience, mindset, relationship to all the other stuff, etc. ("subjective testability").
— Michael Bolton (@michaelbolton) July 13, 2019
You’re welcome. More: https://t.co/7mj4ZXaNFY
— Michael Bolton (@michaelbolton) July 14, 2019
Conclusion
It seems that testers think that the most important testability issue is to have an API, so they can exercises it in automation scripts. Because automation is cool and it will get them a better job. This is wrong, because finding the right application oracles belongs to software testing basic skills, and if you are a software tester, oracles are more important artifacts than automation scripts.
