Comments on: Testability

By: Anonymous

Anonymous — Mon, 09 Nov 2009 06:51:52 +0000

I am not sure as to wether I can accept your definition of testability. "Tesability" to me is the feasibilty of proving the validity (or otherwise) of something. Did you know that "to prove", in the original sense of the word, meant exactly the same thing as "to test"? According to Oxford, prove comes from "Old French prover, from Latin probare ‘test, approve, demonstrate’." So, in the sense that you mean "testability is the feasibility of testing the validity (or otherwise) of something", I agree with you. This means lack of ambiguity is a requirement for testability, as is some way of measuring or quantifying a result. For example, requirements should be Specific, Measurable,Attainable, Realistic and Timely in which case they are testable. Being easy to test does not come into it. Anonymous (too shy to sign) I agree that specificity (or, if you like a lack of ambiguity) might be helpful for some aspects of testing. But there are two problems I see here that make this less than universally desirable. The first problem is that you seem to believe that ambiguity (or its absence) is an attribute of a product or document or artifact or conversation. It isn't. Ambiguity is a relationship. There is no absolute evaluation for (un)ambiguity outside the context of a particular person and a particular object of analysis. Something that is ambiguous to me might be entirely clear to you; something that is specific in your view might be hopelessly vague in mine. I'll demonstrate that right here: I'm not sure what you mean by "ambiguity". The second problem, for me, is that you seem to presume that testing is a process of validating or confirming something. I disagree with that. Testing, to me, is a process of exploration, discovery, investigation, and learning. Excellent testing has no problem with ambiguity, especially in early stages of a product. Indeed, one of the ways in which testing can be most helpful is in identifying ambiguity where it may exist for some people (and not for others). Another way in which testing can be helpful is in dispelling ambiguity, by helping to provide information that allows people to understand the product less ambiguously (for them). So I disagree that a lack of ambiguity is a requirement for testability. I further contend that if you need an unambiguous description of what the product can or should do before you can start testing, you're more likely to be focused on checking—confirming information rather than discovering or revealing it. That might be important, but it's not what testing is all about, to me. One more thing: the comments section of my blog is a conversation among people that I consider to be peers. There's no need to be embarrassed about who you are. ---Michael B. (brave enough to sign)

By: Michael

Michael — Thu, 10 Sep 2009 13:31:29 +0000

@offshore...

You're welcome, but I don't see Markus' question. I'd be happy to answer it.

If you're referring to Joseph Ours' question ("Why is it Automation Vendors dismal duty to achieve widespread disruption of sentient testing?"), my answer is that it's not intentional; they know not what they do. Specifically, they're confusing testing and checking.

---Michael B.

By: offshore software testing

offshore software testing — Thu, 10 Sep 2009 12:02:50 +0000

thanx for telling everything in detail. but my question is the same as Markus Gärtner.

By: Markus Gärtner

Markus Gärtner — Fri, 10 Jul 2009 19:55:25 +0000

In the third point of Product Elements there is debugging mentioned:
- Real-time monitoring of the internals of the application via another window, a debug port, or output over the network—anything like that. Printers used to provide "real-time" updates.

This point basically reminded myself on my reply to Brian Marick's "An Alternative To Business Facing TDD" last year:
http://www.exampler.com/blog/2008/03/23/an-alternative-to-business-facing-tdd/

By: Joseph Ours

Joseph Ours — Tue, 07 Jul 2009 02:38:38 +0000

"Is there an example of testability that doesn't involve improving ability to automate?"

I think your response is dead on.

For fun, I did some research on McLuhan where his illustration of marketing is appropriate to test automation.

A nose for news and a stomach for whiskey: McLuhan analyzes an ad for Time Magazine in which he likens a reporter depicted as a romantic character from a Hemingway novel and asks "Why is it [his] plangent duty to achieve cirrhosis of the liver?"

Just as satirically, in the testing sense, why is it Automation Vendors dismal duty to achieve widespread disruption of sentient testing?

By: Drew

Drew — Tue, 07 Jul 2009 01:39:34 +0000

I agree with everything you've posted, but I'd like to make up a word and add it to the list: debugability. Not just monitoring over a debug port, but things to help interactively debug running code. Some of these things apply to compiled binaries much more than scripts or web interfaces.
– non-obfuscated code to test
– non-optimized, debug binaries instead of release ones (where applicable)
– whatever needed debug symbols (if any) are readily available
– debugging tools to help diagnose typical problems – I mean actually within a debugger when available
– etc.