Skip to main content

Too much testing, too little clue

A couple of interesting things shook out of today's retrospective.  It turns out that we're well behind on our targets for the current project, and two of the culprits seem to be:

  1. Too much Selenium testing
  2. No card wall

The evils of Selenium

The right way to do Selenium testing is pretty well covered in Patrick Welsh's blog and in other places.  Talk about great timing - Patrick was at the office today to give a lunchtime talk on this very subject.

The team decided to handle the Selenium problem by writing tests for only the things that we absolutely had to test through the UI.  Most of us (we'll have to revisit this) also agreed that we would keep the Se tests as small as we could get away, with while still retaining a reasonable level of test protection.

VersionOne or card wall?

The second item is something I should have brought up before, but I wasn't sure of it until I had been on the project for a month.  We have been using VersionOne as our story management system, and doing all of our updates through it.

It's a nice tool and fun to play with.  Just one problem - I wasn't  aware that we were behind this week (as in others) until after it was too late to do anything about it.  Two reasons came to mind for this:
  • I'm lazy.  I didn't realize that VersionOne had a Story Board view because I didn't take the time to learn the ins and outs of the tool.  The task-oriented view has far too much information on it to give me an overview.
  • We didn't have a card wall that I can just glance up at to see how many stories were still not done and who was working on them.
The team focused on the second bullet - lack of card wall, and I think that is a wise decision. 

It doesn't matter  how good your electronic tools are.   There is no substitute for being able to just look up and see status without any mouse clicks.  It is also very powerful to be able to stand up with another team member or two, and point at cards as you talk.  The simplicity of the setup is what makes it so powerful.

What goes on a card...and on the wall?

I did a quick search for examples of story cards, and this one (scroll down a bit after you click the link) will work.  The best setup I have seen adds some refinements to the cards and their organization on the wall:
  • Write the names of the people working on it on the card, or have mini-cards with team member's names on them that you can post next to the card their working on.
  • Have some sticky notes handy with a bright color.  If the story is blocked for any reason (even if it's something you expect to get resolved the same day), write a few words on the note describing the block and stick it on the card.
  • Organize the cards in columns by status, such as "Dev Ready", "In Progress", "Test Ready", "Test Verified" and "Business Verified".
  • Write a "definition of done" where appropriate for each status and post it at the top of each column.  For instance, "In Progress" would have bullet points like:
    • Unit tested
    • Integration tested if it has external dependencies
    • Selenium tested if it has UI components
    • Reviewed in both IE and Firefox if it has UI components
I doubt that we'll go to such lengths this late in the project, but it's something to consider for the next one.  It isn't a panacea, but it does solve several problems.

Above all, it's simple.

(Image courtesy of J'Roo's Flickr page)
Post a Comment

Popular posts from this blog

Agile Performance Management: Why Performance Reviews Suck

Many thanks to Mary Poppendieck, who wrote about this topic in 2004, and proposed a comprehensive solution.  She is the inspiration for much of my thinking on this subject.  She is also a better writer than I am a cartoonist.

Performance reviews suck.  I don't know of anyone who goes into their appraisal without some trepidation.  Your boss is guaranteed spring some surprise criticism on you that is ill-informed or misses the point as you see it.  It's a real challenge not to get defensive about that.

The only thing that makes your own performance review suck less is having to give them.  As a manager, I have dished out quite a few, and some of them went pretty badly.  (To the people at my first management job: Thanks for helping me learn how to get better at them.  Your sacrifice was not in vain.)  Since then, receiving one isn't nearly as gut-wrenching, if only because I try to make it easier for the guy on the other side of the desk.  I've been there, and I know how …

Windows 10 Driver Issue with Falcon / Z-77 Keyboard

Windows 10 has an issue with this mechanical keyboard (which works great, BTW).  It's a Chinese-made keyboard (aren't they all?), but it doesn't have much English-language support.

I captured a few screen shots of how to fix it in case someone else has the same problem.  (I got the instructions off of Tom's Hardware, but it doesn't have screen shots & isn't clear on some of the details.)

First, open up Device Manager and select the controller under USB controllers (not under keyboards).

Next, choose "update driver" from the Drivers tab.
Then choose the "browse" option (search doesn't find anything).
Then select "Let me pick from available drivers on my computer."
Finally, switch it from the ND device (which is the wrong one) to the generic USB compatible one (which works fine on my machine).

You might want to clip these instructions into your favorite notes software because:

You need to do this for each USB port you plug in…

Do. Not. Optimize.

You've probably heard this quote before:
Premature optimization is the root of all evil.
 - Tony Hoare
Speculative optimization is always wasted time.  In the absence of an actual performance problem, you're just burning time that could be better spent on refactoring your code to make it clearer.  This is exacerbated because performance-optimized code is usually harder to read than code which hasn't received such treatment.

Here is what you're doing when you optimize:
Adding code that now must be maintained.Obfuscating the existing code.Spending time writing code that doesn't add value. But what's that you say?  You have the experience and know-how to decide when optimization is needed?  Maybe, but probably not.   The people at Sun and Oracle may or may not be smarter than  you or me, but they certainly know more about optimizing Java bytecode than we do.

For example, some people think that having a large number of classes is slower than the alternative.  This …