単体テストとか結合テストとか


ITのテストは組織や顧客やそれぞれのドメインで言い方も何をするかも様々で、いちいちこのテストは何をどこまでするかを聞かないと工数の配分を失敗してしまうんです。


テストの専門家や品質の専門家ではないのですが、経験値で整理しておきます。おもにテストフェーズで記載しますがこのほかテストのレベルやテストのタイプなどの視点が絡むのでテスト方針とテスト計画大事です。


テストフェーズ
所謂、単体テスト結合テスト、総合テストというテストの目的で区切ったもの。呼び名は、単体テストユニットテストやモジュールテストなど様々ある。


単体テストの目的は、モジュールや関数レベルの機能の確認でテスト手法はホワイトボックスをとることが多い。単体で動作しない関数やモジュールは、スタブやドライバなどが必要になる。


異常系のテストをするならココ、単体テストでやっておかないと、結合時にテスト済みのプログラムをわざわざ修正して異常系テストを実施することになり、そのあとプログラムを戻すことが必要になるのでムダになったり、最悪修正を忘れたりするので異常系のテストは方針が大事。


結合テスト
結合テストは、一つのプログラムとして動作するものの単位で結合する結合テストとシステムとして連動させて動作を確認するテストがある。前者はプログラム内のインタフェースをテストし、後者はプログラム同士のインタフェースをテストする。


なので、結合テストは限界値テストやシステムとしての全体の連動テストと結合したシステムのレスポンスの負荷をテストすることを目的とすることが多い。


プロジェクトによっては、この結合テストをベンダのシステムテストと位置づけることがあるので、うっかりして総合テストでもテストが出来ると思っているとテストを積み残すことがあるので注意が必要です。


負荷テスト
負荷テストは、非機能要件の有無でその結果の対応が左右されるので、基本設計(外部設計)での非機能要件や仕様が曖昧だと後の始末が大変になる。あと、思ったより工数が係るのと負荷テストツールは経験者がいないと設定が面倒なので。


運用を専門の部署に引き継ぐ場合、この結合テストのタイミングで引継ぎを始めることをお勧めする。できれば、結合テストのテスト実施者に入ってもらい、テストすることで実際のシステム操作をスキトラするのがお互いにとってお利口さんです。


総合テスト
顧客がこの局面に入って初めてまじめにコレまで作ってきたシステムのことを考える時期です。この局面が始まるまでにそれだけ口すっぱく言ってきたか、顧客の準備がどれだけ進んだかでリリースがオンスケで行くか延伸されるかに分かれます。顧客業務としての確認するテストですからね。


まぁ、ここで単体テストレベルのバグが出るとベンダは死にますけど。