システムやソフトウェアのテスト設計では、開発者の視点とは異なる、ユーザーの視点を持つことが大切です。

ユーザーの視点を持ってテスト設計を行うことで、システムやソフトウェアの品質が格段に向上するからです。

それでは、テスト設計を行う上で、ユーザーの視点と開発者の視点との違いは、どういったところにあるのでしょうか。テスト設計でどのように活かされるのでしょうか。

開発者の視点は、機能からテストを考える

開発者の視点でテスト設計するということは、システムやソフトウェアの機能が、要件定義書にまとめられた仕様通りの動きをするかどうか、チェックするということです。

開発者の視点で行うテストは、主に単体テストや結合テストで行われます。単体テストの工程では、ホワイトボックステストと呼ばれるテスト手法が用いられます。プログラムの内部を読み込んで、論理構造が正しいかどうか、解析するテストです。

単体テストの次の工程、結合テストでは、同値分割法や境界値分析、状態遷移テストなど、ブラックボックステストと呼ばれるテスト手法が用いられます。こうした手法は、機能は正しく動くかどうか、効率よくテストするために編み出されたものです。

⇒関連記事：失敗しないテストケースの作り方と、効率よくテストを進める方法

ユーザーの視点は、実現したいニーズから考える

一方、ユーザーの視点でテスト設計するということは、本来実現したいことができるかどうかをチェックするということです。システムやソフトウェアが、要件定義書にまとめられた仕様通りの動きをするのは当然のこと。使い勝手が良いか、ストレスのない操作ができるといった、ユーザビリティが求められるからです。

ユーザー視点のテストは、結合テストや総合テストで行われます。このうち、エンジニアが、ユーザー視点で設計するテストのひとつが、結合テストで行われるユースケーステストです。

ユースケーステストで重要なのは、ユーザーの使う場面を想像することです。 想像したユーザーの行動をもとにシナリオを作成し、そのシナリオに沿ってシステムやソフトウェアの動作を確認するからです。

ユースケーステストでは、まずは要求定義書を参考にして、ユーザーの行動をシナリオに起こします。さらにユーザーが想定もしないような、使う場面も追加して、ユーザーが求めている以上にユーザーのことを考えたシナリオを作成しましょう。

ユースケーステストでは2パターンのシナリオを作る

ユースケーステストで用いるシナリオは、2つのパターンがあります。1つは基本系列と呼ばれるもので、最短で目的を完了するまで進んだ場合のシナリオ。もう1つは、代替系列と呼ばれるもので、横道にそれた場合のシナリオです。

会計ソフトを例に説明すると、基本系列は、「日付や金額、仕訳を入力」から「登録」というプロセスをまっすぐ進みます。一方の代替系列は、「日付や金額を入力」から、「仕訳が分からないので検索」し、「仕訳を入力」して「登録」するなど、寄り道をしながら進みます。

まずは、一番シンプルなシナリオの基本系列を作成し、ユーザーの行動を想像しながら、代替系列を作成しましょう。

ユーザビリティテストは、実際にユーザーが動かしてテストする

ユースケーステストと混同されやすいテストに、総合テストの工程で行うユーザビリティテストがあります。

ユーザビリティテストとは、実際にターゲットとなるユーザーにシステムやソフトウェアを利用してもらい、テスト中の行動を観察して、操作に戸惑っている点や、誤った操作をした点などの問題を発見する手法です。

ターゲットになるユーザーとは、システムやソフトウェアを実際に使用すると想定される方です。ユーザビリティテストを行う前に、ターゲットとなるユーザーの年齢や性別、職業などを想定したペルソナを作成し、ペルソナに当てはまる方にシステムやソフトウェアを利用してもらいましょう。

ユーザビリティテストを行う上で課題となるのは、ペルソナに当てはまる方を確保することです。社員の中で、ペルソナに当てはまり、なおかつプロジェクトに関わっていない、第３者目線でテストを行える方を見つけるのは難しいことです。専門の調査会社に依頼して、ペルソナに当てはまるモニタを集めてテストを行うという方法もあります。

ユースケーステストは、想像したユーザーの行動をもとにシナリオを作成し、そのシナリオに沿ってシステムやソフトウェアの動作を確認するテストです。一方のユーザビリティテストは、システムやソフトウェアが使いやすかどうかをテストします。ですから、会計ソフトの登録ボタンのサイズが小さすぎて見つけられない場合、ユーザビリティテストはクリアできません。しかし、ボタンを押して仕様通りに動くなら、ユースケーステストはクリアできるというわけです。

独立したテストチームのメリット・デメリット

ここまでは、ユーザー視点を持ってテスト設計を行う重要性を伝えてきました。ここからは、ユーザー視点のテストをより充実させる方法を紹介します。その方法とは、システムやソフトウェアの開発に関わっていないエンジニアがテストする、独立したテストチームを立ち上げるという方法です。

しがらみがなく、バグを指摘できるメリットも

独立したテストチームを作ることで、開発者の視点への偏りを抑えて、テストを行うことができます。システムやソフトウェアの開発者がテストを行うと、機能を理解しているだけに、「こう使うだろう」という思いが強く、ユースケーステストなどで想定外の使い方をするシナリオが不十分なものとなる可能性があります。独立したテストチームであれば、客観的に、ユーザーの視点でテスト設計を行うことができます。

独立したテストチームを立ち上げることで、テストとバグの修正を並行して行えるというメリットもあります。開発を担当したエンジニアが、テストも担当すると、バグの修正にまで手が回らず、進行が遅れる可能性があります。テスト工程の進行を速める上でも、独立したテストチームの立ち上げを検討してはいかがでしょうか。

さらに、独立したテストチームであれば、先入観やしがらみなく、バグを指摘することができます。開発を担当したエンジニアでテストを行うと、バグを見つけても指摘しづらいといったことはないでしょうか。また、バグの修正が増えてしまうから、といった理由からバグを指摘しないといった事態も防ぐことができます。

デメリットは、開発チームとテストチームの対立に発展する可能性

独立したテストチームを作ることは、ユーザー視点のテストをより充実させるだけでなく、テストの進行を速め、バグの洗い出しにも貢献するというメリットがあります。しかし、いいことばかりではありません。デメリットも存在します。

開発を担当しているチームと、テストチームとで十分なコミュニケーションが取れていないと、テストの進行が遅れる場合があります。テストに必要なデータが共有されていなかったり、仕様の変更が伝わっていなかったりして、手戻りが発生するといったことが考えられます。

また、開発を担当するチームが、テストチームがバグを見つけてくれると考えるようになると、品質管理への意識が薄れる可能性もあります。

最悪の場合、テストチームと開発チームの間で対立することも考えられます。テストチームは独立することで、バグを修正する手間などを考えずに指摘できますが、開発チームにしわ寄せがいくからです。

まとめ

テスト設計では、開発者の視点で、機能が正しく動くかどうか、テストすることはもちろん大切です。しかし、実際にシステムやソフトウェアを使うのはユーザーです。

ユーザー視点のテストを充実させるために、独立したテストチームを作る方法を紹介しましたが、プロジェクトの規模や状況によって難しいこともあるかもしれません。

ユーザーは、いったいどんな使い方をするだろうか。単体テストの工程から、ユーザーの視点を意識して、テスト設計に臨むところから始めてはいかがでしょうか。