Talking testing, agility and automation... and anything else.

Dec 12

Should You Just Stop Tracking Bugs?

With apologies to Ian Betteridge for the hyperbolic headline, I wanted to share this 6 minute lightning talk in which Jon Tørresdal argues for “The simplest solution to bug tracking: don’t!”.

To paraphrase Jon’s list of 5 “crazy ideas”:

  1. Don’t track bugs; just fix them
  2. Delete all bugs in your backlog that you can’t fix immediately
  3. All newly reported bugs are either rejected or fixed immediately
  4. Automated tests are created for each new bug
  5. Set WIP limit for bugs (eg. 20 total)

Ten years ago I would have scoffed at the idea of not tracking bugs and deleting the bug backlog, but today, I can see this as a realistic possibility. In fact, this isn’t far from how my current team operates today. So what’s stopping me from going all in? Guts?

Nov 12

Gojko Adzic “Reinventing software quality”

Here’s a very interesting presentation from Gojko Adzic. Entitled “Reinventing software quality”, Gojko builds a parallel between Abraham Maslow’s hierarchy of needs and software quality.

Fellow tester/blogger Augusto has a nice first-hand recap of this presentation as well…

Dec 11

Testing In The Cloud

I’ve been watching some of the presentation videos from the 2011 Google Test Automation Conference (GTAC) and found this one to be particularly interesting. Entitled “Building a Test Grid for the Cloud”, Simon Stewart talks about writing tests, ensuring test isolation and testing in the cloud (including Amazon’s EC2).

Dec 11

Better Communication From A Distance

There’s an old joke in Bluegrass music circles that goes “Bluegrass musicians will drive hundreds of miles to jam with people from their home town”. It’s funny ’cause it’s true. While attending a ThoughtWorks workshop this past year, with a faction of my company’s QA team, I discovered this joke can also apply to software testers. Eg. it can take traveling hundreds of miles to get testers from the same company to work together.

At the workshop, it quickly became clear that many of the questions or pain-points expressed by individuals within our group, were at least shared by, and in many cases, could be solved by, other individuals from our group. With that powerful knowledge in hand, I paired up with a coworker to hatch a plan (over cocktails… ’cause we’re from Wisconsin) to leverage this shared knowledge and pain.

The plan was simple enough; set up bi-weekly QA meetings, at which a pair of testers would facilitate the meeting and make a presentation to the rest of the group. Fairly straight ahead but there’s some details to call out…

The meeting will:

  • Be one hour. Topics must be sized and focussed to fit.
  • Facilitated by a pair of testers. The idea being each will QA the other’s work, thus solidifying their concept and streamlining the meeting.
  • Be tool agnostic as possible (unless the a tool itself is being presented).
  • Include an example(s).
  • Attempt to ask and answer a question.
  • Concentrate on topics that affect the entire group. Questions will come up at the meetings themselves that can/should be tabled for a future meeting topic.

The overall premise for the meetings are for the presenters to “show their cards”, as it were. Show examples of what they are actually doing; not what some book says you should be doing. This is essental and it takes a lot of courage to expose yourselves in this way… especially to a room full of QA! I’ve found the fear/pain from such exposure can be lessened substantially by pairing facilitators and allowing them to come to a concusses before presenting. Strength in numbers! This has also proved to keep the conversations at the meetings focused.

We’ve been running these for a couple months now and the response has been extremely positive. I documented one of the topics from a meeting in a previous post… I’ll try to continue to do so.