円滑な立ち上げのために！ユーザーテストの目的と設計方法のポイント

まず最初に確認したいことがあります。

ユーザーテストの目的、誤解していませんか？

ユーザーテストは、事前に検討していたユーザー側の運用が システムを使って廻るのかを検証するものです。

システムが正しく動くのを検証することではありません。

今回は、システムを導入する前に実施するユーザーテストの目的とテスト設計方法について 紹介したいと思います。

ユーザーテストの目的 ー システムテストとの違いから

システムを導入する前のテストには、システムテストとユーザーテストがあります。

システムテストは、ベンダー側が行います。
テストの目的は、詳細設計で決めた仕様通りにシステムが動くのかを検証することです。

そして検証が終わった段階で ユーザーテストに移行します。

つまり、ユーザーテストの段階では ユーザー側と合意した仕様通りに動くことが保証されているのです。

では、ユーザーテストでは 何を確認するのでしょうか？

ユーザーテストで最も多い誤りは、システムテストと同じテストをすることです。

ダブルチェックと言えば 聞こえは良いですが、明らかに時間のムダです。
動いて当たり前なのです。

ユーザーテストは、あくまでユーザー側のテストであることを認識することが必要です。

であれば、ユーザー側で使えるかの視点が 最も重要ですよね。
システムができても 業務で使えなければ、全く意味のないものになってしまいます。

つまり、ユーザーテストの目的は システムを使ってユーザー側の業務が廻るのかを確認することなのです。

目的が異なれば、テストの設計方法も当然異なります。

次に、ユーザーテストの設計方法について 紹介したいと思います。

ユーザーテストの設計方法

通常は、以下の４フェーズに分けて設計します。

• 単体テスト
• 統合テスト
• 前後工程があれば、前後工程も含めたスルーテスト
• 試行

今回は、最も重要である①②について 紹介します。

単体テストの設計ポイント

各機能単位（各組織単位）で使用できるかをテストするものです。

通常、機能単位でユーザーテストメンバーをアサインし 実施します。

ユーザーテストメンバーは、詳細設計に参加したメンバーが行うのがベストです。

テスト設計視点で重要なポイントは、以下２つです。

• 機能単位でユーザーが考えていた処理が行われるか
• ユーザーインターフェースの使い勝手が良いか

以下 順番に紹介します。

機能単位でユーザーが考えていた処理が行われるか

ベンダー側とユーザー側との違いは、業務知識です。

ベンダー側が行うシステムテストは、あくまでも詳細設計で検討した範囲でのテストです。
テストデータも限定されています。

ユーザー側は、もっと多くの事例を持っています。

これら考えられる異なる事例を挙げて、テストの設計をするのです。

ユーザーインターフェースの使い勝手が良いか

詳細設計の段階では、画面は紙と同じです。
紙ベースで画面も遷移し、検討もしています。

実際の画面になると あれって感じることは 多々あります。
これをあぶり出すように テスト設計します。

通常は、①のテスト設計で ほぼ網羅されていると思います。
もし使わない画面があるのならば、テストに追加することになります。

そして、実際のテスト時に この２つのテスト視点で見ていくことなります。

統合テストの設計ポイント

最も重要なテストです。

実際にシステム立ち上げ後と同じ運用を実施しながら テストします。

テスト設計視点で重要なポイントは、以下３つです。

• 考えられる運用を 全て挙げてテストする
• 上位工程・下位工程で変更が発生した場合の運用を 全て挙げてテストする
• イレギュラー業務が廻るのかテストする

以下 順番に紹介します。

考えられる運用を全て挙げてテストする

ユーザーテストが始まる前には、運用規定を決定している必要があります。

システム開発と並行して行う運用検討については 別投稿していますので、そちらを参照ください。
（以下にリンクを掲示します）

参考投稿記事：円滑なシステム導入のために！導入前の運用検討が最も重要

運用規定で決めた全てのケースを織り込み、テスト設計をします。

この際に注意することは、以下です。

• 実際に稼働後に利用する機能単位毎のメンバーで実施すること（実担当が実施すること）
• 運用規定で決めた通りに実施すること
• メンバーは各自事前に正確を準備しておくこと（各自で担当分は検証すること）

特に②は 重要です。
ユーザーテストの目的そのものですよね。

本当に決めた通りに実施します。
入力をメールで依頼するのならば、メールの文面（内容）も本番と同じにします。

では、どれぐらいのテストケースが出てくると思いますか？

私の事例でいえば、５億のシステムで 約３０パターンぐらいはテストケースを設計しています。

システム化の対象にもよりますが、大体これぐらいが目安だと思います。

一方で、３０パターンを順番にやっていたら 長い期間が必要になりますよね。

テストメンバーが何もしない日がないように、スケジュール表に落とし込むこともテスト設計のポイントです。

上位工程・下位工程で変更が発生した場合の運用を 全て挙げてテストする

多くのシステムは、プロセスに沿って作られていると思います。
上位工程・下位工程の関係 当然ありますよね。

上位工程で変更した時に下位工程で行う作業もあると思います。

例えば、上位工程で製品ラインナップの中の１つの製品を廃止にした場合 下位工程で行う作業ありませんか？

逆に、下位工程で問題が発生したので、製品ラインナップの中の１つの製品を廃止することもあると思います。

こうしたお互いに影響し合う変更に関するケースを洗い出し、テストケースに織り込みます。

変更は、実際の運用の中では 頻発する行為です。
一方で、システム設計の中では 最も抜けているケースになります。

全てのケースを見つけ出すことは 確かに難しいのですが、テスト設計する際には テストメンバー全員で考え抜きましょう。

尚、①で作成したテストケースを利用して 延長線上で変更ケースを設計するのが効率的です。

イレギュラー業務が廻るのかテストする

業務には関係部署が必ずあります。
そして、関係部署もシステムを持っていて、相互に関係しているのが普通だと思います。

そのため 全て自部署都合でシステム化することはできません。

また、どうしても標準化できない頻度の少ない特殊な業務をすることもあると思います。

これらイレギュラー業務が全て廻るのか テストケースに織り込みます。

これも、事前にイレギュラー業務の運用規定を作成している と思います。
そして、運用規定通りにテストすることが 大切です。

イレギュラーケースの場合は、本番と同じデータを使って実施することをオススメします。
その方が現実感があること・正解と比較しやすいことがあります。

---

私の経験では、５億のシステムでユーザーテストを設計すると テスト期間としては３ヶ月程度になると思います。

ユーザーテストの設計期間も３ヶ月ほどです。

上記のポイントを織り込んでテスト設計・テストをします。
結構 時間がかかるものなのです。

一方で、これほど準備をしてユーザーテストをしても、稼働後３ヶ月は ドタバタします。

もし、運用が廻るのか確認もしないで システムを立ち上げたら。。。
どんな状況になるのか 容易に想像がつくと思います。

まとめ

ユーザーテストの目的は、あらかじめ決めたユーザー側の運用が廻るのかを検証するものです。

システムが正しく動くのを検証することではありません。

今回は、システムを導入する前に実施するユーザーテストについて 目的と設計方法について紹介しました。

ユーザーテストは、通常４つのフェーズに分かれます。

今回は、重要な単体テスト・統合テストについて紹介しました。

単体テストの設計ポイント

テスト設計視点で重要なポイントは、以下２つです。

• 機能単位でユーザーが考えていた処理が行われるか
• ユーザーインターフェースの使い勝手が良いか

統合テストの設計ポイント

テスト設計視点で重要なポイントは、以下３つです。

• 考えられる運用を 全て挙げてテストする
• 上位工程・下位工程で変更が発生した場合の運用を 全て挙げてテストする
• イレギュラー業務が廻るのかテストする

---

ユーザーテストを勘違いしている人、本当に多くいます。
ユーザー側のシステム担当という立場が そうさせているのかもしれません。

適切にユーザーテストを設計・実施すれば、稼働後少しはドタバタしても 必ずシステム化の効果は出せます。

まずは、ユーザーテストの目的を 正しく認識することです。