「テスターちゃん」で学ぶソフトウェアテスト⑦

「Qiitaに書いてた記事をnoteに移行しよう」シリーズと言うことで、Qiitaに投稿している記事の掘り起こしとなります。また、内容の整理も行う予定のため、Qiitaに投稿した記事をそのまま移行する形とならない場合もあります。ご了承ください。

■Archives

「テスターちゃん」で学ぶソフトウェアテスト①

「テスターちゃん」で学ぶソフトウェアテスト②

「テスターちゃん」で学ぶソフトウェアテスト③

「テスターちゃん」で学ぶソフトウェアテスト④

「テスターちゃん」で学ぶソフトウェアテスト⑤

「テスターちゃん」で学ぶソフトウェアテスト⑥

■モブテストのやり方

・モブテストって何？

①一つの場所に集まって、
②一つの画面を見ながら、
③みんなで探索テストをする

手法である。

一人がデバイスを操作する人、他の人がどう言うテストをするか指示を出す人になって、テストを進める。

・役割

ドライバー
・操作する人のこと。
・基本的に「No thinking」。
・他の人の指示で手を動かす。
　→ナビゲーターの指示を解釈して、それを実行に移す。

ナビゲーター
・ドライバー以外の人が担当する。
・ドライバーに指示を出す。

・モブテストの基本的なフロー

①事前準備
・ファシリテーターを決める。
・大きな画面がある部屋を確保する。
・仕様把握を行う。
　→いきなりやっても案が出ないこともあるので、あらかじめ把握しておくことが必要。

②開始
・今回の目的を伝える。
・ドライバーを決める。
・ナビゲーターを決める。

③モブテスト実行
・4～5分くらい。
・問題が出た時は簡単にメモしておく。

④振り返り
・5～10分くらい。
　→どんな問題が起きたのか。
　→それから考えられることはあるか。
　→他に気になる場所や点はあるか。
・しっかりファシリテートして次のテストに繋げることが大切。

⑤その後
・③と④を繰り返す。

補足

・指示は細かいより抽象化されている方がいいとのこと。
　→自分の考えが相手の解釈を通して出ていく時に新しい発見がある可能性がある。

・メリット

・テストのやり方や考え方を共有出来る。
　→みんないろんな知見を持っているが、それを他人に伝えることが少ないため。
　→企画者や開発者を交えてテストを行うと新しい観点が出て来るかもしれない。また、どんなテストをしているか直に伝わるし、不具合が出た時は直に伝えられる。
・それぞれの得意を合わせることで、よりよい結果を出せる可能性もある。

・デメリット

場所の確保と参加メンバーのスケジュールの調整。
→今はメンバー全員在宅…ならば場所は気にしなくてもいいかもしれない。

■モブテストや探索的テストについて

このシリーズで参照している「テスターちゃん」や他の書籍や他の方のブログ等の資料で取り上げられているモブテストや探索的テストについてですが、機会があればやってみたいのですが、個人的にはまだ経験がありません。

未経験者の感想ではありますが、ナビゲーターの“抽象化された指示”をドライバーに伝えることも大変そう(ちゃんと言葉に表せるかどうか)ですが、ドライバー側の”No thinking”も意外と大変だろうな、と思いました。
自分の意思で動かしてはいけないということだろうな、と認識したので。

もしモブテストをやる機会があったらドライバーもナビゲーターもどっちもやってみたいですね。