Testability & Good Design

Much of the time, the test-driven development yahoogroup is pretty quiet, but it has recently awakened from winter hibernation.  The question “Is it OK to add code to a class only to improve its testability?” stirred up a wide-ranging discussion that brought in the topic of what constitutes good design.  “Uncle Bob” Martin drew a bold line in the sand with his comment,

One reasonable definition of good design is testability.  It is hard to imagine a software system that is both testable and poorly designed.  It is also hard to imagine a software system that is well designed but also untestable.

I greatly sympathize with this statement, though I wouldn’t go quite that far.  I don’t think it is so hard to imagine code that is testable, but poorly designed.  For a trivial counter-case, there could be rampant duplication of testable code.  I would call that poorly designed, but it doesn’t affect it’s testability.  Therefore I would soften Uncle Bob’s definition to “One reasonable component of the definition of good design is testability.”

To me, the notion of “testable code” is the same thing that “testable circuit” was back when I worked on a custom integrated circuit.  Mostly, that depends on the ability to put the circuit or code into a known state, exercise it, and see the interactions with its collaborators and its resulting state. (Continued)

It’s not the script, it’s how you do it.

I’ve had numerous discussions with Michael Bolton where he makes the claim that scripted testing (whether via automation or a person following written directions) is not testing but checking.  He quotes Cem Kaner‘s definition of testing: “testing is an empirical, technical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek.”  Running a script that validates certain desired behavior certainly fits this definition. (Continued)

Long term focus

My good friend, Steven M Smith, tweeted

AGILE methods emphasize realizing short-term OBJECTIVES rather than creating long-term objectives and trying to satisfy them.

I completely disagree with this statement.  I don’t agree that short terms objectives are the emphasis in Agile methods and I don’t agree that short term objectives are preferred over long-term objectives.  I think that Steve’s misunderstanding is rooted in the fact that he has only read about Agile methods, and not practiced them.  I think that it is impossible to get a deep understanding of Agile methods by reading without experiencing.  Therefore, I’d like to encourage Steve and others talking about Agile methods to try to get some experience before making such statements.  I’d also like to offer an explanation that attempts to clear up this particular misunderstanding. (Continued)

Questionable security

Adding security questions to back up password-protected web sites has become all the rage. I’ve had to deal with this on many web sites I use, and have encountered it on the back end helping teams implement sites. I’ve known security departments of financial organizations that say these are required by industry rules and not to have them would be a breach of responsibility.

The fact is, having “security questions” weakens security rather than strengthens it.  Recent news of the infiltration of Twitter’s proprietary documents is a good case in point.  The New York Times reports

Instead of circumventing security measures, it appears that the Twitter hacker managed to correctly answer the personal questions that Gmail asks of users to reset the password.

If you don’t believe me that security questions weaken security, just ask Bruce Schneier.

If you don’t automate acceptance tests?

Amr Elssamadisy reports on InfoQ that automated acceptance tests are “only used by a small minority of the community.”  Is this true?  If you and your team don’t use automated acceptance tests, please let me know how you handle regression tests as the application grows larger.  You can leave a comment here or, if you’d rather not say it in public, email me directly. (Continued)

Agility and Predictability

I was reading the latest post on Johanna Rothman’s Managing Product Development blog.  In it she says,

Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction that’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by”“the first possible, optimistic date.

I like that characterization of the predicted date.  Another characterization, usually true of serial lifeycles, is that the predicted delivery date is the first day of schedule slip.  I’ve seen many serial projects get almost to that date before they first admit that they’re in trouble. (Continued)

More on Agile Usability

I recently wrote about Agile Usability.  Now I find an article on StickyMinds, “Getting Agile With User-Centered Design,” by Jon Dickinson and Darius Kumana.  They talk about a number of issues that can come up.  My favorite bit is this:

We must actively challenge the mindset of divided responsibility–” You spec and design it; we’ll build what you spec.” Everyone should work toward the shared vision of a successful experience.

That says so elegantly what I tried to say in my article.

Agile Usability

If I had time, I would re-read Tom DeMarco’s book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, because I have precious little slack in my own life, these days.  So it is that I just now got around to reading Jakob Nielsen’s article, Agile Development Projects and Usability, which William Pietri noted on the Agile Usability list on November 17.

The statement

“For a project to take interaction design and usability seriously, it must assign them ‘story points’ (i.e., resources) on an equal footing with the coding”

jumped out at me.  Alistair Cockburn wrote a thoughtful reply where he noted the same statement.  I agree with Alistair’s comments, but I’d like to comment on this statement from a slightly different perspective. (Continued)

Test-driving those “non-functional” stories

The term “non-functional requirements” has always bothered me. “Do you mean the software isn’t supposed to work?” ;-)

This post is about how I approach test-driving the solution to non-functional requirements such as performance, and how it differs from test-driving a functional user story requirement. (Continued)

Refactoring a House

Some of you may remember that I started a house construction project. Things are moving very fast, now, and the actual construction may take less time than it took to get all the necessary permits. So far, the project’s about 100% over the time budget. And people say that software development should be more like the construction industry!

But the fact that the construction has run slower than expected is not the reason for this post. Neither is the fact that this project has been consuming a large portion of my attention, and hindering posts on this blog.

This post is about an example of refactoring found in the house construction domain. (Continued)