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.
