「何百人が一斉にテスト、バグがなければタダ」 驚きのテスティング・サービス uTest【体験編】

前回、ペイパーバグサービス「uTest」を紹介したが、筆者らはこのサービスを実際に利用してみた。本稿では、その内容を報告する。

■「uTest」を利用した開発案件の概要
筆者所属の会社（当社）が開発・運用を請け負っている「インテリアに興味のある人々のコミュニティーサイト」のリリースに向けて「uTest」を利用した。

主な機能の特徴は以下の通り、

・インテリアの価値観の合う人との交流
・プロシューマと呼ばれる、インテリアに造詣が深いユーザーにインテリアの相談
・インテリアの写真の共有だけでなく、購入場所、購入価格などの情報提供

プロジェクト管理と機能設計は当社社員、開発は協力会社に一括発注した。今回、協力会社の開発したシステムの受入検収試験の一環として「uTest」を活用した。

新しいサービスにトライすることを協力会社に相談したところ、関心をもってもらった。折角なので、発注条件としてバグが少なければ開発費を「増額」し、バグが多ければ「減額」することとした。テスト期間は2009/5/25-29と設定。6/2には顧客に納品、顧客側での検収作業に着手する計画だ。

■事前契約交渉
「uTest」に対して、4月後半に直接、利用できそうかをメールで確認してみた。「日本語のサイトでテストは可能か？」「バグか否かの判定はどのようにするのか？」「バグの種類の区分け定義はなに？」といった素朴な疑問を投げかけたところ、丁寧な返信があった。

「uTest」としては、日本語サイトでの利用は初めて。一方、日本人のテスターは数十名存在することも分かった。何度かの確認作業を通じ、利用メリットを得られると確信して、発注の意思を伝えた。

すると直ちに、order sheet が PDF でメール送付されてきた。サインして返信するとともに、Start-up Subscriptions として1,500ドルの決済をクレジットカードで行った。この費用から、バグでかかったコストを引き当てることになる。

■テスト準備
・チャット会議を2度実施した。時差の関係もあり、日本時間の23時（uTest の拠点 Boston 時間は午前10時）に打ち合わせ開始だ。

・「uTest」側は案件ごとに、当初はプロジェクト管理者アサインする。今回のプロジェクトでは、Roy Solomon がアサインされた。彼の役割は、テスターの募集、進捗管理、テスターとクライアントと意見調整だ。会議には、Roy 以外に営業担当者とマネージャも参加した。

・打ち合わせでは、我々からサイトの概要説明と、テストしたい機能範囲やスケジュール、進め方の要望等を説明した。かなり突っ込んだ質疑応答が繰り返される。テストの概念が異なり意見がかみ合わないこともあったが、幸い当社には英語に堪能な技術者が対応したので、スムーズに進行できた。このような人材がいないと、契約の問題などもあり、かなり苦労しそうだ。

・テスト開始前に High Level Script（大雑把な仕様書）を用意するように求められた。内容は、設計時に作成した、画面遷移図と機能一覧表を英語化したものだ。

・テストサーバーのアドレスと認証方法およびテストアカウントを発行し、Roy に伝えた。

■テスト開始
・「uTest」のバグ管理システムのアカウントが用意される。このシステムにログインすると、プロジェクトの概要や事前に提出した High Level Script も掲載されている（図1）。

開始時点で、テスターは4名だった。テスターは徐々に増えていき、最終的には14名となった。少なくとも、我々にはテスターを集めるのに苦労しているような様子は伺えなかった。


・テスターのプロフィールをみると、フルネームと国籍や使用しているブラウザや OS の使用言語、テスト経験、ウイルスソフトなどの情報が記載されている。（図2）。

これに加えて、テストのスキルとして、Functional/GUI/Regression/Security/WhiteBox/Script Writing/Performance/Stress/ Userbility/Technical Writing/Automation/Programing といった項目ごとに、［Begginer］［Familiar］［Good］［Very Good］などのスコアが掲載されている。

・バグの報告は、バグ管理システムに随時登録されてくる。土日に報告が多い傾向があり、テスターが副業として作業しているケースもありそうだ。


・テスターはかなり真面目にテストをしてくれる。エラーの内容は画面コピーなどの添付もして、細やかに記述もあり対策もとりやすい。

・またバグ項目の横に時計アイコンが表示される。投稿されてから、承認も否認もしないでいると、自動的に承認（auto-approval）されてしまう。テスターのモチベーションのためにもなるべく早く判断をすることが大切だ。

・テスターからのバグ申請に対して拒否する場合は、理由を必ず書かなければならない。当方の全面的に主張が受け入れられ、トラブルは一切なかった。

■テスト総括
・最終的に報告されたバグは21件（図3）。このうち、14件をバグとして認定した。


・21件中、GUI が11件、Functional が7件と大多数を占めた。

・指摘されながら、バグと認定しなかったケースは「仕様認識の錯誤」、「既知のバグ」などだ。テスターとの間に摩擦が起きるかと懸念もしたが、前述のとおり、すんなりと受け入れられた。

・バグ費用は、合計361ドル。1件当たり約25ドルのコストとなった。

・High Level Script に間違いがあって、バグと指摘された例もあった。結果的に設計書のバグも指摘されたことになった。

我々は直接、テスト仕様をテスターに説明していないにも関わらず、テスター間のテスト内容の重複も少なく、かなり細かいチェックをしてもらった。今回は、あくまで顧客からの側面からしか理解できなかったが、「uTest」のテスター管理は緻密そうだ。また、テスターの募集方法や、先に述べた auto-approval のような機能等運用ノウハウも蓄積されている模様。

■まとめ
今回、委託会社からの検収受け入れテストに十分活用できた。

当然「uTest」とテスター間では守秘義務契約を結んでいる。また、バグ管理システムから氏名（フルネーム）も確認できる。テストは専用のテストサーバー（固定 IP アドレス）を用意し認証機能によってアクセスできる者を限定した。

さらに VPN を設定したり、アクセス可能な IP アドレスを制限することも考えられる。今回、このような相談していないが、要望には柔軟に対応してくれる印象がある。逆に利用者が専門的な知識を有する前提の業務システムには、向いていないだろう。テスターが専門の業務知識を習得しなければならないからだ。

「uTest」は自らを“In The Wild Testing”と位置づけている。実際にサイトを利用者が使う環境は、テスト仕様書で計画できる「美しい世界」ではない。言語、ブラウザ、OS、インストールされているプログラムなど予測不可能な膨大なバリエーションで利用される。

「uTest」は、実際に近い状況でテストを目指している。（図4）は電気通信大学 西氏がまとめられた「テスト実施4つの視点」（PDF）である。

「uTest」は、このなかの、User-View（ユーザーが何をするかを考える）と Fault-view（起こしたいバグを考える）の2つのアプローチを最も得意とするサービスだ。


システム開発において、「uTest」を利用できそうなケースを考えてみた。

（1）公開中サービスの継続的なテスト
「リリース後のサービスに対して継続的にアドホックテストを実施する」
これが、「uTest」の最も効果的な活用方法だ。同じサイトでのテストが繰り返されるため、テスターも固定化される。

このため、着々とサービスに対する理解も深まる。事前説明などの手間も省けたうえに、ペイバーバグの専属チームを編成できる。前稿で述べたとおり、「uTest」のバグバトルでは、「Facebook」、「Myspace」、「LinkedIn」などすでに数年の実績があるメジャーサービスで、それぞれ200を上回るバグが発見できるテスターたちだ。

きっと、良好なサービス運営に資することだろう。例えば3か月に1度メジャーなリリースを行う場合、そのタイミングごとに利用するようにすることでも効果が期待できる。月額ランニングコストが100万円を超えるような規模のサービスであれば、是非お勧めしたい。

（2）受入れ検収委託したプログラムの検収
今回のプロジェクトのように（a）SIer が協力会社から受け入れ検収として利用するケースと、（b）サービス提供者が SIer からの受け入れ検収に利用するケースと2つある。

委託開発の契約条項に「検収期間」を設けて受け入れ検収をすることが多く見受けられる。例えば、検収期間に通常の検収作業に加えて、「uTest」を利用する。このことで、テスト専門家による密度の濃い、客観的なテストを実施できる。これは検収する側だけのメリットではなく、受託開発側にとってもバグを前倒しで対応できることになる。リリース後の障害対応に要するコストを削減できる効果ある。

また、発注時から検収条件として「第三者が実施したテストで発生した問題をすべて解決すること」とすれどうだろうか？委託者にも受託者にとっても公平感のある、検収基準が設けられるのではないだろうか？月額費用が1,500ドルということを考えると、500万円以上の受託案件であれば活用を検討してみてはいかがだろうか。開発サイドは極力品質の高いものを納期内に仕上げないと、余分に原価を支払うことになる。

（3）ソフトハウスのテスト工程のアウトソーシング
開発者とテスターの分業は米国では一般的だ。マイクロソフトでは開発者1人と専門テスター1人がアサインされると聞く。双方がプロフェッショナルでなければ、十分な成果が得られない。

専任のテスト体制を用意すれば好ましいことは理解できても、小規模な企業規模のソフトハウスでは、専任のテスターをアサインするほどの業務量が確保できないのが現実だ。自然、開発者が掛け持ちでテストすることになる。

貴重な開発リソースを効果的に利用するため、テストを「uTest」に委託してみてはいかがか？コストの変動費化が可能なだけでなく、開発とテストの責任分解点も整理できる。また事前に、テストスケジュールを「uTest」だけでなく、関係者全員に宣言することになる。プロジェクト管理面でも緊張感が生まれる。

また「uTest」は、一時期に何百人ものテスターに同時にアクセスしてもらうテストも提供している。こちらは、ペイバーバグではなく、稼働実績により費用が請求される。ほかにも、マニアックなテスターにクリティカルなバグを集中的に見つけてもらうといった、明確な目的をもったテストにも効果がありそうだ。

また、サービスメニューはないが、プログラミングに長けたテスターも存在する。将来的には、豊富なリソースを活用して、ソースコードレビューを受託するようなサービスも生まれるかもしれない。

オーソドックスな「uTest」のサービスモデルは、「一通り完成したシステム」を専門的なテストスキルを持っているテスターが「プレビュー」して問題点を指摘する。その指摘内容のうち、顧客に納得してもらった分だけ費用を申し受ける、というものだ。丁度、マイクロソフトの製品でよくみられるβバージョンを開発者などに配布してバグをだしてもらうプロセスに該当する。

「uTest」の目指すテストは、テスト項目を消化して報告書を作成することではない。サイト利用者達がおそらく経験するであろう、バグや不快感、違和感などを、事前に明らかにすることだ。

Web サイトの利用者は、操作していてストレスを感じたり、気にくわない表現や動作があっただけでアクセスしなくなる。クレームすらあげてくれない。このような「サイレント・マジョリティー」の声に気づかせてくれる、実践的な効果を期待できる。

【当コラム執筆は、Looops Communications 取締役副社長の福田浩至が担当しています】