A practical testing tip: Bug Bash!
Do you ever wish your product team had more dedicated test time? Do you try to ship products with insufficient testing? Do you feel that your dev team is disconnected from QA?
Here’s a practical software testing tip, just in time for the new year. My team at Positive Networks has been doing regularly-scheduled Bug Bash days for a while now, and in general, they work really well. Here’s the idea: you schedule a time during every release cycle and dedicate the entire dev team to doing testing for an entire day. Have team members test areas of the code that they don’t own if possible (assuming that the dev owners have thoroughly tested their own code and won’t find too many more bugs themselves).
We usually schedule our bug bash between feature freeze (code complete, tested, and committed) and code freeze (no code changes at all), with enough time left in the cycle that bugs can be patched and resubmitted to QA. This works quite well for short release cycles (e.g. four- to eight-week cycles) and reasonably well for longer cycles.
To state the obvious: this is no replacement for real, dedicated quality assurance testing. Software testing is its own engineering discipline, distinct from dev, and needs organizational commitment. Bug Bash days are great as an addition, though: the dev team stays current with the details of the product through systematic testing (as opposed to random dogfooding), and dev team members are sometimes better at spotting certain kinds of bugs because of an overall familiarity with the code base.
We use it as a bit of a team-building event as well - we work in close proximity to each other, typically bring pizza in for lunch, and go out for a team dinner at the end of the day to recap results.
So, if you feel like something is missing from your test methodologies, try a bug bash! I’d love to hear how it goes.
December 29th, 2005 at 4:11 pm
Guess who found your website? Hint: You owe him a call
December 31st, 2005 at 5:43 pm
You know what else really helps the dev team? Using the product for a time. Or doing tier 3 support. Anything that takes them from the theoretical and into the practical. Your team is probably so smart that they would fix 1000 small things that make a difference to the end user if they were regularly using it or had a “lets use it day” as well. I think the disconnect between developers and end-users is a natural one, and not one you can really solve, but perhaps advanced usage might be cool. Of course your company would need to provide them with the tools to “test” your product anyway.
Brain to Brain. - Out