テストとは
テストとは、
要求定義、要件定義、設計、コーディング の工程を経て実現したシステムが要求、設計された機能や性能を満たしているかその妥当性を検証する工程です。
システムの品質を確保するための工程で、この工程で不具合や仕様の誤りなどを検知できないと、不具合を抱えたまま本番稼働することとなってしまうため、非常に重要な工程と言えるでしょう。
この研修では、一般的なウォーターフォール開発で実施されるテストの目的や観点、手法などを理解し業務に活かすことを目的とします。
テストの必要性 ～そもそも品質とは？～
品質の定義
ISO/IEC 25000:2005という規格では、品質の定義を、
『指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフトウェア製品の能力』
としている。
言っていることは正しいが、それを満たすことは容易ではない…
でも基本的な考え方、進め方を理解、実践することで少しづつ品質の高い製品を提供することができる。
テストの必要性 ～1:10:100の法則～
なぜ品質が大事なのか
ソフトウェアの欠陥を修正するために必要とするコストでは、設計フェーズで検出した欠陥の修正コストを1とすると、その欠陥を試験フェーズで検出・修正すると10倍、運用フェーズでは100倍のコストが必要になるといわれる。
テストの必要性 ～システムダウンの原因別割合～
システムダウンの原因別割合
ソフトウェアの障害は全体の約30％として報告されている。
この実績は業務停止につながるもので、業務停止に至らないシステム障害を数えると、ソフトウェアの結果による障害は格段に多くなっているのが実態です。
テストの必要性 ～なぜ品質を高める必要があるか～
品質が悪いと…
品質が良ければ…
テストの必要性 ～品質特性、品質副特性～
要求品質の網羅性および水準を的確にとらえるための「品質特性」と「品質副特性」
このような計測基準の観点で品質観測することも有効。(現状ここまで実施しているプロジェクトはあまりない)
テストの必要性 ～テスト7原則～
先人たちのテスト経験からうまれたテスト7原則
- 欠陥があることしか示せない
欠陥があることは証明できても、欠陥がないことは示せない。
- 完全なテストは不可能
全ての条件、組み合わせは非現実的。リスク、優先順位に焦点をあてよ。
- 初期テスト
早い段階から欠陥を発見すればその分影響範囲は狭まる。
- 欠陥の偏在
欠陥は特定のモジュールに集中する事が多い傾向がある。
欠陥位置を予測してテストの焦点を絞るとよい。
- 殺虫剤のパラドックス
同じテストを繰り返すと新しい欠陥が見つからなくなる。新しいデータ、ケースで実施するように見直す。
- テストは条件次第
条件が異なれば、テスト方法も変わる。
使用される条件や目的に合わせてテスト内容、方法を変更する必要。
- 「バグゼロ」の落とし穴
欠陥を見つけて修正しても、構築したシステムが使えなかったり、ユーザの要件や期待を満足しなければ役に立たない。
テストの必要性 まとめ
- 稼働する前に欠陥を摘出して修正するならば、実行環境で問題が発生するリスクを低減できる。
- 摘出欠陥に基づき、ソフトウェアの機能／非機能要件や品質特性の観点から品質を計測できる。
V字モデルのテスト工程
ウォーターフォールのV字モデルにおける開発工程とテスト工程の関係。
V字モデルで左右を見比べることでどのレベルのテストか着目できる。
各テストの概要 ～単体テスト／UT～
概要
ソフトウェアを構成する最小単位である関数やメソッドに対して、設計書で要求された機能を満たしているかを検証するテスト。
単体テストは大きく分けてホワイトボックステストとブラックボックステストに分類できる。
ローカルPCに開発環境を構築して実施するケースが多い。
- 開発環境を素早く、また、基本的にはメンバー間で差異のない環境でテストする。
- 単体テストとは直接関係ないが、VirtualBoxやVagrant、Ansible、Dockerなどの構成管理ツールをうまく利用する。
現場のポイント
単体テストツールを利用し自動化すると、より効率的に進めることが可能となる。
- Java⇒JUnit
- NET⇒NUnit など
単体テスト仕様書(ケース)を作成し、画面やバッチを実行し確認する現場、案件もある。
各テストの概要 ～結合テスト／IT～
概要
単体テストで動作が確認されたモジュールを結合させてモジュール間のインターフェースがあっているか、結合した場合に正しく動作するかを確認するテスト。
テストのシナリオを作成し事前にデータを準備したり、他関係個所と調整しながら進めることもある。
結合テストの分類について、現場・案件によっては結合テストのインターフェースの連携先で名称、フェーズを分ける
- ITaやIT1：開発するシステム内で作成したコンポーネント間の結合テスト
- ITbやIT2：開発したシステムと他のシステムとの結合テスト
現場のポイント
計画結合テスト仕様書、実施範囲、実施方法、スケジュール、合格基準を事前に定義する。
単体テストとは異なり、他チーム・他システムと関係するため、スケジュールが厳密になる。
検出した欠陥をいつ修正するかを取り決める。
結合テストレベルの欠陥は基本的にリリースまでに対応する。
各テストの概要 ～システムテスト／ST～
概要
システム全体として要求された機能や性能を満たしているかどうかを検証するテスト。
総合テストや非機能テストとも呼ぶ場合もある。
本番と同じ環境で多角的にテストを行うことで、開発環境で検出できないバグや不具合を検知する。
アプリケーションのテストだけではなく、ハードウェアやOS、ミドルウェアなどのシステム全体が正常に動作することを確認する。(各種類については後を参照)
現場のポイント
計画システムテスト仕様書、実施範囲、実施方法、スケジュール、合格基準を事前に定義する。
品質特性、品質副特性の幅と深さを考慮して作成することが必要となる。
大規模開発案件の場合は、STチームが選任されて計画から準備、実施までを行う。(中規模案件位までであれば自身のチームで実施することもある)
システム開発最後のテストとなり、システム構成、リスク、期間、費用など総合的に判断し実施するテストの種類を決めることもある。(計画時に判断)
各テストの概要 ～システムテスト／ST～
システムテストの種類①
システムテストの種類②
各テストの概要 ～受入テスト／UAT～
概要
発注者が本来の目的や意図通りに稼働するかを検証する。
システムの欠陥を見つけることが目的ではなく、実際に業務として回る事を確認するためのテストとなる。
一般的にはシステムに対してその対価を払うべき品質となっているか、検収する作業。
現場のポイント
ユーザにテストを行ってもらうためには事前の計画と要員確保を調整しておかないと、ユーザがテストできないなどのケースが発生する。
全ての作業をユーザに任せるのではなく、テストをしてもらうための環境の準備や、必要に応じたタイミングの指示などを行いながらテストを進める。
ユーザから発生した指摘事項は「要望」「不具合(実装／仕様)」などを分類し、稼働までの優先度を計画・提案することが重要。。
ユーザの指摘だからといって、無条件に対応することが必要ではない。
各テストの概要 ～その他のテスト～
各テストの概要 まとめ
V字モデルにある開発工程とテスト工程から実施するテストの観点、範囲を意識する。
各テストを全て漏れなく実施する必要性はない。限られた期間、コスト（費用、人員）から必要なテストを選定し、実施しない・網羅性を抑えたテストの提案も行う必要がある。
結合テストの場合、リスクについてプロジェクトとして取り決めておくことも必要。
テストプロセス
各テストの計画、準備、実施、終了までの一連のプロセスを確認してみる。
案件、現場によって実施するテストの進め方は様々だが、各プロセスの進め方やポイントを抑えることでどのようなことをやる必要があるか理解する。
以上のようにテストも段階的に成果物を仕上げていく。
次は、テスト条件の洗い出しやテストケース作成に活用するテスト設計を確認してみよう。
テスト設計について
テスト設計とは…
テストとはプログラムを動かして、結果を確認する事だけがテストではない。
テストプロセスでも提示しているが、テストの為の操作、確認はテストの一部である。
テスト設計とは、必要な条件、ケースを網羅しているか、また、結果はどうあるべきかを事前に定めておくことである。
テスト設計を行う目的
- 誰でも実施できる状態となるように
- 誰が実施しても同じ結果が得られるように
- 結果の判断基準を明確にするように
- テストの実施対象に対する結果と欠陥時の証跡がわかるように
テスト設計について ～静的テスト／動的テスト～
静的テスト、動的テストの分類について
静的テスト：プログラムを実行しないで、プログラムテキストを解析することなどでテストを行なう。
動的テスト：テストケースをもとにプログラムを実行して、その結果を解析することによるテストを行なう。
テスト設計について ～ケースの洗い出しのポイント～
「機能」×「テスト観点」×「対象箇所」
テスト設計について ～テスト設計の手順～
① テスト条件（確認項目）の識別
確認すべき機能や動作を設計書から抽出し、その機能や動作の確認に必要な観点を設定する。
⇒テスト条件一覧にまとめる
※注意点
・「期待値」は具体的な内容であること。
×： ～が正しいこと。（「正しい」が曖昧）
・期待値に複数の状態を混在させないこと
×： OK、NGが混在するため管理が面倒
②条件分岐とパターンの洗い出し
条件を左右する要因＝「因子」と各因子に設定する段階（取りうる値）＝「水準」を識別し、因子と水準の組み合わせパターンを作る。
⇒デシジョンテーブルを作成する。
※デシジョンテーブル作成のポイント
・機械的に組み合わせを作成する事。（面倒だから、分ってるからと省かない）
・ありえない組み合わせは最後に除外する
テスト設計について
デシジョンテーブル補足
テスト設計について ～仕様ベース：同値分割・境界値分析～
デシジョンテーブルと同じ様にテストで必要な技法を説明します。
同値分割法：
仕様ベースのブラックボックステスト技法。同一の処理がされて同様の結果をもたらすことを期待できる入力セットや出力を想定し、テストケースを設計する手法。同じとみなせる入力領域（入力セット）や出力領域のことを同値クラスと呼びます。同値クラスは、正常系の同値クラスである有効同値クラスと、異常系の同値クラスである無効同値クラスに分かれます。
境界値分析：
同値分割した領域の端、あるいは端のどちらか側で最小の増加距離にある入力値または出力値のこと。
テスト設計について ～構造ベース：カバレッジとは～
カバレッジ：
テスト実施の網羅率。実装したソースコードに対してどれだけテストを行ったかを図る指標。網羅率が高ければ検証された状態となり、品質が高いであろうとみなせる。
カバレージ計測ツールを利用して計測する。
＜カバレッジの種類＞
・C0：命令網羅 ステートメント・カバレッジ … テストケースによって実行された行の割合
・C1：分岐網羅 ブランチ・カバレッジ … テストケースによって実行された分岐の割合
・C2：条件網羅 コンディション・カバレッジ … 条件式の全組み合わせの割合
テスト設計について ～カバレッジ：C０～
テスト設計について ～カバレッジ：C１～
テスト設計について ～まとめ～
テスト設計を行う目的
- 誰でも実施できる状態となるように
- 誰が実施しても同じ結果が得られるように
- 結果の判断基準を明確にするように
- テストの実施対象に対する結果と欠陥時の証跡がわかるように
- テスト技法を適切に実施する事で網羅率を測ることができる
テスト実施時の注意点
- テストと侮るなかれ：品質確保の砦である
- バグを憎んで人を憎まず：稼働前に見つかってよかったと思い、開発者非難となってはならない。
- 疑わしき目で確認すること：こんな簡単なケースにバグはないだろうと思っていると、必ず見逃す。常にバグが潜んでいることを念頭に持つこと。
テスト まとめ
- 品質の重要性を再認識し、計画建てたテストを実施することで、品質や効率的なテストを進めることができる。
- テストの範囲に関しては特に案件、現場で進め方、利用するツールなど様々であり、色んな現場の経験を積むことで自身のナレッジが溜まる。
- Ｖ字モデルにあるようにどの工程のテストかを意識しテスト計画、設計、分析、実施と進めていく。（これも結局案件、要件による）
- 機械的に実施するところと「感（経験値）」で進めるところの力加減が必要。
その他 頻出用語
※最新の情報の取得・更新に努めておりますが、掲載内容については、その正確性、完全性、有用性、最新性等についていかなる保証もするものではありません。