Bugbashを導入してみた

こんにちは！アルダグラムでエンジニアをしているshige_sです

2024年から取り組み始めている「Bugbash」についてのご紹介をさせていただければと思います。

Bugbashとは

Bugbashとは、職種関係なくみんなでテスト対象をさわって「バグ出し」するイベントです。

弊社では、各開発チームで企画されている開発施策に対して、Bugbashを行っています。

昨年までのQAフロー

Bugbashを企画・運用する前までのQAフロー

テスト工程	内容
テスト計画	・QA期間の見積もりやテスト対象の範囲の選定など
テスト設計	・テスト観点の洗い出し
	・テスト技法を用いたテスト項目書の作成
テスト実行	・テスト項目書に基づいたテスト実施
	・項目外の探索的テスト
	・不具合報告及び修正確認
リリース判定テスト	・リリース前のリグレッションテスト実施

もちろん、上記でも大きな課題はなかったのですが、

開発チーム内で新しく実装された機能に対してフィードバックを行うタイミングが職種によって異なっていました。

UI・UXに関するフィードバックが場合によってはテスト実行フェーズの後半で見つかることもあり、その際にはリリース日の再検討など、難しい舵取りをしないといけない場面も発生してしまいます。

そこでQAユニットでは、今年「Bugbash」を導入しました。

運用についてご説明します。

---

対象機能

• 開発期間の取り決めはないですが、概ね1ヶ月以上の期間を費やしている中規模以上の開発施策を対象としています。

開催タイミング

• 実装担当者がQAエンジニアにテスト実行依頼を行い、QAエンジニアが対象機能をウォークスルーで確認し、致命的な不具合がなければ、Bugbashを開催します。

参加メンバー

• 下記の各職種のメンバーを招待しています。
  • 開発チーム内のエンジニア
  • 対象機能の仕様策定にあたったPdM
  • 対象機能のデザインを行なったデザイナー
  • QAチーム内の全QAエンジニア

テストデータ準備

• テストアカウントやBugbashの時間内で準備するのが大変なデータについてはQAエンジニアが事前に準備しています。

開催時間

• 1時間

---

テスト実行フェーズに入った段階でBugbashを開催しますが、致命的な不具合があると、せっかく集まってもらったのに、基本的な操作ができないため有意義なBugbashとならない可能性が高くなります。QAエンジニア側で開催しても問題ない品質であることを確認してから参加者には周知しています。

テストデータの準備については、あまり事前に作り込みすぎると、各自のテスト操作の柔軟性が損なわれてしまうので、塩梅は難しいですが、本来触ってみたいところにしっかり時間が取れるようにしています。

他社事例では、Bugbashに1時間以上充てているケースも見受けられたのですが、弊社では基本的に1時間を設定しています。今のところ、みなさん集中力高く、フィードバックもたくさんいただけているので、ちょうど良い時間設定なのかなと思っています。

Bugbashを取り入れたQAフロー

テスト工程	内容
テスト計画	・QA期間の見積もりやテスト対象の範囲の選定など
テスト設計	・テスト観点の洗い出し
	・テスト技法を用いたテスト項目書の作成
Bugbash	・みんなでいっぱいフィードバックを出し合う！！
テスト実行	・テスト項目書に基づいたテスト実施
	・項目外の探索的テスト
	・不具合報告及び修正確認
リリース判定テスト	・リリース前のリグレッションテスト実施

直近でリリースした新機能（オフライン対応など）で開催し、

• 自分以外のメンバーのフィードバックを読んで、新しい観点でのテストを知ることができた。
• フィードバックを通して、仕様の再検討などに時間を割くことができた。
• 各関係者が同じ場所に集まることで効率的なコミュニケーションを図ることができた。

などの評価を頂けています。

まとめ

今後の課題としては、

• 各関係者に操作方法を委ねてしまっているので、グループ毎にテストシナリオを用意して実運用を想定した操作をする
• オフラインでイベントを開催し、より活発的なイベントにしていく

などイベントの運用面で改善点があるので、よりブラッシュアップし、QA文化として根付かせられたらと考えています。

もっとアルダグラムエンジニア組織を知りたい人、ぜひ下記の情報をチェックしてみてください！