The Reality of Automated Acceptance Testing

Recently, Jim Shore wrote about The Problems With Acceptance Testing.  I like Jim, and respect him a lot.  Because of my respect for his opinions, I found it quite discouraging that he said, “I no longer use [automated acceptance testing] or recommend it.”  Gojko Adzic has posted his response to Jim.  This is mine.

Certainly when something’s not giving you the results you want, it’s time to make a change.  That change can be to drop the practice that’s not working for you.  It can also be changing the way you go about the practice, or changing what you want to accomplish.  Or, instead of changing, maybe the word “refining” is a better fit. Read More

A Lingua Franca between the Three (or more) Amigos

There were a couple dozen people who showed up at the Fool, last night, for my presentation on A ”Lingua Franca” to Ensure You Get the Right System.  I’d like to thank them all for coming and for such lively participation.

These are exciting times.  The tools of acceptance testing and behavior-driven development are progressing beyond the domain of the techies.  They are entering the realm where they can help the Whole Team. Read More

3 Legs to Standing Up an Agile Project

Maybe you’re starting your first Agile project.  You’ve read books and blogs.  You’ve had training.  You think you’re ready, but it’s still a daunting prospect.  There’s just so much to remember—so many details.

Here’s a little cheat sheet.  Forget all the details and the various ways you can implement Agile for the moment.  Let’s simplify the picture.  There are just three essential legs that your Agile project needs to stand.  Get those in place, and you’ll do OK.  Keep improving all three, and you’ll do fantastically! Read More

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

Agile Retroflection of the Day

Yves Hanoulle asks, “If you could change 1 thing today what would it be?” as the first question in his Agile Retroflection of the Day project. Today being the first of the year, it’s natural that I look back over the past year as I consider this question.  And so I answer,

That people could ask for, and could accept, the help they need and want. Read More

Tracking your investments

The world is slowly recovering from a major financial meltdown.  People blame the collapse on a number of different things: a bubble of inflated housing prices, relaxed requirements for qualifying for a mortgage, predatory lending practices, greed on the part of mortgage companies and investment banks”¦.  There are certainly many places to point fingers.  Each of these places, however, was doing what seemed logical when looking at a small piece of the puzzle.

As is often the case, we must back up and take a larger systemic view to see further.  Once upon a time, people borrowed money to buy a house, paid it back over time, and ultimately the bank was able to lend that money to someone else.  With the creation of the FNMA (Fannie Mae) in 1938, the income streams of those mortgages being repaid were converted to bonds, so that they could be sold to other investors and the banks to re-lend their money more frequently.  This allowed many more people to afford houses.  In the 1970s, private banks got into the business of creating their own bonds based on debt repayment streams.

Nothing ever stands still, of course.  People continued to look for new wrinkles on these themes to allow them to expand the business, or to increase the profit on the business they had.  Some of these investment vehicles got very complicated, intended only for professional bankers who could understand and evaluate them where the mass public could not.  Or, so went the pitch at the time. Read More

I do not endorse PMAC Certification

It has come to my attention that the PMAC (Project Management Association of Canada / Association de Management de Projet du Canada) claims that I support their certification program.  This is a lie.  I do not support their certification program.

Their claim seems to based on a mailing list posting in which I said,

I applaud your efforts to educate the “traditional project manager” in Agile techniques.  I hope that you are very effective in doing so.

  • I did not say anything about their certification program.
  • They did not ask me if they could use my words on their web site.
  • They have fraudulently quoted me as if I have endorsed their certification.

I am all for education. I am suspicious of certifications. I am angry that I have been so misrepresented.

I consider this misrepresentation to be a sleazy trick. It give me the impression that PMAC is not to be trusted. I suggest that you be wary of them.

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: