こんにちは！atama plusでQAをしている吉原です。
「atama plus Advent Calendar 2024」12月16日の記事になります。
はじめに
atama plusでは、大きな新機能開発がある度にQA主導でbug bash(バグバッシュ)というイベントを開催してきました。回数を重ねるごとに知見が溜まり、遂には型化され、結果誰でも開催できる仕組みになってきました！今回そんな型化されたbug bashについて紹介したいと思います。この記事は、bug bashに興味がある方や、これから開催を考えている方の参考になれば幸いです。
bug bashとは
bug bashは、「新機能リリース前に大人数で集まり、探索的に機能を触ってみよう！という趣旨のワイワイしたイベントです。目的は大きく2つ、バグを見つけること、またユーザー目線で使いやすさをフィードバックすることです。
atama plus内 bug bashのこれまでの遍歴
創業当初から、大きめの新機能が追加されるたびに行ってきました。当時は開発チームは1つで、全社員でbug bashに参加していましたが、その後、チームが増えるにつれて、各チームが独自にbug bashを企画・開催するように変化しました。QA内でbug bashに対して「今回ここが課題だったから次のbug bashはこう改善しよう」とPDCAが回るようになってきました。
たどり着いたbug bashの型
さて、ここからが本題です！これからも最適化され変化しつづけるであろうatama plusのbug bashの型を紹介します。大きく4つに分けて説明をします。
- 開催するとなったらまずやること
- 事前準備
- 当日
- bug bash後
開催するとなったら、まずやること
まずは企画概要と手順を作成します。（Confluenceにテンプレートがあるので埋めていくと完成！）企画概要は事前に開発チーム内で話し合うことが大事です。
項目としては、以下の通りです。
- 目的
- 対象機能
- 対象機能の利用想定ストーリー（誰がどう使う？他プロダクトの連携は？）
- 対象外の機能
- バグバッシュのスケジュール
- 開催日程などの詳細
- 日時
- トリアージ(バグの対応優先度決め)日時
- 開催方式
- 端末
- 参加者
- フィードバック（以下FB）の収集方法
- バグバッシュ実施までのプロダクト要件
事前準備がbug bashの肝
企画概要が出来たら、次にbug bashまでに事前準備を行います。bug bashが成功するかどうかは事前準備にかかっています！（少し言い過ぎましたが、そのくらい重要だと思っています）
事前準備内容
①参加メンバーへの案内
②アカウントの作成
③テスト環境や利用する端末の選定
④不具合&FB書き込み表のフォーマット作成
「①参加メンバーへの案内」について
これは事前準備の中でも超重要です。企画概要に落とし込んだ内容から「機能のコンセプトや意図」、どのような視点で機能を体験してほしいかの「目的」など認識を揃えたい情報を、事前にSlackで参加者に共有します。体験の磨き込みをメインにするのかバグの洗い出しをメインにするのかなど、開催者と参加者で認識齟齬が出ると、せっかくのbug bashが実りのないものになりかねません。丁寧に説明をするよう心掛けています。そして、「ログイン手順」「テスト環境」「当日の進め方」も事前に案内しています。bug bashの時間は限られているので、できる限り当日bug bashの機能に関係ない内容で混乱させないように気を付けています。
「②アカウントの作成」について
bug bashの時間内で関連のない作業時間を減らすことを目的に、bug bashで利用する新規ID/パスワードを事前に大量発行しています。それに加えて、アプリ利用済みのアカウントも用意しています。これは、以前新機能リリース後、新規アカウントでは発生せず、既存の生徒の場合のみ発生したバグの教訓です。また、アカウントはスプレッドシートで一元管理し、「誰が」「どの端末で」「何の教科」をbug bash開始後に記入してもらい、アカウントとの紐づけを行っています。もしバグが発生した場合、再現確認がしやすい、同アカウントでログインし状態を確認しやすいなどの利点がありお勧めです。
「③テスト環境や利用する端末の選定」について
データの整合性やデータ量を本番に揃えることを目的に、本番データ(*個人情報を除く)を事前にテスト環境にエクスポートしておくようにしています。ちなみに前回私が企画したbug bashでは、開発環境のスペックが低く動作に影響が出たので、大人数が使っても問題ないように通常よりもスペックをあげておくと良いという学びがありました（反省）。また、端末は何を利用するのか、新機能の特色を見て判断しています。
「④不具合&FB書き込み表のフォーマット作成」について
bug bash中、参加者には不具合や機能へのFBをスプレッドシートに記入をお願いしています。項目としては、大きく、「不具合内容詳細/FB詳細」「画像を投稿したSlack URL」「対応方針(チケット化(must)/チケット化(want)/FB表に蓄積/重複のため却下/対応しない/その他」「対応チーム」「JIRAチケットURL」「ステータス（完了/進行中/未検討)」を用意しています。この表は、主にbug bash後に活躍しており、後ほど説明します。
ここまでが事前準備になります。この事前準備の流れやフォーマットも、複数回bug bashを繰り返すことで出来上がった型です！bug bashで出た不具合やFBが管理しやすいこと、参加者が気軽に参加できる会であること、共通認識を持って取り組める会であることを意識しています。あとは当日までにできる限りバグを最大限つぶしておきます！
ドキドキの当日の動き
当日は同期的に集まって実施することもあれば非同期で行うこともあります。事前に共有していた案内を口頭で共有・補足説明をし、スタートです！Slackに立てるワイワイスレでは毎回盛り上がります。ワイワイスレには、不具合/FBのある動画や画像を貼ってもらいます。ちなみに、atama plusでは重篤バグを見つけた人が優勝などの勝ち負けルールは設けていません。バグを見つけることも目的のひとつで大事なことですが、ユーザー目線で利用し些細な点を挙げてもらうのも同じくらい貴重だと感じています。
▼ワイワイスレの様子
bug bashの本番はbug bash後です
そして、終了後は開発メンバーで集まり、参加者に記入してもらった「不具合&FB書き込み表」を皆で見てQA主導でトリアージを始めます。まずは記入内容を見て不具合とFBに振り分け。
-
不具合の場合
「リリースブロッキング(修正できるまでリリースしない)」にするのか等バグに対する対応の優先度を決めていきます。バグとして対応する場合はJIRAチケットを作成し、紐づけを行っていきます。複数チームで形成されたプロジェクトの場合、どこのチームがリードするかまでその場で決めます。 -
FBの場合
UXやPOと優先度を検討し、やる場合JIRAのチケットを作成し、こちらも紐づけを行っています。ここはUX主導で行うことが多いです。
このスプレッドシートでは、バグバッシュで発見されたバグやフィードバックの進捗管理を一元化しています。そのため、抜け漏れが少なく、非常に便利です。
ここまでが、atama plusのbug bashの型です。bug bashは型化することで誰でも開催でき、開催のハードルを下げることができます。どうですか？bug bashがしたくなってきましたか？是非、bug bashする際はatama plusの型を参考にしてみてください。そしてプロダクトの特徴に合わせて独自に型化してみてください！
よいbug bashの年をお迎えください
Discussion