Category: Working Software

The testers get behind at the end

It’s a very common complaint, such as this one left on the Scrumdevelopment yahoogroup:

Usually in different phases, workload for tester and dev is different. E.g. when a project is coming to the end, most of the tasks will be test.

There are a couple of big red flags waving at me in those two sentences.  One is “different phases.” Why should a software development project, especially one only a couple weeks to a couple months long, have phases?  The other is, at “the end, most of the tasks will be test.” Postponing testing to a phase at the end has never worked very well.  It always results in the testers being behind at the end.

Does this situation sound somewhat familiar to you?  If so, what can we do about it?

Read More

7 Comments

Categories: Working Software

Tags:

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. Read More

5 Comments

Categories: Responding to Change Tools and Techniques Working Software

Tags: , ,

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. Read More

4 Comments

Categories: Working Software

Tags:

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. Read More

No Comments

Categories: Customer Collaboration Working Software

Tags: , ,

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.

1 Comment

Categories: Working Software

Tags:

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. Read More

12 Comments

Categories: Tools and Techniques Working Software

Tags: ,

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. Read More

1 Comment

Categories: Customer Collaboration Tools and Techniques Working Software

Tags:

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.

No Comments

Categories: Responding to Change Tools and Techniques Working Software

Tags: ,

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. Read More

5 Comments

Categories: Responding to Change Tools and Techniques Working Software

Tags: ,