ソフトウェア開発プロジェクトでは、単体/結合/総合/受入試験と製品開発の工程により観点の異なる試験フェーズが存在している。

試験の目的の1つは、

「ユーザが利用しているとき、故障が発生しないよう、事前にあらゆる種類の故障を見つけておくこと」

である。 しかし、現実的に全てのバグを発見することは難しい。

そこで、「良い試験項目」を作成し、限られた時間内に多くのバグを見つけることを行う必要がある。 今回は試験工程（単体、結合、総合）で試験内容の粒度・観点について説明すると

それだけで相当な文書量になるため、「良い試験項目とは?」として押さえておかなければいけない点を説明したい。

「良い試験項目」とは

• 試験実施の方法が説明してあること
• 期待値（捜査の結果）が明示してあること
• 「試験日、担当、結果」が記録されること
• バグを発見できる可能性が高い内容であること
• 重複がないこと
• 単純すぎず、複雑すぎないこと

試験項目を作成するときには、工程や手法によって異なるが「ソフトウェアテスト – Wikipedia」で説明されている点と同じように、

「バグはどうやって発生するのか?」

を考えながら試験項目を作成するとうまくいく場合が多い。

また、バグデータベース（過去の失敗事例、バグトラッキングシステム/BTS）があれば、過去の事例からバグを分析してみると参考になることが多い。

開発の現場でよく発生する例として

本来なら前工程で検出されなければいけないバグが、後工程でみつかることがある。

「なぜ、見つけなければいけない工程で漏れてしまい、後工程で見つかったのか?」

をプロジェクトメンバーが考えることが品質の向上、次のプロジェクトの分析材料になっていく。

過去のプロジェクトの失敗事例や「なぜ、バグが漏れたのか?」をチームで考え、

共有していくことが品質管理の第一歩だと考えている。

zeera document search

「バリバリ働きマン」「めんどくさがりさん」 zeera document search で仕事の効率Up!