Archive | Lessons Learned RSS feed for this section

Testing Has No Value

By on November 14, 2012 in Lessons Learned

Update Nov 20: minor edits to increase clarity.

Yesterday, Rob Lambert tweeted:

Turns out that’s a statement from the ISTQB Expert Level Syllabus on Test Management. Robert was tweeting it to see what others’ reactions were to the statement.

Now, I hold no love of the ISTQB. I don’t see any correlation between ISTQB certification and tester competence. I think an awful lot of what the ISTQB promotes as “best practice” is at best context-dependent and at worst actively damaging. But that’s a topic for another post, one I probably will never write. It’s just not worth the energy. I don’t feed that which I don’t want to see grow.

But my point is that I don’t put any stock in anything the ISTQB says, so I was absolutely stunned to find that I agreed with a statement in an ISTQB syllabus.

So I replied, “Whodathunk I’d agree w/ istqb. Unless org sells test svcs, its is a means to an end, a way to get info.”

That touched off a small storm of responses, some agreeing, but many more disagreeing. I’ve been replying to the objections on Twitter, but I think this topic needs more than 140 characters.

First, a few clarifications:

1) I am talking specifically about software development.

2) I am talking about business value.

3) Business value is inextricably linked with increased revenue or decreased costs. That’s not decreased costs of software development. It’s overall decreased costs that can be attributed to the use of the final delivered software.

So the value in software development rests in the final result—the delivered product or service—not the process or activities that went into making the result.

Testing does not have value on its own. Neither does programming. I have seen more than one team crank out lots of code and yet be unable to ship a product anyone would buy. For that matter, designing doesn’t have intrinsic value either.

“But wait!” you say. “Testing does have value. Customers pay more for better quality software, so testing has value.”

Well no. First, it’s not clear that customers pay more for better quality software. Customers are less likely to abandon better quality software in a fit of rage. But they don’t necessarily pay more for the kind of quality that comes from having testers do more testing. Further, testing does not automatically lead to better software. In fact, better testing can actually lead to worse software. Finally, as Ron Jeffries pointed out, testing only adds value to the extent that the team uses the information that testing produced in order to improve the software.

But that’s not even the main point here. The main point is that testing and programming and designing and all the other activities that go into making software are all just a means to an end. As UCLA coach John Wooden said, “Never mistake activity for achievement.”

The bottom line is that if you want your work to have value, make sure that the software you’re working on ships and satisfies customers. The final result is a whole team effort. The team succeeds or fails together. And the value of the work you’re doing is stuck at 0 until the software you’re working on is in the hands of paying customers.

Comments { 12 }

Agile Up 3 Here

By on May 31, 2011 in Gatherings, Lessons Learned

We held Agile Up 3 Here at Agilistry Studio last week. Nine people gathered from all around the world for our second week-long intensive. Our team consisted of Alan Cooper, Jim Dibble, Pat Maddox, Alex Bepple, Brendon Murphy, Dale Emery, Matt Barcomb, Dave Liebreich, and me. Once again, we were working on mrhomophone.com.
My insights from the week:

  1. Distilling down to the absolute core of the intent for a given period of time is harder than it sounds. It’s tempting to include little nice-to-haves in the stories. Even when implementing, it’s tempting to do a bit of polishing in unrelated areas.
  2. Perhaps the temptation to expand the scope of the deliverable beyond the bare bones isn’t all bad. It can enable us to kick things up a notch, deliver something that surpasses the merely functional to something that feels indulgent.
  3. Or perhaps the temptation is dangerous. To the extent that we allow the extraneous little bits in, we risk losing sight of the bigger and more important goals.
  4. Laser-focused pair partners help with the struggle to distinguish between kicking things up a notch, yak shaving, and losing focus.
  5. Explicit working agreements help create safety (as well as creating a tight-knit team with a strong shared culture).
  6. Shared in-jokes and language also create shared culture. (“System Testing!” Ha ha!) Note that unless you were here, you have absolutely no idea why “system testing” might be funny. Even if I explained the joke, you still probably wouldn’t think it was funny. It’s a “you had to be there” kind of thing. And that’s why shared in-jokes are powerful for creating tight-knit teams.
  7. Creating a sense of safety is critical for learning.
  8. Deciding whether or not to upgrade your infrastructure cannot be a unilateral decision. (On the other hand, I don’t think I made the wrong call; I just did it the wrong way and at the wrong time. If I were to do it all over again, I would open up the discussion with the group in advance. And assuming we decided to upgrade our technology stack, I would start earlier and with more help in the beginning.)
  9. Integrating a test effort is hard, even when all the programmers are test infected and the tester is highly competent.

On a more personal note…

  1. When I think I have an answer, I cling to it doggedly. And when I finally let go of something, I really let go of it.
  2. I am extremely fond of my yak and cannot bear the thought of losing it, even if it will be replaced soon. (Sorry Alex.)
  3. It’s possible for people who don’t live here to introduce me to new things in my own back yard. Go figure. (Thanks for introducing me to the crazy dive bar, Pat.)

So that’s AU3H in a nutshell. AU4H will (probably) take place in May 2012. Details in another 6 months or so.

Comments { 0 }