Automating Bug bash
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
What is the bug bash process?
Who is your target audience? Development teams, developers, product owners, someone else?
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.
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
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.