4．単体テスト

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

製造したプログラムや、画面の動的部分について、仕様どおり実装できているかどうかテストを行う。

• 単体テストのレベルではプログラムの内部構造を考え、（判定条件や経路など）すべての命令が意図どおりに動作するかどうかチェックする。（ホワイトボックステスト）
• 必要に応じて、テストデータを検討・準備する。

画面・帳票の表示部分について、仕様どおり実装できているかどうかチェックする。

• レイアウトだけでなく、文言の誤字脱字、データ内容、初期表示状態、状況によって変わる部分などもチェックする

プログラマーは、担当した１画面内／１機能内の責任を持つ。

• テスト工程としてではなく、製造工程に含まれることがほとんど。
• 「製造」として与えられたスケジュールは、単体テストも含めて考える。

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

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

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

1. テスト項目を洗い出し、必要であればチェックリスト化する。
   • 単体テストのレベルでは、プログラムのすべての命令が意図どおりに動作しているかのチェックを行う。
   • プログラムのすべての経路の動作を確認できるよう、考えられる入力データパターンを洗い出す。
     • 正常値
     • エラー値
     • その境界値となる値
     • ．．．その他
2. 必要に応じて、テストデータやテストプログラムを準備する。
   • データベースやファイルを使っている場合は、テスト内容に応じてデータを入力しておく。
     • あらかじめ複数件のデータが入っている場合
     • １件もデータが入っていない場合
     • １件しかデータがない場合
     • あるデータ値が空の場合
     • ．．．その他
   • 別プログラムや別画面を呼び出したり、別プログラムや別画面から呼び出されたりする場合は、前後のプログラム／画面がまだ用意されていなければ、簡単な仮のものを自分で用意する。
   • 本番データである必要はないが、ある程度実データに近いものでないと入力チェックや計算が機能せず、プログラムの正しい実行・テストにならない。
3. テスト項目に応じて、テストする。
   • 不具合が見られる場合は、以下のことを必ずチェックしておく。
     • 「どの画面／プログラムで」
     • 「何をしようとした時」
     • 「どんなデータ状態の時」
     • 「どうなったか」
     • 「どんなエラーメッセージが出たか」
     • （「ほんとは、どうならないといけないか」）
4. チェックリストがある場合は、状況を記入しておく。
   • チェックリストがある場合は、状況を記入しておく。
   • 記入票がない場合であっても、これらについて必ず状況を把握しておく。
5. 不具合が見られる場合は、デバッグする。
   • デバッグ後、必ず再テストする。

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

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

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

テスト項目の漏れ、データパターンの漏れが、品質に直結する。

• 不具合が出る以前に、そもそもテスト項目やデータパターンに漏れがあれば、「不具合があるかどうかも分からない」状態となる。
  これが一番危ない。
• 類似機能・類似画面であれば、同じようなテスト項目の洗い出し方も可能。チーム内で相談し、あらかじめ基本パターンを洗い出しておいてもいい

プログラムの不具合には、プログラムが悪い場合ももちろんあるが、データが悪い場合も多い。  
エラー原因を特定することが、手早い修正につながる。

• 「どんなデータを使ったらどんなエラーが起きるか」をよく見る。
• 余計な不具合を起こさないためにも、適当な（実データとかけ離れているような）データを使ってテストをするのは良くない。

担当プログラマーが仕様を勘違いしていた場合、ここでは不具合を検出できない。  

単体テストを終了したプログラム／画面は、「１機能／１画面の範囲であれば、問題なく動く」と見なされる。

• この後、隣接する別機能／別画面との結合・連携時に、もし単体レベルでのエラーが出れば、「担当プログラマーは責任を果たしていない」と見なされる。

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