Crash Party

I know what springs to mind when you hear 'Crash Party', but I am not talking about gate crashing or going to a party you haven't been invited. I am talking about Crash party before the release of the software, so let me start by explaining what is a crash party and why there is a need for one?

Testing plays a crucial role in the successful delivery of today’s complex, heterogeneous, business-critical software systems, as software get more and more complicated, there is a need to improve quality which poses challenge to the QA team, crash party is yet another way to improve quality.

Crash party is another form of collaborative group testing when a group of people (Developers, BA, QA, Support) gets together for a limited amount of time and test the functionality of the product with the intention to find as many defects as possible, it works on a very simple principle that when multiple people are using the system in a non predictable way, they are bound to find workflows (along with defects) which hasn't been thought, documented and/or tested before. Some Crash party may use a predefined script (e.g. UAT ) for the testing. Crash party can also be used for load and stress testing.

Crash party is an excellent way to bring team members up to speed, get them familiar with the area they haven’t work before, and the most important thing is to make them feel a part of the entire product.

Each team member participating in the crash party may be given an area of the product to test. Give cards or paper to each team member to record the defects and the steps to reproduce it, I would highly recommend you to not introduce any electronic bug recording system during this process, the reason being it is easier to write it on a piece of paper and expand that later once the crash party is over.

One of key things to ensure in a crash party is to make sure that the test cases and/or areas are evenly distributed among the team members and to avoid repeated test steps. Also make sure you are not executing any steps which have already been tested by automated tools and regression testing. Always tell the team member the goal is to find what we haven’t found before, 'we don't know what we don't know'.

After the Crash Party is completed, compile a list of defects found during the process, there may be some defects reported due to incorrect data entry or workflow, make sure you discuss that with the BA to ensure the defect is still relevant. The next and the most important step is to prioritise the defects to be fixed before the release; the ones which can’t be fixed in the current release will be flagged for the next release.

Finally software testing is an art, testing practices have not changed since last few years, but the tools and techniques have, complete testing is infeasible, so try to implement quality at every stage of development.