この記事はベリサーブ Advent Calendar 2023の24日目です。前日の記事はこちらです。

最近、自分が所属しているチームでは、ユーザーストーリーの受け入れテストをモブテストで実施しています。モブテストのやり方を改善しながら半年ほど継続してきて、効率よく受け入れテストをできるようになったと感じています。そこで、自分のチームでのモブテストのやり方や、良い点、実際にやりながら改善してきた点などをご紹介します。

モブテストとは

モブワークの一種で、テストを複数人で行うやり方です。何人か集まって、探索的テストをみんなで実施するというものです。

複数人でテスト設計やテスト観点出しを行うこともありますが、「モブテスト」と言うと複数人でテスト実行することを指すことが多いように思います。ただし、複数人で探索的テストを実施していると考えると、その場でテスト設計しながらテスト実行していると言えそうです。

モブテストをやろうと思ったきっかけ

チームに新しいQA担当者が配属になり、テスト対象の仕様に関する知識やテストの実施のノウハウをチーム全体で共有できたら良いと思い、モブテストを取り入れようと考えました。

あとは単純に、面白そうだと思ったからです。自分はモブテストを今までやったことが無かったので、どんな感じなのか興味がありましたし、せっかく人が増えたのでみんなでモブテストをしたら楽しそうだと思ったのです。

モブテストの指針など

モブテストをチームで取り入れるにあたって、まずはいくつかの記事を調べて、モブテストをやる目的、モブテストの指針、参加者の役割、進め方をドキュメントとして整理しました。調べた記事についてはこのページの最後にリンクを掲載していますので、そちらをご参照ください。

以下は実際に作ったドキュメントからの抜粋です。調べた記事の中から大事そうな情報を引用しつつ、整理したものです。英語の記事を直訳している部分など少し分かりにくい部分もありますが、そこは温かい目で見てください。

モブテストをやる目的

モブテストの目的は、さまざまな視点や洞察を集めて活用することでソフトウェアの品質を向上させることです。もちろん、誰もが独自の専門知識を持っており、グループとして協力することで、問題をより迅速に特定して解決することができます。
モブテストはチームメンバー間のコミュニケーションを改善するのにも役立ち、コラボレーションの向上につながります。したがって、このテスト手法は、部門横断的なチームやDevOps チームと連携する場合にうまく機能します。

モブテストの指針

セッションは 1.5 時間を超えないようにしましょう。それ以上になる場合は休憩を入れましょう
参加者全員に対して、親切、思いやり、敬意を払うことを忘れないでください
全員の声を積極的に聞き、チーム一丸となりましょう
タイマーに従って、全員が順番に一定時間、キーボード/マウス/デバイスを操作しましょう
このアプローチは、強力なスタイルのナビゲーションに従っており、ドライバーはアプリ/システム上のアクションの背後に自分の思考プロセスを置くことはできません。代わりに、ドライバーのアクションは、ナビゲーターからの指示によってガイドされます

参加者の役割

ファシリテーター
- モブテスト全体の進行やタイムキープを行う。事前に１名決めておく。
ドライバー
- 実際にパソコンを操作する人
- メンバーの中で1人だけドライバーを務める
- ドライバーは「No thinking」。ナビゲーターの指示に従って手を動かす。
ナビゲーター
- ドライバーに指示を出す人（こういうことやってみよう、とか、ここをこうしたらどうなるかな、とか言う）
- 指示はあまり細かくしすぎないほうが良いっぽい
記録係はいてもいいかも？ただし、必須ではなさそう

進め方

ファシリテーターを決める
テスト対象やテストの目的を全員で確認しあう
- テスト対象に詳しくないメンバーがいる場合、仕様の説明や把握をする時間を取ると良い
ドライバーとナビゲーターを決めて、1回あたり4分間くらいテストを実施する
- ナビゲーターが指示を出して、ドライバーがそれに従って実際にPCを操作する
- ナビゲーターの指示は細かすぎないほうが良い（ドライバーに行先を伝えて運転は任せる、みたいなイメージ）
- なぜ4分なのかは分からないが、短い時間で頻繁にドライバーを交代するのが良いらしい
- 実際にテストして見つけたバグや気になった動作などは簡単にメモっておく
ふりかえりを実施する
- ふりかえりの実施のタイミングは以下のように色々なパターンがある
  - 1回のテスト実行とふりかえりを繰り返す（1回あたり、合わせて10分くらい）パターン
  - 何回かテスト実行を行って、最後にふりかえりの時間を長めに（30分とか）とるパターン

自分のチームでのモブテストのやり方

実際にモブテストを行う際は、Miroにモブテスト用のボードを作って、見つけたバグや気づきをメモったり、ふりかえりの付箋を貼ったり、タイマーをかけたりしています。Miro、便利。

イントロとふりかえりの部分を拡大すると、以下のようになっています。

全員がオフィスに集まって対面で実施したこともありますが、最近はTeamsのオンライン会議で実施することがほとんどです。ドライバー役の人がTeamsで画面共有し、その画面を見ながら他の参加者がナビゲーターとして指示しています。

自分のチームでは、3人か2人で実施しています。3人の場合は、1人がドライバー、1人がナビゲーター、1人がナビゲーター兼記録係兼タイムキーパーをしています。2人の場合は、1人がドライバー、1人がナビゲーター兼記録係兼タイムキーパーをしています。バグや気づきがあった際は、主に記録係がMiroに付箋で現象の概要を書いたり、画面のスクリーンショットを貼ったりします。

時間は全体では1回につき1時間～1.5時間取っており、テストの実施は4分～6分程度ずつにしています。Miroでタイマーをかけて、時間になったらキリのいいところでドライバー役を交代します。全体の中の最後の15分くらいはふりかえりの時間にしています。最近は、これを週2回～3回実施しています。

改善してきた点

最初から上に記載したやり方やMiroボードだったわけではなく、やりながら改善してきました。改善してきた点のいくつかをご紹介します。

オンラインでの実施：対面とオンラインの両方試した結果、オンラインで実施するようになりました。対面でやった際の環境づくりが良くなかっただけかもしれませんが、全員で見るモニターが見づらかったり、タイマーの音に気付きにくかったりして、オンラインのほうがやりやすく感じたためです。
バグや気づきの記録：バグ管理ツールがあるので最初はそちらに記録していたのですが、モブテスト中の記録はMiroで付箋に書いて置いておくのが一番手軽で良い、ということになりました。バグ登録が必要なものは、モブテストが終わったあとでツールに登録しています。
バグや気づきのふりかえり：最初のうち、探索的テストの実施中にバグや気になったことがあった際に、その深堀や原因調査をしはじめて、交代時間になってしまうことがありました。そこで、調査が長くなりそうな場合はとりあえずMiroに記録だけしておいて、最後のふりかえりの前に再度見直して調査する時間を取るようにしました。その対象がどれか分かるように、専用の置き場所をMiroに作りました。上図の「バグや気づき（あとで確認するもの）」がそれです。
役割：最初は記録係は特に決めていませんでしたが、誰が記録するか決まっていないとあたふたすることがあったので、決めるようにしました。また、タイマーをかけ忘れることが多かったためタイマーをかける役割も決めようということになり、記録係の人がタイマーをかけることにしました。
役割を忘れないようにする工夫：3人でモブテストを実施していると、「あれ、次は誰がドライバーだったっけ？誰が記録係だっけ？」となることが多かったので、Miroにそのときの役割を表示する付箋を作って、交代するときに動かすようにしました。動かす向きも矢印で明確にしました。
タイマーの長さ（1回のテスト実施の長さ）：最初は調べた通りに4分でやり始め、10分にしてみたり、少し時間を調整してきましたが、テンポよく交代できるのは5分前後だと感じました。現在は、テスト対象を実際に触る前のユーザーストーリーを読み直す時間も含めて、6分でタイマーをかけています。タイマーの長さはまた変わるかもしれません。

モブテストの良い点

自分が感じている良い点や、ふりかえりで出た意見を以下に記載します。

テスト実施の時間が最初は短く感じたが、慣れるとテンポよく1機能を触ることができて、小気味いい。
自分で気づけない視点にも気づけるので、今後、1人でテストするときにも活かせる。
複数のアカウントが必要なテストや、過去に作ったデータを使うテストなど、1人でやるより効率的にできる（他のユーザーを招待する機能のテストでお互いのアカウントで招待しあったり、過去に作ったデータを誰かが持っていたらそれを使うことができる）。
テスト対象の仕様に詳しくない人は仕様の学びになる。普段1人ではあまりやらない操作や、知らない仕様、忘れている仕様も、モブテストだとテストできる。
1人でテストしているときに気付かないバグを見つけることができる。視点が多様になるというのもあるし、1人で操作していると操作している部分に意識がいきがちだが、見ている人はそれ以外の部分も見ていて、おかしい動作や表示に気付くことができる。
テストの内容を書き出して、その内容を他の人にレビューしてもらうという時間が減るので、全体として効率が良くなる。モブテストでは、その場でテスト設計とレビューも行っている感じ。
バグの内容を別途共有する手間が減る。その場で実際に挙動を見ることができるので、あとでバグ登録された文章などから想像するより理解が早い。バグの修正確認をするときにも、全員同じ内容を把握しているので、どんなテストをしたら良いか早く考えられる。

おわりに

上記のように改善しながらモブテストを継続してきたことで、効率よく受け入れテストをできているように感じています。細かい点として、以下のような課題もありますので、今後さらなら改善についてチームで話し合いつつ、モブテストを継続していこうと思います。

画面共有だと、一瞬表示されるような挙動が映らないことがあり、ドライバー以外の人が気付けない　→　ドライバーが意識して、気付いたら発言するようにする。
ドライバーが勝手に動きがち　→　ドライバーがベテランの場合はこれもありかもしれない。何をしようとしているか、なぜそれをやろうと思ったかなどを発言しながらやると、他の人の学びになって良さそう。
1台のPCではなく各自のPCで画面を操作する形にしているため、あるテストの準備のために作成したデータを、次のドライバーに引き継ぐのが難しい　→　みんながアクセスできる場所にデータを置いて引き継ぐ。
ドライバーの手元の動きが見えず、特にキーボードの操作は何をやっているか他の人は分かりにくい　→　ドライバーがやっている操作を声に出すようにする。

モブテストの参考記事

モブテストを取り入れるにあたって参考にした記事は以下です。