Will Your App Survive a Bug Bash?

Let’s face it – bug bashes are for some reason considered by a lot of devs to be a far too unsophisticated approach to software testing. The question is why? Do they fear that a process in some way poses a threat to their professionalism? Or is it that they don’t want the hot-shot rookie in the marketing team with absolutely no knowledge of code to be the one who discovers the bug that no one else thought of?

Who knows?

But it’s really a shame that bug bashes are shrouded with any degree of secrecy, distaste or distrust, for they are in an effective way of discovering if your freshly developed apps contain any annoying little (or large) glitches before being published. In fact, bug bashes are a perfect supplement to any amount of “professional” testing that takes place throughout any iteration of the most textbook agile workflow model (though of course these should also be taken very seriously).

Having said that, however, in order for a bug bash to be effective, then it needs to be conducted properly. But, before we go any further, let’s first of all answer the basic question…

What exactly is a bug bash?

Aside from being the dirty little secret of app and other software development, a bug bash is the name that is given to the procedure where whole development teams – that is, the developers, the testers, the PMs, the marketers, the designers, the researchers – put down their tools and start using the app as if it were a finished a product.

The idea is that with so many different people using the product in so many different ways in a short period of time, then any bugs that are currently contained with the version of the app will be very quickly identified.

Don't confuse it with the ShellShock/Bash Bug

Yes, just to avoid any confusion – you may have heard of something called the Bash Bug or ShellShock. Rather than a testing procedure, the Bash Bug is actually a new vulnerability that was discovered last year that affects most versions of the Unix and Linux operation systems, as well as MacOS X. If exploited successfully, the GNU Bash Remote Code Execution Vulnerability (CVE-2014-6271) could potentially allow an attacker to gain control over a targeted computer – but that’s for another blog post.

Are bug bashes common?

Well, in reality, bug bashes are a commonly used quality assurance (QA) technique implemented in the app development business in the world – but no one really likes to admit that they do them.

Why is this? Well, the fact of the matter is that bug bashes sound quite light-hearted. But if done properly, then they can be an extremely effective way of flushing out any flaws in an app very early on – but the nature of them doesn’t seem to sit well amongst the other “first class” testing methods that QA teams like to advertise.

Developing test documentation and preparing the test environment all sounds very serious – and testing an app’s functionality is indeed a very serious business. But sometimes, the best practice is to organise a good bug bash so that the app in development gets put through its paces by the people who actually matter – real users.

The bug bash in practice

Who can attend?

Put simply, the more the merrier. The whole project team should get involved in a bug bash. The more people there are putting the app through its paces, the better the chances are of bugs being discovered. Plus, each person pays attention to different aspects and details of the app, which helps tracking also UI and UX details that could be improved.

What do participants of a bug bash do?

They use the app as if they had just downloaded it from the app store. You will want to encourage your participants to explore every nook and cranny of the app, use all of its features, and basically leave no stone unturned – and take notes as they do so.

Any bugs that the bashing team discovers must be reported immediately (and if you are using outside help from people who are not professional developers, then someone will need to interpret the notes that these users take into professionally written bug reports).

The benefits of a good bug bash

Firstly, bug bashes are an extremely effective way of discovering lots of bugs in a short space of time. The idea is to run your bug bash quickly, so that any findings can be instantly fixed by the developers..

Secondly, a bug bash will create renewed excitement around the project – taking a break from those hours and hours of high concentration programming, now is a chance to actually have a play with the app and see how it’s coming along.

Tips on running a successful bug bash

As mentioned above, although a bug bash is an undeniably good way of unearthing any problems in the code, if there’s not a certain level of organization to the event, then it might not do any good at all.

So, take heed of the following tips to make sure that your bash is a ball and a boon, and not a bane of a barn dance.

1. Set a strict date and time for the event to make sure that no one changes the code whilst the bash is ongoing.

2. Make sure everybody is fully informed as to how to report bugs properly – bad bug reports just create extra work and help nobody.

3. Keep your bash focused. You don’t have to bash the whole app if you don’t want, but rather narrow the scope of the bash to certain key areas that you want tested, or direct your bash team to focus on the areas of the app you assume the weakest. You can have one final bash of the whole product at the end.

4. Create order. Someone will need to be in charge of the bug bash – and this person you can call the bug master, if you like – and he or she will run the proceedings, organise the timing of the event etc. You will also need a stager, who will be responsible for making sure that a room is allocated for the event, any prizes (see below) are sourced, that there’s a strong Wi-Fi connection, and that each participant has the app ready for bashing on their devices. Finally, unless you leave it up to your team to note down all their findings, you will need to assign a note taker to make note of any bugs that are discovered.

5. Why not make a party out of it? Some companies run bug bashes that have an element of competition introduced to the setup. For instance, you can hand out prizes for the individual (or team) who finds the most bugs, and another prize for those who find the most valuable bugs… and this is where the fun starts!

Does bug bash sound like a thing worth trying to you? Or maybe you have any experience with this method of testing? Leave us a comment and share your insights!

Netguru are currently hiring QA specialists. If you think you’ve got what it takes to join our exciting team (and are not averse to the odd bug bashing session) then get in touch to find out more.