Bug Bash（バグ バッシュ）を社内のイベントで開催しました。

はじめに

こんにちは。モバイルエンジニアの大澤です。
今回は、私とAndroidエンジニア兼品質保証を担当している高津で企画して開催した「Bug Bash（バグ バッシュ）」についての話です。

Bug Bash（バグ バッシュ）とは

• チームメンバー全員で、指定期間内にバグを見つけ出すイベントです。
  テストケースは用意せず、各自が思いつく限りの方法で操作してバグを検出します。

目的

1. 品質向上
   • 多数のバグを発見できるので、その後のプロセスとして優先度の高いバグから修正できます。
2. コラボレーション
   • チームメンバー全員で参加するため、チーム内のコラボレーションを促進します。
   • チーム全体で問題解決に取り組む意識を高めることができます。
3. 早期発見によるコスト削減
   • 開発中の機能をターゲットに含めることで、早期にバグを発見でき、コストを削減できます。 (Shift Left)
     • 障害修正がリリース後になってしまうとコストが数百倍になるとの論説があります。
4. ナレッジ共有
   • 自分では見つけられなかったバグの見つけ方や解決方法が共有できます。また、エンジニア以外も参加できる場合は異なる立場による視点の違いを共有できます。

事前準備

• 他社事例などをリサーチし、どのように運営するかを考えました。
• 本番にスムーズに運営できるように、企画者2名でプレ開催をやってみました。 そこで出た懸念点をまとめ対策を練りました。
  • e.g 参加する人はどうするか？ バグの評価はどうするか？ バグの報告方法はどういう形がいいか？

ルール

プレ開催したデータをもとにルールを再構築しました。

• 個人戦。
• テスト対象はiOS, Androidアプリどちらでも可能。
• 制限時間は30分。
• バグや要望を見つけた場合、専用のSlackチャンネルで投稿。
  • Slackのworkflowを活用し、投稿フォームを揃える。
  • 端末 & OSバージョン、事象内容、発生箇所、期待値、手順などの最低限の項目を記載する形にした。

  

  • 投稿内容はスプレッドシートを同期し、点数管理をする。
• 点数は採点者が判断。

点数	説明
0点	すでに見つかっているバグ 仕様です 修正予定にならない要望
1点	軽微なバグ バグではないが修正した方がいい要望
3点	ナイスバグ サービスのクオリティに関わるバグ 渋いバグ 見つけにくいバグ、長年見逃されていたバグ

• 表彰
  • バグブラスト賞 (Bug Blast Award)
    
    • "ブラスト"は爆発や大量の発射を意味し、大量のバグを発見した参加者を称賛します。
  • バグバウンティ賞 (Bug Bounty Award)
    
    • 検出した障害の価値が最大の参加者に贈られる賞です。

当日

• エンジニア8名で開催。
• オンライン開催。
• 採点者兼解説者と実況者と集計係で運営し、リアルタイムで採点しました。
  • リアルタイムでやることでゲーム性が上がり盛り上がりました。
• 結果、30分間で不具合が20個近く見つかりました。
• 最後は優秀な成績を納めた人からテクニックなどを教えてもらいました。

参加者の感想

• バグもそうですが、うっすらと疑問に思ったり、ちょっと変だなと思う箇所を気軽に指摘できるので良い試みだと思いました。
• テストケースを作成せずに探索的にテストすることがあまりなかったので、とてもワクワクしました。
• 普段は最新の機能に意識をフォーカスしていたり視野が狭まっている気がします。改めて、全機能や体験を統合的にみることで、ユーザー目線を得られた気がします。

次回、開催時にやってみたいこと

• チーム戦や参加するメンバーをエンジニア以外に広げる。
  • チーム戦にすることで自分にはない視点でバグを発見することが期待できる。
  • エンジニアだけだと視点が偏るのでチーム内のコラボレーションを促進するような形にしていきたいです。

お知らせ

askenでは、エンジニアを募集しています。

www.asken.inc

参考リンク

• Bug bash
• マネーフォワードでBug bashをやってみた
• バグバッシュをアプリ開発のプロセスに組み込んだ話