目次
0. Introduction
- 対象となる読者
- ソフトウェア・テストを任されている方
- 本記事の価値
- ソフトウェアの評価及び検証は、ソフトウェア品質に大きく影響します。ソフトウェア・テスト時に、チェックしなければいけないことを確認できます。
- 前提
- 特になし
1. ソフトウェア・テストとは
ソフトウェア・テストは、ソフトウェア製品またはアプリケーションが想定どおりに機能することを評価および検証するプロセスです。 テストを実施するメリットには、以下のようなものが挙げられます。
- バグの防止
- 開発コストの削減
- パフォーマンスの向上
2. ソフトウェア・テストの種類
ソフトウェア・テストには様々な種類があり、それぞれに特定の目的と戦略があります。IBM のソフトウェア・テストとは何か によれば、以下の種類のテストが存在します。
- 受け入れテスト
- システム全体が意図したとおりに機能するかどうかを確認します。
- 統合テスト
- ソフトウェア・コンポーネントまたは機能が集合体として動作することを確認します。
- 単体テスト
- 各ソフトウェア・ユニットが期待どおりに動作することを検証します。
- ユニットは、アプリケーションのテスト可能な最小コンポーネントです。
- 機能テスト
- 機能要件に基づいて、ビジネス・シナリオをエミュレートすることで機能を確認します。
- ブラックボックス・テストは、機能を検証するための一般的な手法です。
- 性能テスト
- さまざまなワークロードでソフトウェアがどのように動作するかをテストします。 たとえば、負荷テストは、実際の負荷条件下でのパフォーマンスを評価するために実施されます。
- 回帰テスト
- 新機能が機能性を破壊または低下させるかどうかを確認します。 本格的な回帰テストの時間がない場合は、健全性テストを使用して、メニュー、機能、およびコマンドを表面レベルで検証できます。
- ストレス・テスト
- システムに障害が発生するまでに、システムがどれだけの負荷に耐えられるかをテストします。 これは非機能テストの一種と見なされます。
- ユーザビリティー・テスト
- 顧客がシステムまたは Web アプリケーションを使用してタスクを完了することができるかどうかを検証します。
3. ソフトウェア・テスト時のチェックリスト
1. テスト計画書
- 計画されたテストは、要件定義書、設計書の内容を網羅した計画か
- テストのスケジュールが計画されており、妥当か
- テストの体制、要因が計画されており、実施可能か
- テストに必要な資源が見積もれており、妥当か
- テストに使用するツールの仕様とその使用法は明確か
- テストの進捗把握方法についてユーザとベンダが合意しているか
- テストの開始基準、完了基準、中断基準、再開基準を設定したか
- テストデータの準備について記載し、実施可能か
- テスト結果の検証方法が明確で、妥当か
- テスト実施の際の依存事項（前提条件、環境）を考慮したか
- テスト計画に影響するような大きな設計変更を行う予定はないか
- 十分なロングラン・耐久テストを計画したか
- リグレッションテストを計画したか
- パフォーマンステストを計画したか
- 限界テストを実機でテストする計画か
- 入力量、処理量、処理時間に関するストレステストを計画したか
- 見やすさ、使い易さのテストを計画したか
- ユーザとベンダの役割分担、協力事項は明確か
- テストデータ・本番データの管理方法は明確か
2. テストケース、テスト項目
2-1. 共通
- テストケース、テスト項目に固有の識別子が付与したか
- 要件定義書、設計書に記載の全項目の網羅性を書面化したか
- テストケース、テスト項目間の整合性、正確性、一意性を確保しているか
- テストケース、テスト項目に重複やモレがないか
- 入力可能なすべてのデータ（異常データも含む）を網羅したか
- 入出力のチェックを漏れなく行えるか
- すべてのメッセージを検証できるか
- すべての入力出力パラメータの範囲（正常値、境界値、異常値）を定義したか
- 各テストの方式（ホワイトボックステスト、ブラックボックステストなど）の選択理由を第三者に説明可能か
- 必要なテストを実施できない場合の対応戦略（代替テスト、別途テスト、実施しない）が明確であり、ユーザとベンダが合意しているか
- すべてのテスト項目について合否判断方法と基準を定義したか
2-2. 単体テストのテスト項目
- すべての分岐条件を検証できるか
- すべての限界値を検証できるか
- すべての定数・変数の初期値と値の変化を検証できるか
- すべての引数・リターンコードを検証できるか
- すべてのメッセージを検証できるか
- すべての資源の消費を検証できるか
2-3. 統合テストの仕様書・テストケース
- モジュール間、コンポーネント間、サブシステム間、外部接続をすべて検証できるか
- 接続先のすべての状態（起動、停止、異常、プロセス起動時、プロセス終了時等）を設定したか
- すべてのデータベースやファイル入出力をテスト可能か
- 想定できるすべてのパフォーマンステスト・負荷テストを設定したか
- ユーザの操作性や視認性など使い勝手についてのテストケースを設定したか
- 異常操作を含むすべてのユーザインターフェースをテスト可能か
2-4. 受け入れテスト・システムテストの仕様書
- オペレータや運用担当者と共にテスト仕様を検討したか
- 想定できるすべての業務シナリオについてテスト可能か
- 受入テスト、システムテストの仕様書はユーザにも理解可能か
- 本番環境（ハードウェア、ソフトウェア、ネットワーク、その他インフラ）を用いたテストは可能か
- 本番データを使用したテストは可能か
- 実際の操作者、運用担当者によるテストは可能か
- システム化対象のすべての業務プロセス（異常時も含む）を網羅したか
- 要件として定義されたすべての機能、非機能を検証できるか
- パフォーマンステストのテストシナリオ、ケースをすべて設定したか
- 本番環境での負荷テストを含んでいるか
- ユーザの操作性や視認性など使い勝手についてテストケースを設定したか
- 他システムとの接続を検証するためのテストケースをすべて設定したか
- 接続先外部システムのすべての状態（起動、停止、異常、プロセス起動時、プロセス終了時など）を設定したか
参考文献
「なぜ、システム開発は必ずモメるのか？49 のトラブルから学ぶプロジェクト管理術」 細川義洋,日本実業出版社