[QA]バグバッシュ再考
こんにちは世界!
ログラス QA担当のおおひらと申します。
みなさん、バグバッシュはお好きですか?
今回のテックブログでは、ログラスでも実施しているバグバッシュを再考していきます。
バグバッシュを実施したことがある方も、まだ実施したことがない方も今後の参考にしていただければ幸いです。
はじめに:バグバッシュの概要
まずは、バグバッシュについて、
日本語のWikiにはありませんでしたが、英語のWikiには以下の説明があります。
ソフトウェア開発におけるバグバッシュは、
すべての開発者、テスター、ユーザビリティ研究者、デザイナー、ドキュメント担当者、そして時にはマーケティング担当者さえも、通常の日常業務を脇に置いて「製品に取り組む」手法です(おおひら意訳)
引用:https://en.wikipedia.org/wiki/Bug_bash
一般的にバグバッシュは、限られた時間の中で、プロダクト開発チームやステークホルダーが製品の不具合を積極的に探し出す活動です。
私の解釈としては、プロダクトに関わる関係者が目的を持ってプロダクトを操作し、不具合だけではなく懸念点や使いやすさなど、たくさんのフィードバックを出し合う会だと考えています。
バグバッシュの目的
私の考えるバグバッシュの目的は、以下の通りです。
1. 多面的な目線で問題を見つける
通常のテストプロセスでは見落とされがちな問題も、異なる専門家が関わることで、発見できる可能性が高くなります。また、広範な視点から、さまざまなフィードバックを得ることも狙えます。
2. 関係者がプロダクトの知識を深め合う
バグバッシュは、メンバーが製品についての知識を共有し、相互に学び合う機会になります。これにより、製品に対する理解がさらに深まり、より質の高いフィードバックが可能になると考えます。
3. プロダクトに関しての対話を促進する
バグバッシュは、開発者、テスト担当者、その他関係者が製品について話し合い、アイデアを交換する場を提供します。この対話は、製品改善のための新たな視点やアイデアを生み出すきっかけとなります。
4. 関係者がプロダクトへの覚悟を持つ
バグバッシュを通じて、各関係者は製品に対する責任感を強く意識するようになります。これは、製品の品質向上だけでなく、チームとしての一体感を高めるきっかけとなります。
バグバッシュの注意事項
次にバグバッシュの注意点について考えてみます。バグバッシュは有効な点が多いですが、万能なプロセスではありません。目的を考えて、以下の点を注意する必要があります。
1. 保証型のテストではないため他のテストと組み合わせる必要がある
特定の問題やエリアに焦点を当てる手法であり、網羅的なテスト手法ではありません。効果的なバグバッシュのためには、ある程度網羅的な保証型のテストを事前に実施する必要があります。
2. 操作する環境が必要になるため開発の後工程になる
バグバッシュは、操作できる対象がないといけないため、開発の後半段階で実施する必要があります。そのため、事前に操作に影響のある問題は他のテスト活動で防ぐ必要があります。
3. 参加者の選定と説明の重要性
バグバッシュの成功は、参加者の選定と事前の説明に大きく依存します。様々な専門分野からプロダクトに関係する参加者を選び、参加者へバグバッシュの目的と方法を明確に説明することが重要です。
バグバッシュの実施方法
バグバッシュを成功させるためには、計画的かつ戦略的なアプローチが必要です。以下は、私が考えるバグバッシュを効果的に実施するための手順です。
1. バグバッシュを設計する
まず、バグバッシュの効果的に実施するため、目的などを設計します。私が設計する場合は、以下の項目を検討することが多いです。
- 目的の設定
- 関係者からフィードバックをたくさん貰いたい
- 関係者の製品知識を深めたい
- 実施方法の検討
- グループで行うか、個人で行うか
- チャーターをどうするか(製品、機能単位、シナリオ)
- 参加メンバーの検討
- 他チーム、ビジネスサイトなどどこまで巻き込むか
- 実施日時や回数の検討
- 対象が多い場合は複数回を実施するなど
- 実施会場の検討
- オンラインで実施するか、オフラインで実施するか
- フィードバックの分析方法
- バグバッシュで得られたフィードバックをどのよう評価し、製品に取り入れるか
- フィードバックのご褒美(参加のモチベーションをあげるために大切)
- 採点基準や景品の選定
2. 関係者への説明と告知をする
バグバッシュの設計ができたら、事前に関係者へ趣旨と目的の説明会を実施します。会の目的、どのような観点で製品を操作すれば良いかを事前を事前に周知することで、参加者が効果的にバグバッシュができることを狙います。また、事前に説明会を実施することで、バグバッシュの設計に対して、フィールドをもらうことができ、内容や参加者の調整することができます。
3. 資料や環境を準備する
アジェンダの作成、実施した操作やフィードバックの記録先の準備、実施環境のセットアップなど、バグバッシュ当日にスムーズに進行できるように事前準備を行います。また、実施環境では、顧客利用を想定しやすくするため、リアルなテストデータの用意することが重要です。
4. バグバッシュを実施する
当日はアジャンダをもとにバグバッシュを実施します。実施時に楽しい雰囲気作りは大切です。参加者がフィードバックを共有しやすい雰囲気や環境を整えると場も盛り上がり、関係者の対話も進みやすくなります。わいわい感を演出するため、お菓子を用意したり、音楽をかけることもいいですね。
5. バグバッシュで得られたフィードバックの分析
バグバッシュ終了後、別途、チーム内でフィードバックを分析する会を実施します。フィードバックが集中している特定の機能はないか、特定の職種やロールにどのようなフィードバックが多いかなどの情報をもとに製品の改善を検討します。
6. バグバッシュの振り返り会で感謝の表明
製品の品質向上だけでなく、チームの一体感を高めるため、バグバッシュを実施後に振り返る会をすることは大切です。とくにバグバッシュの参加者に感謝を伝えることは、今後バグバッシュを続ける上で重要になります。積極的にフィードバックを提供した人や有益な発見をした人を表彰するなどもイベント感があってよいですね。
※5、6については、バグバッシュと同日にすることもありますが、開催規模が大きい場合は、別日にすることをお勧めします。
ログラスではどうしているか
ログラスでは、実施するタイミングは大きめな機能リリース時やライブラリバージョン時に実施することが多いです。以下のテンプレートでバグバッシュのアジェンダを設計しています。
大きめな機能リリース時は、カスタマーサクセスチームのメンバーを巻き込んで実施だり、ライブラリバージョン時は開発チーム全体で実施しています。思わぬ問題を事前に発見することができたり、関係者がリリース対象に理解を深めることができ、一定の効果はある感覚です。
まとめ
この記事を通して、バグバッシュの概念、目的、実施方法を紹介しました。
バグバッシュは、単に問題を見つける活動ではなく、関係者がプロダクトを深く理解し、さらに良くするためのエキサイティングなテスト活動だと私は考えています。
この記事を参考にしていただき、
バグバッシュを最大限活用するため、目的の明確化、組織全体の巻き込み、入念な準備、フィードバックの活用と感謝を大切して、よきバグバッシュライフを!!
Discussion