システムが本番で使用される前に期待通りの動作をするか確認します。

もしも、動作しない場合は、その故障が修正され、再テストを実施して本番でも正しく動くことを証明します。

テストを実施する他に、下記の様々な活動がありそれをテストプロセスと言います。

1.テスト実施前作業

・テスト計画

テストの準備作業、リソース配分、作業内容、テスト終了基準決定を計画します。

効率的なテストの実施と品質向上をサポートします。


・テスト分析

何をテストするのか明確化します。

テスト対象を理解して詳細な設計と効果的な計画を画策することによって、テストの効率性の上昇と品質向上することが可能です。


・テスト設計

テストを実施するための情報を収集して、テスト条件を網羅して確認できるようにテストケースを設計します。


・テスト実装

テスト計画で定義された内容を具現化して、テストの実行に必要なものを準備します。

2.テスト実施時の作業

・実行結果のチェック

テストケースを実施してその結果の確認を行います。

エビデンス(実施時の画像・映像)を　残しておき、NG項目があった場合修正して正常な動作を確認できるまでテストを実施します。

ソフトウェアの品質や機能が適切に検証され、問題点が発見されることで品質向上します。


・テスト終了基準の評価

計画時に決定した終了基準を満たしているか評価します。

3.テスト完了作業

・テスト結果の報告

テスト実施結果、NG項目の対応・結果、終了基準の達成度合いなどを報告します。


・テストウェアの整理

テストプロジェクトが終了した時に、完了したテストのデータを集めて資産化して次のテストに引き継ぎます。

①作業成果物の評価

・作業青果をレビューする中で正しく書かれていること以外に、誤解がないような表現で記載されているか、重複していないかなどについても確認します。

・目的にする場合は、観点をあらかじめ洗い出しておき、成果物が完成した段階で確認を行います。

②すべての要件を満たしていることの検証

・テスト対象となる作業成果物、コンポーネントやシステムが要件を満たしているか検証する必要があります。

③期待通りの動作内容であることの妥当性確認

・受け入れテストでは、テスト対象に対して、ユーザーやステークホルダーが期待していると思われる動作内容を確認します。

※受け入れテストでは欠陥の検出を目的とはせず、ソフトウェアの品質確認を行い、どのようなリスクがあるのかステークホルダーに提供するために行われることがある。
　　

④テスト対象の品質が所定レベルにあること

・「すべての要件を満たしていること」「故障や欠陥の発見」「期待通りの動作内容であることの妥当性確認」を検証した結果を開発メンバー、プロジェクトマネージャーに伝えることができますが、テストの結果をメトリクスを使用して確認する必要がありま　　す。

⑤欠陥作り込みの防止

・テストで検出した故障と修正した欠陥の原因分析を行い、評価観点に分析結果を取り入れることで、同じ欠陥を発生させることを防止します。

⑥故障や欠陥の発見

・テストの主な目的となり、テストを実施してなるべく多くの故障を発見してソフトウェアの欠陥を特定して修正することです。

⑦ステークホルダーが意思決定できる、十分な情報の提供

・テストを行った結果、品質が所定のレベルであることを確証できない部分についても評価対象になります。

※欠陥によりどのような影響があるのか、回避策はあるかなどの考慮も必要

⑧不適切なソフトウェア品質のリスクレベルの低減

・これを目的としたテストをする際に必要となるのがリグレッションテスト。

※リグレッションテストとは、すでにテストしたソフトウェアを何回もテストをして、変更によって発生した欠陥を見つけ、修正によって混入された別の欠陥を発見するこ　とを検出することが目的のテストのこと

⑨契約上、法律上の要件を遵守し、テスト対象が要件に準拠していることの検証

・システムが使われる業界によって、独自の要件や標準を遵守する必要があり、これらに遵守したテストを行う必要があります。

①テストは欠陥があることは示せるが、欠陥がないことは示せない

テストをしても「完全な正しさ」や「絶対にバグがないこと」を証明することはできません。

②全数テストは不可能

すべてをテストすることは、ごく単純なソフトウェア以外では非現実的です。

システムが大規模かつ複雑になるほど、すべての可能性や状況をテストするのは非常に時間がかかり、ソースが必要になります。


そのため、全数テストの代わりにテスト技法、テストケースの優先順位付け、リスクベースドテストを用いてテストを実施すべきです。

※全数テストとは、ソフトウェアに入力する可能性のあるデータとテストを行う時の条件のすべてのパターンをテストすること

※リスクベースドテストとは対応するリスクのタイプとリスクのレベルに基づき、テストの活動とリソースの利用をマネジメントし選択し優先順位付けするテストのこと

③早期テストで時間とコストを節約

早い段階で欠陥を見つけるために、静的テストと動的テストの両方をなるべく早い時期に開始する必要があります。

もしも、欠陥を作成してしまった時期から離れてしまうほど、それによって発生する連鎖的な欠陥や問題や修正のコストは大きくなります。

④欠陥の偏在

テストで見つかる欠陥や運用時の故障はある部分に集中していることがよくあります。

これは、ソフトウェアの開発は複数のチームで分担することがあること、エンジニアの開発スキルが不足していたこと、実装難易度が高いこと、リソースが不足していたことなどの原因によって、欠陥が集中的に発生します。

⑤テストの弱化

何回も同じテストを繰り返すと、新たな欠陥を検出することが難しくなります。

これを「殺虫剤のパラドックス」といいます。


これを回避するためには、テストとテストデータを定期的に見直して、改定したり新規のテストを作成する必要があります。

しかし、殺虫剤のパラドックスが有効だと言える場合もあり、リグレッションテストがそれに当てはまります。

⑥テストは状況次第

ソフトウェアが使用される状況が異なればテスト方法を変更する必要があります。

⑦「欠陥ゼロ」の落とし穴

すべての要件をテストして、欠陥を完全に修正したとしても、ソフトウェアとして機能しない場合があります。

修正を行う際は機能や性能、システム全体に影響は出ないかを確認してから修正を行う必要があります。

1.静的テストとは
プログラムコードを実行せずに、ドキュメントやソースコードなどのチェックによって誤りや脆弱性を検出するテスト手法のことであり、ソフトウェア開発の初期段階でエラーを発見することにより品質を向上させることを目的としています。

2.動的テストとは
プログラムコードを実行して、その結果からソフトウェアのバグ検出や品質評価、動作確認を行うテスト方法のことであり、プログラムの品質評価やバグ検出、動作確認を目的としています。



参考資料：ソフトウェアテスト教科書JSTQB Foundation　第4版

参考サイト：【JSTQBシラバス解説】新ソフトウェアテストの7原則 | テストエンジニア大学 (test-engineer-university.com)　JSTQB FLのまとめ 第一章 テストの基礎① #テスト - Qiita