この記事は「弁護士ドットコム Advent Calendar 2023」の 10日目の記事です。 前日は @Casseroles さんの「Customer Reliability Engineeringとはなんだったのか」でした。 CREチームの歴史と、そのチャレンジの軌跡が分かる、読み応えのある記事でしたね。
こんにちは！ 弁護士ドットコム クラウドサイン事業本部でQAエンジニアをしている田中です。
クラウドサインには複数の開発チームがあり、私たちQAエンジニアは 普段の業務において、それぞれの開発チームに別れてQA活動を行っています。 そんな中で、孤独な作業になりがちな「テスト観点出し」の工程を、 開発エンジニアが行っている「モブプログラミング」という手法を取り入れて実施してみた話をします。
何故やろうと思ったか
自分に無いテスト観点をシェアしてもらいたい
個々の開発チームに分かれて活動している都合上、どうしても開発している機能や影響範囲の知見は属人的になっていきます。 この問題の解決手段の一つとして、モブテスト設計を活用してみようと思いました。 加えて、複数人が参加する事で、一人で考えるよりもテスト対象に対する思考を幅広く持つことができると考えました。
今回のモブテスト設計の内容
まずは対象となるプロジェクトを選定し、やりたいメンバーを募りました。 そして以下の役割とルールのもと実施しました。
プロジェクトの選定にあたっては、QAが開発とできるだけ並走していく為にも、 詳細な仕様が策定される前のフェーズにあるプロジェクトを選定しました。 尚、今回は全員がリモートワークでの参加です。
役割
ファシリテーター（1名）
- タイムスケジュール、進行の管理
ドライバー（1名）
- ナビゲーターの指示に従って観点を記入する
- 画面を共有する
ナビゲーター（2名）
- ナビゲーターは交互に観点を出していく
- ナビゲーター間で議論を行う、観点を具体的にドライバーに指示する
例：1周目（10分毎に交代）
- Aさん（ドライバー）Bさん（ナビゲーター）Cさん（ナビゲーター）
- Aさん（ナビゲーター）Bさん（ドライバー）Cさん（ナビゲーター）
- Aさん（ナビゲーター）Bさん（ナビゲーター）Cさん（ドライバー）
ルール
- タイムボックス:1.5時間
- 役割のローテーション:10分毎
- 1周目:ナビゲーターは議論を行わず、もくもく観点を出す
- 2周目:ナビゲーター間で議論OK、わいわい議論した上でドライバーに観点を伝える
- ドライバーは自身の意見を述べず、ナビゲーターに対して観点を誘導しない
- 一度記載された観点の要/不要は議論はしない
- 観点を出した当人からの申告があれば観点を削除してOK
- 発言する際は「単語」ではなく「文章」で（例:どこで、だれが、xx出来る事/xx出来ない事）
- 2周目が終わったら、残りの時間は不明点の解消の時間に充当する
感想戦
モブテスト設計を終え、うまく行かなかった事、 実施してみて感じたメリット/デメリットを参加者からヒアリングし、 いくつか抜粋して纏めました。
メリット
- 繰り返すことで中長期的にQAチーム内でテストの粒度が合わせられる
- 将来的にレビュー工数の削減に繋がるかもしれない
- QAの用語の統一を図れる可能性がある
- 1人では着想出来ない観点が圧倒的に多く抽出できる
- 議論をしながら得られる気付きもある
- 1人で観点出しを実施するよりも短時間で成果が得られる
- シニア→ジュニア、古参メンバー→新規メンバーへナレッジの伝播ができる
デメリット
- 短時間で成果が出る反面、参加者が複数名必要な為、従来のテスト設計より全体としては工数がかかってしまうので調整が必要
- 複雑度が高すぎる問題（大きな機能）には向いていない
- ある程度ドメイン知識が要求されるため、新規加入メンバーにはハードルが高い
うまく行かなかった事
- 他者の観点に引っ張られてしまって、類似する観点が続いてしまった（テストパターンを出してしまっている）
- 自分の頭で考えている観点を言語化して他者に伝える事の難しさを感じた
- 最後の方は観点が枯渇して長考する時間が増えた
- 事前のインプットをしっかりやっていれば良かった
結果どうだったのか
QAチームとして継続して取り組んでいくべきという結論です。
お互いが持っている機能固有の観点、仕様知識の交換が行われる事で、 今回課題として感じていた「別々の開発チームでQA活動をする事による知見の偏り」が一定解消され、 尚且つ、短時間で効率よく観点を得る事ができました。
また、当初の目的から外れるものの、副次的に気づいた事として以下の効果が得られそうです。
- 複数人がテスト観点を出す事により考慮の幅が広がり、最終的にはレビュー工数が削減できる（かも）
- 繰り返すことで中長期的にQAチーム内でテストの粒度が揃えられる
- 繰り返すことでQAチーム内で用いる用語が統一できる
一方で、うまく行かなかった事に関して、 事前の準備やルール決めで回避出来る問題でもあり、今後継続する中で改善していこうと思います。
尚、デメリットとして上がっていた「新規加入メンバーにはハードルが高い」 に関しては、「無理に観点を出そうとしなくても良い」など、 参加する際のスタンスの調整やメンバーのサポートがあれば、ある程度許容できるものと判断しました。
まとめ
当初期待していた効果を一定得られた反面、 実際に実施する中で幾つか課題も見つかっています。
- 現状、観点を列挙するだけで、構造化まで至っていない
- 事前の準備やルール設定に改善の余地がある
これらの課題については、今後モブテスト設計を継続実施していく中で、 改善ないしは解決できればと考えています。
個人的な感想として、今回ドライバー1名、ナビゲーター2名という設定で実施した為、 ローテーションするとはいえ、必然的にナビゲーターの負担が大きい状態でした。 しかしながら、限られた時間と情報の中で極限まで考え抜くという経験が出来て非常に有意義でした。
また参加者については、開発エンジニア、PdMなど、QA以外の職種を巻き込む事で、 より深く幅広い観点が創出される可能性があると感じました。（あくまでコストメリットが見合えば）
最後に、当初想定していた効果は、単発的に実施する事では得られないものであり、あくまで継続して実施し、 QAチーム内でモブテスト設計の文化を築いていく過程で得られるものであると思いました。 これらを踏まえ、メリット、デメリットを理解した上で、今後も継続して実施できたら良いなと思っています。
弁護士ドットコム Advent Calendar 2023の明日の担当は @naito1224さんの「弁護士ドットコムでやっている 本気音楽部について 」みたいです。
