Defect Bash

In software development a Defect bash is a procedure where all the developers, testers, program managers, usability researchers, designers, documentation folks, and even sometimes marketing people, put aside their regular day-to-day duties and pound on the product to get as many eyes on the product as possible.

 Defect bash is a tool used as part of test management approach. Defect bash is usually declared in advance to the team. The test management team sends out the scope and assigns the testers as resource to assist in setup and also collect bugs. Test management might use this along with small token prize for good bugs found and/or have small socials (drinks) at the end of the Defect bash. Another interesting Defect bash prize was to pie test management team members.

 

Defect bash is an ad hoc testing where people performing different roles in an organization test the product together at the same time. This is very popular among application development companies, where the product can be used by people who perform different roles. The testing by all the participants during defect bash is not based on written test cases. What is to be tested is left to an individual’s decision and creativity. They can also try some operations which are beyond the product specifications. Defect bash brings together plenty of good practices that are popular in testing industry. They are as follows.

• Enabling people “Cross boundaries and test beyond assigned areas”

• Bringing different people performing different roles together in the organization for testing—“Testing isn’t for testers alone”

• Letting everyone in the organization use the product before delivery—“Eat your own dog food”

• Bringing fresh pairs of eyes to uncover new defects—“Fresh eyes have less bias”

• Bringing in people who have different levels of product understanding to test the product together randomly—“Users of software are not same”

• Let testing doesn’t wait for lack of/time taken for documentation—“Does testing wait till all documentation is done?”

• Enabling people to say “system works” as well as enabling them to “break the system“—”Testing isn’t to conclude the system works or doesn’t work”