Is there a name for these kinds of tests?

Question

In our company we have established some rule that from time to time (once a week or every few days) the whole team spends half an hour of testing their own software in its current state. We established this because we are producing a multi-user web application and it turned out to be a good way to find multithreading-related errors when the whole team of e.g. 10 persons are clicking around in parallel on the same server.

However it turned out to be much more valuable than initially thought, especially because developers get early feedback on how their components really feel when used, also from other devs. Additionally we usually find a huge amount of bugs because in this half hour of intuitive testing often functionality is executed which was not even part of recent changes.

So basically the question is if there is a name for this kind of the-whole-team-and-also-the-devs-click-around-for-some-while tests?

Answer 1

We have always called this bug bashes bug bashes

Some guidelines we have used include:

1. Set a date and put this on the team's schedule
2. Provide guidance on the purpose/scope of the bash - specific area (at risk feature, globalization, security, etc) or anything goes
3. Provide a template for filing bugs (including guidance for pri/sev, etc)
4. Provide incentives (food, recognition, etc)
5. Send mail at least 1 day before event with specifics (environments, build number, areas, link to template, POC, etc)
6. Send status throughout day
7. Encourage exploration of features outside area of expertise/ownership
8. Send thank you to all participants and summary of bash results the day after.

If possible I would also encourage folks to get out of their offices (e.g. mobile app testing) or have them buddy test with another person. Another idea we tried was to make a game of it (e.g. folks have to use various features in solving a puzzle)

Answer 2

That sounds like a great practice. You described at least two kinds of activities:

• Ten people clicking around in parallel on the same server. I would call this an informal load test. It is informal in the sense that the individuals are not coordinating their activities and may not be following a predetermined (or repeatable) process. While the process is informal, you can, as you said, still gather some useful feedback from it.
• Developers trying out other developer's components. I would call this an informal usability test. I call it informal for the same reasons as above. Informal usability tests are still surprisingly useful for finding bugs and usability issues.

I would call the practice as a whole a testing party. I chose that term because it sounds informal and fun rather than bureaucratic. (It also suggests the possibility of beer, which might increase participation.)

Answer 3

In the past, I've occasionally referred to this as a "Test Fest".

Sometimes, I've formalized it a bit more, and even added the element of background load as well: http://www.allthingsquality.com/2010/04/automation-assisted-test-fest.html

In the right circumstances, this can be a very useful practice.

Answer 4

The term used at Microsoft and generally in the Seattle area (and undoubtedly elsewhere) is "Bug Bash". The link is to the Wikipedia article, which describes what you have described (it's not a good article at the moment, but can at least confirm that the term is used this way).

The general style of testing where someone tests without test cases is called "exploratory testing", and bug bashes - having the entire team or company spend a period of time 'bashing' the product to find bugs - are one technique that is used in exploratory testing.

Answer 5

Exploratory testing

What each person is doing sounds like exploratory testing. In other words folks in your company use their domain knowledge to test the front end. I do not believe there is a formal term for the multi-threaded aspect of testing that it covers.

You could call it exploratory load testing or manual volume testing. The fact that you are finding so much value in what people just discover in the app, functionality-wise would tend to lead me to just use the term Exploratory Testing to cover both areas ("exploring functionality and exploring volume). One could use exploratory volume testing but that leaves out one part.