テスト設計勉強会でモブテスト設計をやってみた
はじめに
こんにちは。SHIFTのQAエンジニア、小倉です。
今年2022年8月にSHIFTに入社しました。
在宅勤務で体重が増えてびっくりしています。
脳の運動はしているんですが、体も動かさないとダメですね。
そんな脳の運動の1つとして、テスト設計技法に関する勉強会に参加し、知識を整理、学習する機会を得ることができました。
その中で自律的に実施したモブテスト設計に思いのほかメリットを感じたので紹介します！
｜モブテスト設計を取り入れた経緯
私が参加した勉強会は、テスト設計の例題を参加者それぞれで解き、時間が終わるごとに集まって答え合わせをしながら疑問点を解消する、といった方法でテスト設計技法を身に着けよう！という趣旨で行われました。
最初は知らない手法等を覚えることができ、ある程度の会話もあったのですが、途中から例題を解くだけではマンネリ化してしまいました。 そして、このままでいいのか……？と疑問を持つようになりました。
私が感じていたマンネリ化の原因は以下の3つです。
実行環境やツール、時間の都合で答え合わせのタイミングまでに最後まで解ききれない
問題を解いても答えのチェックだけで終わってしまい広がりが薄い
設定そのものに疑問があっても答え合わせの時間ではなかなか言い出せない
これらを打開する手段として、参加者の1人の発案でモブテスト設計を取り入れました。
｜そもそもモブXXとは？
「モブ」の意味は「群衆」という意味で、沢山の人のことを指します。
ソフトウェア開発界隈で使われる場合には、賑やかしというよりも、「チームで」という意味に近い形で使われていることのほうが多いと思います。
エクストリームプログラミングのプラクティス（技法）に、「モブ」と「プログラミング」を組み合わせた「モブプログラミング」というものがあります。
みんなで集まる。
1人がキーボードとマウスを操作するドライバー役になる。
他のみんなは指示をするナビゲーター役になる。
ナビゲーターが指示をしたり、議論をしたりしながら、ドライバーにコードを書いてもらう。基本的にドライバー役の人はドライバーに徹する。
ドライバーの人はたまに交代する。
元ドライバーはナビゲーターとして思った疑問点や議論に参加する（問題の蒸し返しはしてもよい）。
似たようなプラクティスに、ペアプログラミングと呼ばれるものがありますが、こちらは2人でやるものなので、それを「モブ」に広げたものです。「モブ」は「設計」にまで広がっており、それをさらに「テスト設計」まで広げたのが今回の取り組みです。
｜今回のモブテスト設計のやり方
SHIFTではテレワークを進めていることもあり、今回は全員が遠隔地にいる状態でした。以下のような進め方で実施しました。
音声チャットを使用して、やりとりは基本的に口頭で実施する。
ドライバの人は画面共有をONにしてもらう。
問題ごとにドライバを固定する。
通常のモブXXでは、頻繁（10～30分くらい）にドライバを交代するのがセオリーですが、ツールの使用が前提の問題は、環境・途中の状況を共有の制約のためにドライバは問題ごとに交代という形をとりました。
｜モブテスト設計で起きたこと
勉強会で取り上げた問題の中で複雑な問題をモブテスト設計で解いてみました。すると、設計中に以下のようなことが起きました。
問題文を読み上げた直後に問題文に突っ込みが入り、疑問点が明らかになる。
ツールの疑問点を皆で調べて共有するため、1人でやった時よりもスムーズに問題を解くことができる。
これでいいのかな？が自然に言葉として発せられ正しいテスト設計を導くことができる。
問題を解きながら＆解いた後、他のシチュエーションや実際の業務想定での議論が交わされる。
「勉強会」の目的は「参加者全員」が「この問題（テスト設計）を通じ」て「テスト設計技法を学ぶこと」、「実務で考慮しなければならないことを意見交換すること」でした。
そして、モブテスト設計を導入することによって、参加者がその場で疑問が解消でき、かつ意見交換もただ単に解いたものを持ち寄った時より活発に行うことができました。
解答を互いに確認するだけでは、生まれなかったコラボレーション（議論）が生まれたことが最も良い影響だと思います。
｜1人でテスト設計をしていた時との違いって何だろう？
1人のときにもテスト設計の後、テスト設計の結果を皆と共有はしていました。しかし、あまり議論は広がりませんでした。「モブ」で実施することと1人1人が解き、その結果を持ち寄ることの違いは何でしょうか。
私は、テスト設計の成果物がチームの持ち物になるという感覚の強さだと思います。1人でテスト設計をしていた時には、その人個人の成果物であるという感覚が強く、
何か指摘するときには言い方にも気を付けないといけない
他の人は疑問に思っていないかもしれない
流れを止めてはいけない
のようなことを考えなければなりませんでした。
モブテスト設計をすると必ずドライバーの人に指示を出します。
その指示のタイミングで話したいこと（疑問・質問）を混ぜることができるため、確認や指摘のハードルをちょっとだけ下げてくれます。例えば、
「ここの境界値はAとBを書いて欲しい。ところで、Cって入るのかな？」
「問題文のこの部分に書いてある通りにテストパターンを考えればいいんだと思うんだけど、あってる？」
のような感じです。（実際に実施したときにはもう少し固い言い方になっていましたが、雰囲気は伝わると思います）
例え（結果的に）間違ったことを言ったとしても議論が深まってその間違いはないことを皆で確認しながら進めることができます。
個人的に、強制的に（でも安心して）対話をできる仕組みが“モブ”の最大の良いところであると感じました。
｜最後に
モブテスト設計は私自身がまず楽しかったこともあり、現場作業でも機会があれば使ってみたい！と思いました。 それと同時に、全員の予定を合わせる必要がある、時間がかかる等の制約や課題もあると思います。
私が考えるモブテスト設計が合うシチュエーションは以下のような場合だと思います。
プロジェクトが始まるときに既存メンバーと一緒に実施して、コミュニケーションと技術的疑問点の解消をする。
新人同士でやってもらい、課題の解決方法を学ぶ。
難しい課題をチームの集合知識で解決する。
特に実務で使う際には、他のモブXXと同様に作業時間の累積（時間×人数）に対する効率は下がってしまう可能性が高いです。
（この取り組みの後に読んだ「モブプログラミング（パール・マーク著）」にも記載があります。）
開発者レビューと同時進行的に進むこと、難しい課題を1人しか理解していないという事態を防ぐことによってテストの保守性・品質の向上（テスト対象の変更に伴う修正効率の上昇やレビューと並行して進めることによる誤り数の減少）により、結果的にトータルの累積時間が減る可能性もあります。こうしたことから、ある程度人数を絞って実施すれば効率よくモブXXを実務で使用することができるのではないか、と考えています。
ただし、それでも単純で全員が苦も無く取り組めるテスト設計であれば、個々でやったほうが良いというのは頭に入れておく必要があります。
今回の取り組みが上手くいったのは以下の3つが偶然にも条件として重なっていたことによるのではないかと考えています。
参加者が合意して実施したこと。
実験的なものだと全員が把握していたこと。
モブテスト設計の時間は参加者の後入り自由になっていたこと。
実務の場合には難しい1つの問題を解決するため、作業を止めないためなど、目的にあっているかを考え、使いどころを間違えないようにしないといけません。
このあたりは、勉強会の振り返りの際に他の方も言っていました。 ただ、モブテスト設計のようなプラクティスは選択できる手札だと考えています。
ツールに振り回されないで、手札として持っている人を増やすべくモブテスト設計の輪を広げていきたいと思います。
SHIFTの技術ブログにも、テスト技法についてまとめた記事があります。こういったブログを見ながら、皆さんもモブテスト設計にチャレンジしてみてはいかがでしょうか。
｜メリット/デメリットまとめ
モブテストのメリット・デメリットをまとめてみました。宜しければ参考にしてください。
メリット
複雑なパターンを導出する効率が上がる（1つの問題を解消する速度は上がる）
複雑なテスト対象を全員が同じレベルで理解できる
開発者レビューと同時進行しているような安心感が得られる
デメリット
全員の予定を合わせる必要がある
単純な問題には向いていない
累積時間が増加する可能性がある（一時的に人×時間が増える可能性がある。ただし、レビュー等を含めると減る可能性もある）
執筆者プロフィール：小倉 大介
2022年8月、中途採用でSHIFTに入社。前職はソフトウェア開発チームで設計、コーディング、試験を一通りやったり、プロジェクト部門として動いたりしていました。
SHIFTでは今までとは全く違うドメインを相手に、楽しみながら格闘しています。 スウィングロールなソフトウェアエンジニアになるため、PSMの資格を取得したり、ドメイン知識をつけたりと勉強中です。
直近の悩みは、技術ブログの書き出しの名乗り出し。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/