※FlexFirmでは現在、アプリの運用に関するアンケートを実施しています。
ご協力いただけましたら幸いです。
アンケート（Googleフォームに遷移します）
ユーザーテストの事例をシェアします
Webアプリの開発やテストに関わる皆さん、こんにちはー！
今回、あるWebアプリで、クラウドソーシングを利用したユーザーテストを行ってみました。
クラウドソーシングのテストで品質を高められたのでシェアさせていただきますね。
まずはテストした、弊社のWebアプリの説明から。
Webレンタル
弊社では、アプリやサイトの検証用に、スマホやタブレットの実機を貸し出すサービスをしています。
その申し込みをWebから行うためのアプリケーションです。
※ちなみに、9/7 オープンしました！
こちらからどうぞ→ 実機レンタル Web申し込み
ユーザーテストを行った背景
なぜ、効果がでる保証もない、しかも面倒なユーザーテストを行うことにしたのか簡単に説明しておきます。
実はこの『Webレンタル』、その前身となるシステムを昨年 開発し、一部ユーザーにリリースしました。
そのときこんな体験をしたのです。
念を入れて運用メンバーと開発メンバーでテストし、不具合やユーザビリティの問題を修正。
しかし、最初のお客様がたった1回使っただけで、複数の問題を指摘されてしまったのです。
どれも「もっともです」と共感できるものだったのと同時に、こんな簡単なことに気が付けなかったことを恥ずかしく思いました。
お客様に呆れられたかもしれないとの悔いも残りました。
このときこう思いました。
「内部の人はユーザの視点を持てない」
それで、「次に開発するときは必ずユーザーテストをやろう！」と決めたわけです。
テスト準備
以下のような順番でユーザーテスト準備を進めました。
テスト方針決め
悩んだのはテスト対象にする機能です。
全体をカバーすると機種の検索、予約確定、到着、返却とシナリオ実施に数日かかってしまいます。
これは、テストのコストがかさむし、内部で行ったテストとの重複も多い。
そこでテスト範囲は以下のように設定しました。
・機種の検索から予約確定～機種の変更までの操作
見つけてもらう問題は以下のように設定しました。
・不具合などの機能的な問題
・ブラウザ依存の問題
・ユーザビリティの問題
テスターの募集は以下の様にしました。
・某大手クラウドソーシングサービスを利用
・テスターは30人前後
問題の報告の仕組みは、弊社サービス「あれれサーチ」https://arere.applihelp.comで用いている独自のシステム CTM（Crowd Test Manager)を使うことにしました。
（↓CTMはこんな感じ）
●テスト指示
クラウドソーシングサービスのコンソールから仕事依頼を作成し、以下のように指示を出しました。（※細かい部分は省略）
＜テスト対象の説明＞
スマートフォン向けに開発したサイトをテストするときに、特定の機種のスマートフォンが必要になることがあります。
そのスマートフォンの実機をレンタルするサービスを提供するWebアプリケーションがテストの対象となります。
＜想定シナリオ＞
あなたは、ある企業でスマートフォン向けにWebサイトの開発を行っています。そのサイトの動作をテストするために、手持ちのスマートフォンでは足りないので、外部の会社からレンタルすることにしました。
1. テストで使うパソコンとブラウザの確認をお願いします
パソコン：WindowsまたはMac
ブラウザ：IE 11、Firefox、 Safari、 Chromeのどれか
2. テスト対象のWebアプリケーションへアクセスしてください
https://xxxxx.flexfirm.jp/
3. テスト対象のタブに移動し、次のアカウントにてログインしてください メールアドレス：AAAAA パスワード：BBBBB
＜基本操作＞
来週の任意の日付から、再来週の任意の日付までの期間で、５から２０台をレンタルする申し込みを行ってください。
配送・受取指定：どれを選択してもOKです。
機種を探す条件は、お任せします。
以下にその条件の事例を挙げますでの、参考にしてください。
・６月以降に発売された機種・・・最低１機種
・Android２．３、４．０の機種・・・それぞれ最低1機種
・iOS6、OS7のiPhone・・・それぞれ最低1機種
・Xperia シリーズ・・・最低1機種
・キャリアがY!mobileまたはEMOBILEの機種・・・最低1機種
・タブレット・・・最低1機種
・異なるメーカーの機種・・・最低５メーカー
＜応用操作＞
画面上部の[申し込み履歴]から申し込みの内容を変更する。
上記の操作を参考に問題を発見してください。
4. Webアプリケーション（以下、アプリ）の問題発見を行ってください。【※スクリーンショット必須】
【重要】
アプリの操作が15分未満の場合、承認できませんので特にご注意ください。
問題が見つかった場合は、必ずスクリーンショットを撮ってください。
問題が見つからなかった場合（実施のみ）もどの画面でもよいのでスクリーンショットを撮ってください。
問題とは、以下のどれかを指します。
【機能の問題】
1.フリーズ/強制終了
2.利用継続できない（例：ログインできない）
3.動きが遅い
5.機能の一部が正しく動作しない
6.情報が間違っている
7.エラーや、意味不明の表示が出る
8.表示が崩れている
9.その他、ユーザとして、重大な不満を感じる動作や表示など
【使いにくさや見ばえの問題】
1.表示が目ざわり
2.期待した動作ではない/期待した機能がない
3.操作がしにくい、使い勝手が悪い
4.表示情報が足りない
5.誤って操作してしまいそう
6.何をしたらいいのかわからない
7.見づらい
5. 報告用サイトにアクセスしてください
https://yyyyy.flexfirm.jp/
※このときに、テスターごとに、違ったユーザーID、パスワードが発行されるような工夫が必要になりました。
テストの手順については、概要のみを提示し、その他は独力で理解してやってもらうようにしました。
テスト結果
●テスト概要
| テスト概要 | |
|---|---|
| 実施期間 | 3日(金曜～日曜) |
| 実施人数 | 26人 |
| 問題報告数 | 45個 |
●問題報告の内訳
| 問題の種類 | 報告数 |
|---|---|
| 不具合などの機能的な問題 | 3 |
| ブラウザ依存の問題 | 0 |
| ユーザビリティの問題 | 26 |
| その他、意味不明、勘違い、重複など | 16 |
| 合計 | 45個 |
●OSとブラウザの分布
| OS | ブラウザ | 人数 |
|---|---|---|
| OS X 10.10 | Safari 8 | 1 |
| OS X 10.9 | Safari 7 | 3 |
| Windows 7 | Chrome44 | 12 |
| Windows 7 | Firefox40 | 3 |
| Windows 7 | IE11 | 5 |
| Windows 8.1 | Chrome44 | 1 |
| Windows 8.1 | Firefox40 | 1 |
| Windows 8.1 | IE11 | 4 |
これについては、期待通りに人数が分かれました。
幸いブラウザ依存の問題は発見されませんでした。
具体的な事例
発見された中から、大きな不具合を一つ紹介します。
「レンタル開始日と終了日を選択し、配送・受取指定を変更するとレンタル開始日、終了日がリセットされる」
これは内部でのテストケースの漏れといえるでしょう。
一番多くの指摘があったユーザビリティの問題は以下です。
「キャリアや形状、メーカー、OSを複数選択する時、controlキーを押しながら選択しなければならない点が使いにくく感じました。 また、メーカーやOSは選択項目が多いのですが、見えている範囲が狭く、選択しにくかったです。」
これは5件の同様な指摘がありました。
実はここは、仕様を決めのとき、幾つものやり方があったため、もめた点だったのです。ここの設計担当は、この指摘にがっくりの様子でした。つまりユーザー視点が自分の思いと違っていたことに気が付いたからです。
この指摘には、クラウドソーシングを利用したユーザーテストならではの特徴があります。
それは__26人中5人がそう思ったという、重みが分かる点__です。
ユーザーテストにかかったコスト
内部工数
テスト準備 4時間
報告された問題の精査 4時間
コスト
17,000円程度をクラウドソーサーに支払いました。テスターの総稼働時間は22時間程度と思われます。
参考までに内部で行なった受け入れテストと運用テストは以下の通りです。
テスト実施時間 16時間
発見バグ数 19個
テスト方法の比較
我々が行った二つのテストを比較してみました。
| 外部者によるユーザーテスト | 開発・運用メンバーによる受け入れテストと運用テスト | |
|---|---|---|
| バグ発見コスト(※1) | ￥1,290/個 | ￥2,500/個 |
| 使い勝手の問題 | 多数発見 | ほとんど発見なし |
| 使用ブラウザ | OSとの組み合わせで8通り | OSとの組み合わせで2通り |
| テスト前の準備 | クラウドソーシングプラットフォーム選定 | テストケース・シナリオ作り |
| ” | テスト環境準備 | テスト環境準備 |
| ” | 問題報告システム準備 | |
| ” | シナリオ作り | |
| ” | アカウント自動発行システム | |
| 問題報告の質 | 玉石混合、重複多数 | 良い |
| テストカバレッジ | テスターの力量による | 努力次第で100を目指せる |
| (※1 内部時給を ￥3,000 と仮定) |
単純な比較は意味がありませんが、ユーザーテストはコストの低さ、準備作業の面倒さが特徴といえるでしょう。したがって、初めて試みる開発担当者にとっては、敷居が高く、気の進まないテストにはなるでしょう。
まとめ
今回、コストと時間がそれなりにかかるユーザーテストですが、正直やって良かったと思います。
もしやらなければ、3つの不具合で、ユーザーへに迷惑をかけることになったのは必至です。
また、ユーザビリティに関する指摘を読むと、内部の人とは違った視点を持っていることは明白で、ユーザーを深く知る貴重な機会になりました。
●結論
「えいやっ！」で結論を書きます。
・リリースが目的であれば、ユーザーテストはマイナス
納期を遅らせ、コストも発生させるから。
・運用が目的であれば、ユーザーテストは必須
ユーザー満足の高い状態からのスタートが可能で、初期トラブルのへの対応の手間が減らせるから。
次回の開発では、内部テストを減らし、外部テストでの範囲を拡大してやってみたいと思っています。
皆様もクラウドソーシングを利用したユーザーテストにチャレンジしてみてはいかがでしょうか？
※FlexFirmでは現在、アプリの運用に関するアンケートを実施しています。
ご協力いただけましたら幸いです。
アンケート（Googleフォームに遷移します）