テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



クリスマススペシャル モブテストのやり方

f:id:m_training:20181222195605p:plain

f:id:m_training:20181222195600p:plain

f:id:m_training:20181222195555p:plain

クリスマススペシャル モブテストのやり方

 

この記事は「ソフトウェアテスト Advent Calendar 2018」の 22日目記事です。

21日目の@acha_821さんからバトンを受け取りました!

 

 

モブテストのやり方

みなさんは「モブテスト」というテストの手法をご存知でしょうか?

www.slideshare.net

 

乱暴に概要を書いてしまうと、

みんなで集まって、同じ場所で、同じパソコンを使って、みんなで探索的テストをするやり方です。

 

1人がパソコンを操作する人(ドライバー)になり、周りの人が指示を出す人(ナビゲーター)になり「あーしたらこうなると思うけど、どうなる?」「こうしたらどうなる?」と指示を出しながら探索的テスト(探索的テストと書いたけれど、ad-hoc感も強いかもしれない)を進めていきます。

 

マンガに描いたように、一人がゲームコントローラーを持ち、他の人の話を聞いて進める、といった形に近い気がします。

 

 

役割

ドライバー

実際にパソコン(デバイス)を操作する人です。

メンバーの中の1人だけがドライバーになります。

ドライバーは基本的には「No thinking」です。

ナビゲーターの指示を解釈して、それを行動にします。

 

ナビゲーター

指示を出す人です。

他の役割を用意していないのでしたらドライバー以外はナビゲーターになるかと思います。

指示は細かくてもいいと思いますが、先に挙げた資料7Pによると「Highest level of abstraction. Intent/Location/Details(意図、場所、詳細について最大の抽象化)」のようです。

 

ナビゲーターの抽象化された思考を、ドライバーの解釈で具現化することによって、ひらめきや新しいテスト観点が生まれる……かもしれません。

 

進め方

1. 事前準備

まずはテスト対象の仕様把握は必要です。

どんな動きをするのか、ということを知っておかないと、モブテスト実行の場で行うべき確認が浮かばずただ立っているだけのカカシになってしまいます。

 

マンガにも書きましたがファシリテーターも必要です。

要は全体まとめ役です。マンガならりんちゃんの役割ですね(笑)

 

2.開始時

実際にモブテストの時間になって、みんなが集まったら、まずはファシリテーターがテスト対象の概要説明、今回のテストの目的を話しましょう。

その後、ドライバーを決めましょう。

ドライバー以外の人はナビゲーターです。

 

作者たちがはじめモブテストをした時には書記の役割も決めましたが、実際テストを行うと書いている暇がないほど話が飛ぶし、書いている人はナビゲートできない…となりました。

で。

「PCでマイクをONにして、画面録画すればいいのでは?」という意見が出たので採用しました。

もし書記をするならば、問題が出たときに簡単に書いておく、が良いかもしれません。

 

3. テスト開始

モブテストを行います。

資料を見ると時間は4分。短いと思う場合は伸ばしてもよいかと思います。

実際にやった感覚ですと、集中して一気にテストするので疲れますし、長ければ集中力も持ちませんし、ちょうどよい時間だったと思います。

 

4.振り返り

テスト実行が終わった後は簡単に振り返りましょう。

どんな問題が起きたのか

それらから考えられることは何か

他気がかりな場所があるか……

そのようなことを話して、次のテストの方針を決めましょう。

 

この後は3~4を繰り返すことになります。

何回繰り返すかはチームやテスト対象の規模次第ですが、1時間も行えば結構な意見や問題点は拾えるかと思います。

 

モブテストのメリット・デメリット

メリット

メリットとしては、ナレッジ共有が挙げられます。

探索的テストのナレッジは各々が経験でため込んでいますが、実際にみんなと一緒にテストを行うことでそれらを他のメンバーに伝えることができます。

作者たちの実施時は各々が持っている、「言うほどではないと思っているけど実は便利な小ワザ」を見ることができました。

 

あと、メンバーには例えば「入力系に強い」とか「このドメインは任せろ」みたいな人がいます。

そういった人たちの力を合わせることによって、1人でやっているときよりもより高い効果が生み出せる……かもしれない、ということがあります。

参加メンバーに企画・開発の人を入れるとより観点やナレッジの幅が広がるかと思います。(次回は是非試してみたいと思っていますw)

 

それとモブテストは「チームビルディング」にも良いと作者は考えます。

「誰々さんはそういうことを考えてテストをしているんだ…」といったメンバーを知るきっかけにもなりそうです。

 

デメリット

人をそろえないといけないので、会議室の確保とスケジュールの確保でしょうか(^-^;

みんなが動けるタイミングを見つけなければいけませんので、忙しい人が多い現場でスト大変かもしれません><

 

作者が所属するチームは全員が探索的テストが得意なのですが、この場合、個人で行った方がバグが見つかる可能性があるかもしれない……そんな考えも浮かびました。

 

 

まとめ

モブテストは、特にスゴイ技術が隠されているわけではなく、みんなで集まって知恵を出し合えばより良いテストができるよね、といった手法です。

準備も場所とスケジュールの確保ができればそこまで大変ではありません。

お手軽にできる手法の一つと言えるでしょう。

みなさんも是非現場で試してみたらいかがでしょうか。

きっと新しい発見がありますよ(^-^)

 

23日目のアドベントカレンダーソフトウェアテストと言ったらこの人!@YasuharuNishi さんです!

私も毎度毎度学ばせていただいておりますmm

 

勉強させていただいた資料

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

www.slideshare.net

www.slideshare.net