If you find an escape (i.e., a bug for something marked “Done”), you may want to develop an automated check for it.  In a meeting today, there was a discussion about when the automated check needed to be developed?  Someone asked, “Should we put a task on the product backlog?”.  IMO:
The automated check should be developed when the bug fix is developed.  It should be part of the “Done” criteria for the bug.
Apply the above heuristically.  If your bug gets deferred to a future Sprint, deffer the automated check to that future Sprint.  If your bug gets fixed in the current Sprint, develop your automated check in the current Sprint.

Acceptance Criteria.  When User Stories have Acceptance Criteria (or Acceptance Tests), they can help us plan our exploratory and automated testing.  But they can only go so far.

Four distinct Acceptance Criteria does not dictate four distinct test cases, automated or manual.

Here are three flavors of Acceptance Criteria abuse I’ve seen:

1. Skilled testers use Acceptance Criteria as a warm-up, a means of getting better test ideas for deeper and wider coverage.  The better test ideas are what need to be captured (by the tester) in the test documentation...not the Acceptance Criteria.  The Acceptance Criteria is already captured, right?  Don’t recapture it (see below).  More importantly, try not to stop testing just because the Acceptance Criteria passes.  Now that you’ve interacted with the product-under-test, what else can you think of?
2. The worst kind of testing is when testers copy Acceptance Criteria from User Stories, paste it into a test case management tool, and resolve each to Pass/Fail.  Why did you copy it?  If you must resolve them to Pass/Fail, why not just write “Pass” or “Fail” next to the Acceptance Criteria in the User Story?  Otherwise you have two sources.  Someone is going to revise the User Story Acceptance Criteria and your test case management tool Acceptance Criteria instance is going to get stale.
3. You don’t need to visually indicate that each of your distinct Acceptance Criteria has Passed or Failed.  Your Agile team probably has a definition of “Done” that includes all Acceptance Criteria passing.  That being said, if the User Story is marked Done, it means all the Acceptance Criteria passed.  We will never open a completed User Story and ask, “which Acceptance Criteria passed or failed?”.

Hey testers, don’t say:

“yesterday I tested a story.  Today I’m going to test another story.  No impediments”

Per Scrum inventor, Jeff Sutherland, daily standups should not be “I did this…”, “I’ll do that…”.  Instead, share things that affect others with an emphasis on impediments.  The team should leave the meeting with a sense of energy and urgency to rally around the solutions of the day.  When the meeting ends, the team should be saying, “Let’s go do this!”.

Here are some helpful things a tester might say in a daily standup:

• Let’s figure out the repro steps for production Bug40011 today, who can help me?
• I found three bugs yesterday, please fix the product screen bug first because it is blocking further testing.
• Sean, I know you’re waiting on my feedback on your new service, I’ll get that too you first thing today.
• Yesterday I executed all the tests we discussed for Story102, unless someone can think of more, I am done with that testing.  Carl, please drop by to review the results.
• I’m getting out of memory errors on some test automation, can someone stop by to help?
• If I had a script to identify data corruption, it would save hours.
• Paul, I understand data models, I’ll test that for you and let you know something by noon.
• The QA data seems stale.  Don’t investigate any errors yet.  I’m going to refresh data and retest it today.  I’ll let you know when I’m done.
• Jolie, if you can answer my question on expected behavior, I can finish testing that Story this afternoon.

Your role as a tester affects so many people. Think about what they might be interested in and where your service might be most valuable today.

At this week’s metric themed Atlanta Scrum User’s Group meetup, I asked the audience if they knew of any metrics (that could not be gamed) that could trigger rewards for development teams.  The reaction was as if I had just praised Planned Parenthood at a Pro-life rally…everyone talking over each other to convince me I was wrong to even ask.

The facilitator later rewarded me with a door prize for the most controversial question.  What?

Maybe my development team and I are on a different planet than the Agile-istas I encountered last night.  Because we are currently doing what I proposed, and it doesn’t appear to be causing any harm.

Currently, if 135 story points are delivered in the prior month AND no showstopper production bugs were discovered, everyone on the team gets a free half-day-off to use as they see fit.  We’ve achieved it twice in the past year.  The most enthusiastic part of each retrospective is to observe the prior months metrics and determine if we reached our “stretch goal”.  It’s…fun.  Let me repeat that.  It’s actually fun to reward yourself for extraordinary work.

Last night’s question was part of a quest I’ve been on to find a better reward trigger.  Throughput and Quality is what we were aiming for.  And I think we’ve gotten close.  I would like to find a better metric than Velocity, however, because story point estimation is fuzzy.  If I could easily measure “customer delight”, I would.

At the meeting, I learned about the Class of Service metric.  And I’m mulling over the idea of suggesting a “Dev Forward” % stretch goal for a given time period.

But what is this nerve I keep touching about rewards for good work?

On weekends, when I perform an extraordinary task around the house like getting up on the roof to repair a leak, fixing an electrical issue, constructing built-in furniture to solve a space problem, finishing a particularly large batch of “Thank You” cards, or whatever…I like to reward myself with a beer, buying a new power tool, relaxing in front of the TV, taking a long hot shower, etc.

Rewards rock.  What’s wrong with treating ourselves at work too?