この記事は「Autify Advent Calendar 2022」22日目の記事です。

株式会社レコチョクで品質保証を担当している清崎と申します。
つい先日QAチーム内で第1回目のBug bashイベントを開催してみましたので、実施内容の紹介をしつつ振り返ってみたいと思います。
※ 記事内では対象プロダクトの説明と具体的なバグの内容は割愛します。

Bug bashとは

検索エンジンで「Bug bashとは」で調べると

英語から翻訳-ソフトウェア開発では、バグバッシュとは、すべての開発者、テスター、プログラムマネージャー、ユーザビリティリサーチャー、デザイナー、ドキュメント担当者、場合によってはマーケティング担当者が、日常業務を脇に置いて「製品にお金をかける」手順です。 "—つまり、それぞれが考えられるあらゆる方法で製品を実行します。ウィキペディア（英語)

Wikipediaの自動翻訳が怪しいですが・・・いろんな立場の人達で集まり「普段の業務とは別に時間を確保して」対象のプロダクト（=サービス）に触れて「バグを見つけ出す」という理解で良いと思います。

開催理由

ポジティブにバグを見つけ出すという発想が斬新で気になりました。
まずはQAチーム内でコミュニケーションを図る目的でトライして、良い結果がでれば社内で横展開をしようという狙いもあり開催に動き出しました。

目的

参加者同士でコミュニケーションを促進
業務だけど普段の業務と違った感覚でプロダクトに触れて気分転換してほしい
さまざまなプロダクトに触れる機会になり、プロダクトに対する知識を蓄えてほしい

事前準備

対象にするプロダクトの候補を出しから着手して、プロダクト担当者を口説いた上で決定しました。（ご理解ありがとうございました）
プロダクトが決まったら開催に必要な「ルール」「テストデータ」「報告手段の用意＆評価方法決め」「賞品」など書き出して、開催日から逆算して準備を進めました。
また、当日は説明の時間に余裕が無くなる可能性があるため、概要資料を作成して参加者へ事前配布することにしました。

ルールについて

指定した環境でそのプロダクトのサービスや機能や触れてみて、バグを発見したらエビデンス（スクショや動画など）を指定の方法で報告する。
制限時間は1回10分
見つけたバグに対して評価して得点をつける
得点が高いチーム（または個人）が優勝　※今回は個人戦
同じバグを見つけた人がいた場合は先着のみ有効

タイムテーブル

実施項目	時間
説明	15分
実施（1回目）	10分
休憩＆途中集計	10分
実施（2回目）	10分
休憩＆集計	10分
発表	10分

全体の流れと実施対象のプロダクトについて説明
実施の時間は10分（2回実施）
見つけたバグを運営が評価

バグ報告内容の説明

項目	説明
事象内容	発生したバグの要約
発生箇所	発生した画面や機能、URLなど
期待値	期待している動きや結果
手順	操作内容を簡潔に
実施環境	クライアントの環境（デバイス、OS、ブラウザなど）
エビデンス	スクショや動画

ここは普段の業務でQAやっていれば基本的なところではありますが、短時間で報告するために最低限な項目に絞りました。

報告方法

報告方法はFormsのアンケートフォームを作成して、結果を表ですぐに集計できるようにしておきました。

評価方法

項目ごとに割り振った評価指数を加点していく方法を採用

プラスαとして評価者が独断で、これは熱いと思ったものがあれば「89盛賞」として8.9点を加えます。

賞品

壁打ち的な開催ですが、何もないとやる気も起きないと思いましたので、気持ち簡単なものですが用意しました。

優勝・・・「からあげクン」数個分の電子クーポン
敢闘賞・・・「コンビニコーヒー」数杯分の電子クーポン

おなじみのからあげクンですが、実はあのキャラクターは「妖精」なんですね・・・知らなかったです。
そして妖精のイラストが書かれた激レアあらあげくんがあるらしいという話題がでたので採用

第一回目の実施

実施時間：65分
トライアル要素が高く、業務の合間なので極力拘束しない範囲でバッファ込みで1時間30分確保しました。
参加人数：7名
※ 今回はチーム単位にするほど人数が居なかったため個人戦

実施結果

報告数：18件（うちバグ認定17件）

実施前は全く見つからない可能性もあると思ったのですが、短時間でこれだけ見つけられました。
普段の仕事ではネガティブなことですが、不思議とポジティブな気分になりました。

結果発表

MKさんが57点で優勝、味わい深い事象を見つけたAKさんが敢闘賞でした！

振り返り

開催後に参加者でKPTを実施して次回開催に向けた改善点を洗い出しました。
いろいろ意見が飛び交いましたが簡単に抜粋すると・・・

Keep

10分の実施だと煮詰まらない程度にできるからよい
全くバグが見つからないことはなかった
テスト環境やデータなど事前準備ができていた
ゲーム性があり楽しい
など

Problem

点数が偏ってしまうので採点方式は見直したほうがよい
予定より集計に時間がかかってしまった
それぞれどのような点を狙ったかを作戦を共有したほうがよい
など

Try

採点方法を見直す
どこを重点的に見るかガイドラインを最低限与える
運営者の人数を増やす
など

採点方法を見直す

特に採点は加点方式だと数多く不具合を報告した人が高くなるという傾向になるため、バグではないものは0点にするなどして乗算したほうが競えるかもしれません。
「4. 手順」の"通常：5"、"限定：3"、"イレギュラー：1"という評価指数は逆にしたほうが良いのではないかという意見もありました。
どうしても普段の業務でQAをしていると「通常手順」で発生するものは、発生頻度が高い（＝緊急度が高い)となるため無意識に評価指数を高く割り当てていました。
イレギュラーを高くすると、宝探し感覚でいろんな操作を試してみたくなるので、もっと面白くなるかもしれません。

どこを重点的に見るかガイドラインを最低限与える

第一回目の参加者は全員QAなので不具合の見つけ方や操作の説明は不要でしたが、開発者や事業部門の人が参加する場合は、操作方法やどのような所を狙うのかなどテストのコツを説明する必要がありそうです。

運営者の人数を増やす

今回の第1回目は実施者へのサポートは特に問題なかったですが、報告の確認や評価などやることが短時間に集中するため、サポートは居たほうがよいです。

その他

また、開催後もバグの傾向を分析して、今後のテストのための教訓にすることも大切です。
リスクの高いバグや他でも有りそうな事象であれば「観点リスト」の更新や「リグレッションテストのシナリオ」を見直すなども必要に応じて行います。
弊社の場合は、バグが修正されたら自動テストツールAutifyでリグレッションテストを行い新しいバグが出現していないかテストを実行しております。
リソースは限られているので、こうやって手動テストと自動テストを使い分けて互いに補完し合うことが大切になってきます。

まとめ

開催を決めてからしっかりと準備をしていたため、混乱なく実施することができた（普段の仕事と同様に段取りは重要）
説明は手を抜かずしっかりと行う
評価方法と採点はシミュレーションしておく
短時間で集計する必要があるため、運営者は1名とサポートが必要

参加者からは楽しかったという意見しかなかったため、非常に有意義な時間であったと思います。
あと数回壁打ちして、慣れてきた頃に複数部門へ展開することで品質意識を醸成してまいりたいと思います。

告知

レコチョクでは一緒に活躍してくれる仲間を募集しております。
興味がある方はぜひ採用情報ページを御覧ください！