Hi all! My name is Yulia and I am a tester. Last year I told you about bagodelnya - an event held in our company to clean out the bug backlog. This is a completely viable option to significantly reduce it (from 10 to 50% in different teams) in just one day.

Today I want to tell you about our spring Bagodelny format - BUgHunting (BUH). This time we didn’t fix old bugs, but looked for new ones and proposed ideas for features. Below the cut there are many details about the organization of such events, our results and feedback from participants.

Having thought through and written down the regulations, we sent out an invitation to all channels in corporate Slack, which did not contain any restrictions:

As a result, about 30 people signed up - both developers and non-technical specialists. We allocated a whole working day for the event, booked a large meeting room, and organized lunches in the office canteen.

What for?

It would seem that each team tests its functionality. Users report bugs to us. Why even hold such an event?

We had several goals.

1. Introduce the guys closer to related projects/products.
   Now in our company everyone works in separate teams - units. These are project teams that are working on their own part of the functionality and are not always fully aware of what is happening in other projects.
2. Just introduce your colleagues to each other.
   We have almost 800 employees in our Moscow office; not all colleagues know each other by sight.
3. Improve developers' ability to find bugs in their products.
   We are now promoting Agile Testing and training guys in this direction.
4. Involve more than just technical specialists in testing.
   In addition to the technical department, we have many colleagues from other specialties who wanted to talk more about testing, about how to properly report a bug so that we receive fewer messages like “Ahhh... nothing works.”
5. And, of course, find tricky and unobvious bugs.
   I wanted to help teams test new features and give them the opportunity to look at the implemented functionality from a different angle.

implementation

Our day consisted of several blocks:

• briefing;
• a short lecture on testing, in which we touched only on the main points (goals and principles of testing, etc.);
• section on “rules of good manners” when introducing bugs (here the principles are well described);
• four testing sessions for projects with high-level described scenarios; before each session there was a short introductory lecture on the project and division into teams;
• short survey on the event;
• summarizing.

(We also didn’t forget about breaks between sessions and lunch).

Fundamental rules

• Registration for events is individual, which solves the problem of the entire team draining due to inertia if one person decides not to go.
• Participants change teams every session. This allows participants to come and go at any time, and you can also meet more people.
• commands two people before each session are formed randomly, this makes it more dynamic and faster.
• For introduced bugs you are awarded points (from 3 to 10) depending on criticality.
• No points are awarded for duplicates.
• Bugs must be filed by a team member according to all internal standards.
• Feature requests are created in a separate task and participate in a separate nomination.
• The audit team monitors compliance with all rules.

Other details

• Initially, I wanted to do an “advanced” testing event, but... Quite a lot of guys from non-product teams signed up (SMM, lawyers, PR), we had to greatly simplify the content and remove complex/profile cases.
• Due to the work of units in Jira in different projects, according to our flow, we specially created a separate project in which we set up a template for introducing bugs.
• To calculate points, they planned to use a leaderboard that was updated via webhooks, but something went wrong and in the end the calculation had to be done manually.

Everyone runs into problems when organizing events, and to make it a little easier for you, I will describe our problems that you can avoid.

One of the speakers suddenly fell ill and had to find a new one.
I was wildly lucky that I found a replacement from the same team at 9 am). But it’s better not to rely on luck and have a spare. Or be ready to give the necessary report yourself.

We didn’t have time to roll out the functionality, we had to swap the blocks.
To avoid throwing away an entire block, it is better to have a backup plan.

Some test users dropped, we had to quickly re-create new ones.
Cross-check test users in advance or be able to do them quickly.

Almost none of the guys for whom the format was simplified came.
There is no need to drag anyone by force. Humble yourself.
There is an option to strictly prescribe the format of the event: “amateur”/“advanced”, or prepare two options at once and decide which one to hold after the fact.

Useful organizational points:

• book a meeting in advance;
• arrange tables, don’t forget about extension cords and surge protectors (charging laptops/phones may not be enough for the whole day);
• automate the scoring process;
• prepare ranking tables;
• make paper handouts with logins and passwords of test users, instructions for working with Jira, scripts;
• Don’t forget to send out reminders a week before the event, and also indicate what you need to take with you (laptops/devices);
• tell your colleagues about the event at a demo, at lunches, over a cup of coffee;
• agree with the devops not to update or roll out anything on this day;
• prepare speakers;
• negotiate with feature owners and write more scenarios for testing;
• order treats (cookies/candies) for snacks;
• do not forget to tell us about the results of the event.

The results

Over the course of the whole day, the guys managed to test 4 projects and create 192 bugs (134 of them unique) and 7 issues with feature requests. Of course, the project owners already knew about some of these bugs. But there were also unexpected finds.

All participants received sweet prizes.

And the winners are thermoses, badges, sweatshirts.

What turned out interesting:

• the participants found the format of tough sessions unexpected, when time is limited and you cannot spend a lot of time thinking;
• managed to test the desktop, mobile version and applications;
• we looked at many projects at once, there was no time to get bored;
• met different colleagues, looked at their approaches to introducing bugs;
• felt all the pain of the testers.

What can be improved:

• do fewer projects and increase session time to 1,5 hours;
• prepare gifts/souvenirs much in advance (sometimes approval/payment takes a month);
• relax and accept that something will not go according to plan and there will be force majeure.

Reviews

Anna Bystrikova, system administrator: “The almshouse is very educational for me. I learned the testing process and felt all the “pain” of the testers.
At first, during the testing process, as an exemplary user, you check the main points: whether the button clicks, whether it goes to the page, whether the layout has moved out. But later you realize that you need to think more outside the box and try to “break” the application. Testers have a difficult job; it’s not enough to “poke” all over the interface; you need to try to think outside the box and be extremely attentive.
The impressions were only positive, even now, some time after the event, I see how work is being done on the bugs I found. It’s great to feel involved in improving the product ^_^.”

Dmitry Seleznev, front-end developer: “Testing in competitive mode greatly motivates us to find more bugs). It seems to me that everyone should try to participate in Baghunting. Exploratory testing allows you to find those cases that are not described in the test plan. Plus, people who don’t know the project can give feedback on the convenience of the service.”

Antonina Tatchuk, senior editor: “I liked trying myself as a tester. This is a completely different style of work. You're trying to break the system, not make friends with it. We always had the opportunity to ask our colleagues something about testing. I learned more about prioritizing bugs (for example, I’m used to looking for grammatical errors in texts, but the “weight” of such a bug is very small; and vice versa, something that seemed not very important to me ended up being a critical bug, which was immediately fixed ).
At the event, the guys gave a summary of testing theory. This was useful for non-technical people. And a few days later I caught myself thinking that I was writing in support of another site using the “what-where-when” formula and describing in detail my expectations from the site and reality.”

Conclusion

If you want to diversify the life of your team, take a fresh look at functionality, arrange a mini "Eat your own dog food", then you can try to hold such an event, and then we can discuss it together.

All the best and fewer bugs!

Source: habr.com