Design for Testability

Asked on the Agile-Testing mailing list:

Lesson 136: Testability is often a better investment than automation.

(I’m quoting “Lessons Learned in Software Testing” by Kaner/Bach/Pettichord)

If anyone has practical examples of improving testability, I’d be very interested to understand, and grateful. (Continued)

Time to Shut AOL Down

This is an unusual topic for this blog. And a bold statement: It’s time for AOL to go out of business.

Why? Because they are an irresponsible participant in the internet community. They are damaging the internet. (Continued)

Post-Agile?

Seen on Twitter

“Most people doing Agile today are actually doing Waterfall with Agile terms. Agile is dead.”

There are a lot of people talking about “post-agile” now that the word Agile has been taken up by the masses, including those selling products and services with the word without ever doing what some might consider to be truly Agile. (Continued)

Build a Cache, not a Stash

There are many times where a call to get some data is time-consuming or expensive. Perhaps it makes a webservice call, or a network connection to a database, or iterates over a large collection to perform a calculation. If the values isn’t going to change rapidly, and might be needed again soon, it’s natural to want to save the value for that use. (Continued)

Technical debt comes in various varieties

Ward Cunningham originally coined the term Technical Debt and described it at OOPSLA 1992

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

In this, Ward was not referring to poor programming practices, (Continued)

Lessons from Sailboat Racing

Recently, I was attending a sailing seminar on racing small keelboats. As the lecturer talked about the crew requirements for winning races, I noted a lot of similarities with effective software development teams. Both situations require a small group of people to work in coordinated concert to achieve a common goal. No one on the team succeeds alone–they all reach the finish line together. There is a mix of specialized skills and general work that almost anyone can do. And there is a constant need for improvement, coupled with a desire to go fast. (Continued)

Running cucumber on jruby under ant

I’ve just spent more time than I expected getting this to work. It seemed like it would be easy, since running cucumber from the command line is so easy. But ant is very helpful in sanitizing the environment for subprocesses–a little too helpful, perhaps. After chasing a number of dead ends and increasingly complicated detours, I ended up with this target: (Continued)

Safety Exercise

In my recent posting on Separate Retrospectives, I mentioned sometimes performing a Safety Exercise at the beginning of a retrospective where the situation was unknown or seemed a bit charged with emotion. I was asked about that exercise.

I use a simple poll of how safe people feel. I got this from Norm Kerth’s book, Project Retrospectives (page 110). (Continued)

Separate Retrospectives

I was talking recently with a friend about separate retrospectives for sub-groups. They were worried about thing devolving into separate silos, with a retrospective for programmers, a retrospective for testers, a retrospective for analysts, …. I would be worried if that happened, too, but I can see value in separate retrospectives. How can we know when they’re appropriate and when they’re not? (Continued)

Contemplating Given-When-Then

This week, Chris Matts tweeted, “Contemplating whether GIVEN-WHEN-THEN is back to front. The system should do <outcome> WHEN <event> PROVIDED <stimulus context>… Hmmm.” Let’s try an example. “Given I have $500 in my account, when I withdraw $50 then I have $450 in my account” becomes “The system should show $450 in my account when I withdraw $50 provided I had $500 in my account before.” It doesn’t exactly roll off the tongue, does it? Putting the result first makes the sentence both more complex and more passive. Yet I can understand the impulse that triggered this tweet. (Continued)