１．概要

これまでテストに最低限必要な計画、設計、テストケースの3つについて説明いたしました。今回からは上記を補足するドキュメント郡について説明いたします。

今回の対象となるのは「テスト手順書」になります。テスト手順書は、テストケースの実施手順と合否判定のプロセス等を記載したドキュメントになります。

2．IEEE829のテスト手順書とは？

IEEE829のテスト手順書は以下の構成となっています。こちらは、実際にテスト手順を考えるにあたって項目数が少ないので、3章以降で経験談も交えて解説いたします。

構成
・テスト手順書識別番号
・目的
・特殊な要件　⇒テスト実施に必要な特殊な環境、データ等を記載します
・手順のステップ　⇒どのテストから実施するのか流れを記載します

テストを実施する上で問題になる部分や、事前に必要なものについて記載します。

3．テスト手順書の考え方

テスト手順書では大きく、
①テストケースの実施順序を決める
②テストの合否安定方法の詳細を決める
の2つを考えます。

①テストの順序を決める

作成したテストケースをどの順序で実施するかを決定します。

基本的な実施順序の考え方は、信頼度成長曲線を描けるように順序を決めることです。つまり、初めに不具合を質・量ともに多く出し、後半に少なくする、ということになります。

なぜ上記のような考え方を行うかというと、以下の理由が挙げられます

• 終了ギリギリに重大な不具合が出ると、リリースに影響が出る
• 早めに見つかればリリース時期の再検討や対応策を検討することも可能

では、どのようにして信頼度成長曲線を描けるような順序を決めるかというと、以下のように考えます。

• 複雑な機能からテストを行う

複雑であればあるほど不具合は多くなる傾向にあります。そのため、機能の連携が多い部分、外部のシステムと関わるところ、読み込むデータの種類が多いなどを優先的にテストします。

• 開発者がここは不具合が多いかも、と指摘しているところからテストを行う

開発者側にも確認しテストの順序を決めます。経験則から、ここが多いかも、と開発者が言った部分は結構な確率で当たります。

• コードレビューや単体テストで不具合が多かったところかたテストを行う

事前のレビュー等で不具合が多かった機能は、大抵その後のテストでも多くなる傾向があります。そのため、事前にコードレビュー等の結果を入手し、テストの実施手順書に含めるべきです。

• 見落としそうな例外パターンからテストを行う

テスト設計中にテスト担当者が作成した例外パターンのテストは、早めに実施するべきです。例外パターンは開発に反映されていないことが多く、不具合が多く出る傾向があります。

また、そのほかのテスト手順を考える上で以下のような考え方もあります。

• 時間がかかるテストから行う（環境の準備が大変、大量のテストデータが必要、性能テストなど）

どこか間違いがあって、やり直しになることが多くあります。後半にやり直しになると、時間がなくやり直すことができなくなり、テスト未実施でリリースしなければならないこともあります。

ただ、段階的にリリースされる場合は時間のかかるものからテストできないことがあるので、その場合は、できるだけ早めにテストできるように努めるしか方法はないです。

• 仕様が不明確な機能からテストを行う

仕様が不明確ということは、そこに不具合があるのかどうかも誰にも分らない状況でもあります。そのため、早期にその部分をテストすることで問題部分を明瞭にすることができます。（一部をテストして不具合が出ない場合は、途中で順序を後の方に変えることもあります）

②テストの合否安定方法の詳細を決める

テストの合否判定基準についてはテスト計画書で概要を決めています。そのためテスト手順書では、どんな時にどんな判定をすればいいのか、詳細や例外を決めます。

ここでの基本的な考え方は、だれでもそのフローに沿って判定できるような基準となっていること、です。そのため、今回テストを担当する担当者のスキルレベルによって記載の粒度は変わってきます。
※テストの実施が初めてのチームや、複数の会社に依頼する場合も詳細に記載する必要があります。

例えば、担当者の技術レベルが高ければ、

• 期待結果と同じになっていればOKとする
• 期待結果と違う場合はNGとする
• 環境不備で実施できない場合は保留とする…など

とテスト計画書で記載する概要レベルで問題ありません。なぜなら、上記から外れる問題については、担当者自身が自分で考え判定してくれるからです。

ただ、担当者の技術レベルが低い、もしくは複数の会社に依頼する場合などは、不具合の判定フローなどを作成して詳細化する必要があります。

不具合フローには関係する担当者と、時間軸上の対応の流れを記載しておけば大丈夫です。

4．テスト手順書の項目

IEEE829の項目と3章の内容から、テスト手順書に含めるべき項目は以下となります。

• ①目的

ここではテスト手順を決めるための大方針を記載を記載します。不具合を早めに見つける、A機能が重要なためここを優先する、などを記載して、テスト実施の順序でもめる場合は、ここの目的を参照します。

• ②特殊要件

テスト実施に必要な環境、データなど用意に時間がかかるものを記載します。また、できれば誰がいつまでに用意するのか、スケジュールも記載しておいた方がいいです。

• ③テストの手順

機能テストB　⇒機能テストC　⇒機能テストAの順にテストを実施するなど、ケースレベルでの実施順序を記載します。もしくは実施のWBSなどを記載して、テストの手順をわかりやすく記載しましょう。
※ここが最重要項目

• ④テスト手順の変更条件

不具合が多く検出されないなど、信頼度成長曲線が描けない場合の対応方法を記載します。例えば、目的通りにテストをしても不具合が出ない場合は様子見や、別のテストを先行して一部実施する、などの対応を記載します。

• ⑤テスト合否合判定の詳細

テスト担当者の技術レベルが低い場合や、複数の会社に依頼する場合はテストの合否判定基準の詳細を記載します。

基本的には、こういったときにこういった流れで対応する、といったフロー図を記載することが多いです。ただ、特に記載しなくても対応できる人選の場合は、この項目を記載しなくても問題ないです。

最低限、上記の5つの項目（テストの合否判定を記載しないのであれば4つ）が記載されていればテスト手順書として問題ないです。

5．まとめ

テスト手順書はテスト実施をスムーズに進めるために作成するドキュメントです。そのため、テストが複雑になりそうであれば、テスト手順書を作成しテストを円滑に進める必要があります。

ただ、1～2週間で終わるようなテストであれば、テスト手順書を作成しなくても問題ないことが多いです。ただ、その場合、テスト手順書等にテスト手順書の考えを取り入れて、設計を行う必要があります。