5．テスト項目洗い出し、テスト報告書作成、テスト

◆作業の概要、目的、タイミング

（原則として）仕様書に基づき、「システムのあるべき状態／動作」を洗い出し、ドキュメント化し、テストする。

• 画面上でユーザが操作可能なすべてのこと
• 入力され得るすべてのデータパターン
• 状態によって自動的に変わる部分

メニュー体系に従った画面遷移、複数機能の連続動作を含めて項目を洗い出す。  
実際の業務で使用することを前提とした流れを想定する。  
テストそのものは製造終了時～後に行うものだが、テスト項目の洗い出しだけであれば、  
（原則として）仕様確定後ならいつでもできる。

• 事前に、仕様が詳細部分まで明確になっていて、仕様変更がない（または、仕様変更に際してドキュメントとプログラムの同期が取れている）ことが前提。
• 「テストファースト」という考え方もある。実装より先にテスト項目の洗い出しとテストコード・テストデータの作成を行い、その１つ１つをクリアしていくイメージで実装していく開発手法。

テスト報告書は、システムとあわせて顧客に提出することもある。

◆事前に必要なもの、情報

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

◆一般的な、テストの種類

以下に挙げたもののうち、結合テストおよび機能テストは、どのシステムでもほぼ行われる。　　
それ以外は、システムの規模や性質などに応じて、必要なものが行われる。

• 結合テスト
  各画面やプログラムを結合し、動作、データの流れなどを検証する。
  • トップダウンテスト：システムの上位メニューから順番に結合し、テストを進める。
    必要な下位メニューがまだ未完成の場合、ダミー（＝スタブ）を用意することがある。
  • ボトムアップテスト：システムの下位メニューから順番に結合し、テストを進める。
    必要な上位メニューがまだ未完成の場合、ダミー（＝ドライバ）を用意することがある。
• システムテスト
  各機能を連動させ、システム全体の処理、動作、データの流れ、性能などを検証する。
  • 機能テスト：仕様にしたがって、機能を満たしているかを検証する。
  • 性能テスト：画面遷移、検索や集計などの応答時間を計ったり、マシンのリソース消費量を計ったりする。
  • 負荷テスト：一度に大量のアクセスをかけたり、複数ユーザが同時に異なる処理をしたり、大量データを処理したりする。
• 運用テスト
  本番環境、またはそれに近い形で、実際の業務の流れに基づいたシステムの動作全般を検証する。
  • ユーザが主体となることが望ましい。
  • これが「試験運用」「受け入れテスト」となり、このテストにパスすれば「本稼働OK」と見なされる。
    （逆に言えば、パスしなければ本稼働できない。）

◆具体的な作業項目、手順

1. テスト項目を洗い出し、リスト化する。これをテスト項目一覧表とし、最終的にはテスト報告書とする。
   • 入力データとそれに応じた状態／結果、そのデータパターン
   • ある動作／状態変更に応じた、別の箇所の状態変更
   • 画面・項目の初期値、別画面から引き継いだ値／状態
   • 画面の進み／戻りの場所
   • 入力エラー・システムエラーの際の、適切な状態
2. 必要に応じて、テスト機やテストデータを準備する。
   • ユーザが実際に使用する機器やOS、ソフトなどのバージョンがばらばらの場合、できるだけ多くのバージョンや組合せでテストする。
   • データベースやファイルを使っている場合は、テスト内容に応じてデータを入力しておく。
     • あらかじめ複数件のデータが入っている場合
     • １件もデータが入っていない場合
     • １件しかデータがない場合
     • あるデータ値が空の場合
     • ．．．その他
   • ユーザから実データをもらってテストすることもある。
     • 実データを扱う場合には、セキュリティにも十分注意する。
     • 壊れて復旧できなかったり、社外に漏れたりすれば、何らかの責任を負う可能性もある。
     • 社内でも、プロジェクトの関係者以外には触れさせないようにする。
3. テスト項目に応じて、テストする。
   • 不具合が見られる場合は、以下のことを必ずチェックしておく。
     • 「どの画面／プログラムで」
     • 「何をしようとした時」
     • 「どんなデータ状態の時」
     • 「どうなったか」
     • 「どんなエラーメッセージが出たか」
     • （「ほんとは、どうならないといけないか」）
4. テスト項目一覧表に、状況を記入する。不具合が見られる場合は、場合によっては不具合票に記入し、プロジェクト内で共有する。
   • 不具合が見られる場合は、上記のチェック項目について状況を必ず記入しておく。
   • プロジェクトの規模にもよるが、あらかじめ不具合票フォーマットを紙（またはファイル）で用意しておくこともある。
5. 不具合が見られる場合は担当者がデバッグし、再度テスト担当者に回す。
   • デバッグ後、必ず再テストする。
6. ドキュメントの体裁を整え、テスト報告書とする。
   • すべてのテスト項目が「結果OK」となっていることが前提。
   • テストを実施したマシン環境などについても記述する。

業務で使うことを想定したテストを、もれなく行う。

• ある日の売上が全くないまま、集計処理をするケース
• ある日の売上が１件だけで、集計処理をするケース
• ある日の売上が複数ある状態で、集計処理をするケース
• １回の売上で、１商品を１個だけ買うケース
• １回の売上で、１商品を複数個買うケース
• １回の売上で、複数の商品を買うケース
• その他

システムによっては、画面表示／帳票出力されたデータのチェックを行う。

• ある入力データに対して、適切な結果となっているかどうか
• 一連の業務データ（あるいはそれに近いもの）に対する適切さ

◆成果物、最終イメージ、作業例

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

◆作業上のポイント、注意点

そもそも、関連業務とシステム仕様をきちんと把握していないと、適切なテスト項目洗い出しができず、正しい動作／状態のあり方も分からない。

• テストは、システムの下流工程であると同時に、その意味としては上流工程であるとも言える。

スケジュール的／要員的に可能であれば、製造担当者以外の人がテスト項目の洗い出し～テストを行うといい。

• 製造担当者がテストすると、無意識のうちに甘くなる。第三者がテストすることで、客観的にテストできる。

プロジェクトの全体期間の中で、設計や製造のスケジュールが押し気味になると、テスト期間が少なくなることが多い。

• 本来、そうならないように気を付けてプロジェクトを進め、調整する。

どんなシステムでもテストは十分にやらなければならないものだが、特に以下の場合などは気を付ける。

• 大型のシステム：不具合があると、影響範囲が大きくなる可能性がある。
• 基幹業務に近い部分で動くシステム：不具合があると、企業のメイン業務をストップさせる可能性がある。

• 一度に大量の処理が発生するシステム：通常のテストでは発見されない不具合が、本番稼働で表出する可能性がある。

  システム移行（旧システム→新システムへの移行）の場合、しばらくの間並行稼働させ、
  旧システムでの動作や出力結果と新システムでの動作や出力結果が見合うかどうかを確認することもある。

• 見合わなければ業務に対応できないので、新システムへ切り替えられない。

Copyright © Xincor miXell Co., Ltd. All rights reserved