テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

モブテストをやってみたよ

最近わたしの流行りのテストランチ
毎週思いついたまま、思いつかないときはだらだらと続けています。

今回はモブテスト( mob testing )

モブっていいですよね

モブテストってなんですか？

モブプログラミングのテスト版です。
といってもよくわかっていないので、海外のスライドを何となく読んだり読んでなかったりしながら
「みんな知らないからとりあえずやってみよう。体験してみよう」と思ってチャレンジしました

今回の目的

  • モブテストというのを参加者全員で体験する
  • 参加者のナレッジを共有する
  • わたしのテスト脳を共有してもらう

参加者

9名いました。
エンジニア2名、マーケティングチーム3名、CS兼テスト1名、サポート兼テスト1名とわたし（テスト）です。

やりかた

  • みんなで同じPC、モニター（プロジェクター）、場所でおこないます。
  • テスト実行⇔ふりかえり　をおこないます。
  • 実際に操作するドライバーは1名です。
  • どういうテストをするかを指示するナビゲーターはドライバー以外の人です。

今回は時間に対して人数が多いこともあり、1人を書記（やりとりやIssueに書く内容などをメモる人）というロール（役割）を作りました。

特別ルール　書記

モブテストに書記というロールは特に出てこないと思うのですが、
以前ペアテストについての事例発表で書記というロール使ってるて言ってたなぁと思って入れてみました。 http://jasst.jp/symposium/jasst15hokkaido/pdf/S3-1-3b.pdf
http://jasst.jp/symposium/jasst15hokkaido/pdf/S3-1-3.pdf

これは、のちほどIssue起こすときにとっても助かりました！

ドライバー

今回1回目も2回目もわたしがおこないました。

タイムスケジュール

公開されているSlideShareを参考にしつつ、そもそも1時間しかないお昼休みにやりたかったので 無理矢理スケジュールを作成しました。

また、テストはふりかえりを活かすために複数回することを必須としました。

12:00 - 12:30 ご飯＆モブテストについての説明＆今日のテストアイテムについての説明
12:30 - 12:34 モブテスト1回目
12:34 - 12:40 ふりかえり1回目
12:40 - 12:44 モブテスト2回目
12:44 - 12:50 ふりかえり2回目
12:50 - 片づけ

複数回するっていうのは、昔 kyon_mm さんに 福岡でやってもらった勉強会で教えてもらって、取り入れました。

atnd.org

テスト対象

エンジニア、マーケティングチーム、CSまで色んな方が参加してくれたこともあったので、 わたしたちの会社で作っているサービスの１画面を対象としました。
わたしたちも使っているシステムなので、サービスについての説明はしなくてもOKでした。

やってみたふりかえり

成果

バグが1件、Issueに書いた内容が7件ほどありました。
8分＋αの時間でこれだけ出せるのは効果が高いと思いました。

ドライバーをしてみて

「私のテスト脳を共有する」を掲げていたので、手と口をなるべく動かしつつテストしました。 * 今から何を入力するか

はあまり言えないときもありましたが、自分が思っていたよりかなりのことを伝えられたと思います。

一例ですが、スラッシュ区切りのデートピッカーがあった場合
「テキストでスラッシュ以外やスラッシュなしで日付が入れられるか」というナビゲートがありました。
ここで私が話した話

「まず区切り文字なしで入力します。20180131とかですね。（ここではこれは日付として認識できないだろうからそのまま登録できることはないと予測）
　デートピッカーのテキストエリアにコピペではりつけます。
　あ、自動補完でスラッシュが入りました。この場合はそのまま登録できるのでテストOKとします」←区切り文字なしのテストおわり

「次にスラッシュではないものを入れます。これは例えばPostgreSQLなどで使われているハイフン区切りを入れてみます。2018-0-31とかですね。
　デートピッカーのテキストに貼ってみます。あ、これだとハイフンのままですね。
　そのまま登録してみます。登録できちゃいました。（一覧画面が表示される）
　では、もう一度このデータの編集を見てみます。先ほどの値がスラッシュ区切りで表示されているので、私はこれはOKとします」←スラッシュ区切り以外のテストおわり

「どういうことかというと、ハイフンでも日付として認識できて登録できれば登録としてはOKと私は判断します。
　でも、他のデータと表示が違ってしまうと他に影響があるかもしれないので、編集画面をみてみて、表示にも影響がない（他と同じスラッシュ区切りになっていること）を確認しました」

*1

  • テストの実施
  • 入れる理由を話す
  • OKと判断する根拠、そうではない根拠を話す
  • なぜIssueに書くか、書かない理由を話す

などを話しました。いつもテストでやっていることなんですけど、これ話しながらやってみると、自分てここまで考えながらやってんのね。とちょっとびっくりします。

よかったこと

  • 1つの指示で芋づる式にテストがでてくる

モブテストのだいご味の１つだと思いますが、１つテストすると、それに関連して「あれは？」「これは？」というものがでてきました。

  • みんなで楽しんでテストができる
  • 当初の目的は達成できたかも
  • 短時間の実行なのにIssueに書くようなことがでてきた

うまくいかなかったこと / カイゼンしたいところ

  • ふりかえり時間中もテストの話になっちゃう

ドライバーのテストはしていませんが、ふりかえり中もテストの話（あれやったらどうする？みたいな）が続いてしまったので
もっとメリハリつけた方がよかったのかもしれません。

というか、ふりかえりで話すものをもっと限定してしまってもいいかもしれない（ふんわり、次のテストに向けてカイゼンした方がいいことって言ってしまったので） ここは、他の資料も読みつつカイゼンしたいところ

  • Issueの書き方も別に共有したい 　後ろに書いていますが、わたしがIssueを書くときに気をつけていることが色々とあるんですが、この流れでそこまでお伝えできたら
    　共有という意味では理解しやすかっただろうなぁと思います（モブテストとは離れちゃうけど）
    　2回目テストを入れずにふりかえりでそれをやってみてもいいかもしれません。いいのかな

想定外の発見

  • 社内共有ツールと併用できる

普段ちっこい気づきはできるだけ社内共有システム（Tamel）に書くようにしているのですが、今回の時間で
「あ、これ詳しくはTamelに書いてるから」ということが３～４個ありました。社内共有ツール大事。書いててよかった。社内共有ツール。

ただ、書いていても使いどころや、そもそもそんな記事があるって当事者にならないとわからないので、それが短時間に４つも既知の情報を共有できてよかった♡

  • Issueに書く内容や時間も省略できるかもしれない

このあと出てきた内容をサービスプロダクトのIssueに書いたんですが、Issue書くだけで1時間以上かかっちゃったんですね。
Issueは出来事だけを書くわけじゃなく、エビデンスや、どうすべきかを知ってるかぎりのコンテキストも考えつつ
最適解を自分なりに考えて書いています。
今回はサービス担当のエンジニアが参加していなかったのですが、担当エンジニアが参加していたら、考える部分もモブテスト中に解決できるかもしれないので
Issueを書く時間が短縮できるかもしれません。

  • 時間に対してのインプットとアウトプットの量が半端ない！ これ↑20分のできごとだからね！ほんとすごい。
    ただ、めちゃくちゃ疲れる！

これを実業務に入れようとすると、適切な頻度や範囲みたいのはあるかなーと思います。　マリオでいうスターとった時間みたいな感じ。

さて次回

すっごい疲れましたが、来週ももうテスト対象のサービスがリクエストきたのでやってみます。
次回はサービス担当エンジニアが参加してくれるので、また違った発見がありそう！Issue問題も解決するといいな：）

Twitterでは「#テストランチ」で水曜日くらいに呟いています。

これこうした方がいいよ。うちはこうしてるよ。とかあったらぜひ教えてください。時間配分とか。

参考にした資料など

教えてくださったみなさま、ありがとうございます♡

Slideshare https://www.slideshare.net/llewellynfalco/mob-testing-72610210

https://www.slideshare.net/maaretp/mob-testing

www.stickyminds.com

devtest.hatenablog.com

本・雑誌

WEB+DB PRESS vol.102「はじめてのペアプロモブプロ」

*1:・・・そういえば区切り文字でNGパターンやってないなぁ