Skip to main content

Automating Bug bash

Last post 04:12 pm April 12, 2019 by Henri van der Horst
4 replies
03:56 am April 10, 2019

Hello All,



Working on a project to automate the bug bash process. Please comment on the following things:

1. Issues/Bottlenecks/pain points faced in the process of bug bash faced by different stakeholders

2. Any feature of bug bash to automate

Thanks


11:28 pm April 10, 2019

What is the bug bash process?

Who is your target audience? Development teams, developers, product owners, someone else?


02:49 pm April 11, 2019

Given the information you provided, I find no way to give you any advice.  What exactly do you mean by "automate the bug bash process"? What are the bugs you are bashing?  Are you trying to automate the testing in an attempt to prevent bugs or are you trying to build automated build process?  What does any of this have to do with Scrum? 

Provide some more information and we might be able to help. 


03:54 am April 12, 2019

Thank you for your reply.

Automation word used here is with respect to improving the UX of the users who would be participating in the bug bash. This could be in terms of logging a bug, triage etc.The testing process would rather remain the same.

I plan to create a bot which would help the developers to set the test environment, do automatic bug creation on platforms like Azure DevOps, find duplicates etc.  

Target audience: Developers, Project Manager, Testers (if any), Designers etc.

I want the process to be as generic as possible. So the type so bugs won't be in the problem statement.

Thanks


11:56 am April 12, 2019

A bug 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"—that is, each exercises the product in every way they can think of. Because each person will use the product in slightly different (or very different) ways, and the product is getting a great deal of use in a short amount of time, this approach may reveal bugs relatively quickly. (Source: https://en.wikipedia.org/wiki/Bug_bash)

The power of the bug bash is the unpredictability. Random people do random things in your product. You never know what they may do next.

This unpredictability is hard to automate, as you normally only automate what you can predict. So you will need to introduce randomness in your test automation. Perhaps use RNG (Random Number Generators) to simulate weird behaviour? 

E.g. you could make an array of a million random values with all the different formattings, data types, lengths and precisions that you can think of. Then use RNG to put these values in your screen fields, whether they match the expected input type or not. Or you could use RNG to determine how many times in a second to perform an action and have RNG determine if that action is to e.g. submit a form, push a button or reload a screen.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.