｢バグの出ないテスト｣に潜むシステム開発の危険 最後の砦､｢確認の確認｣まで怠ってはいけない

品質確保の第一歩。管理職、経営層の立場でもやることはある。

管理職や経営者の立場で「テスト」の際に気をつけるべきこととは（写真：paradax / PIXTA）

特集「文系管理職のための失敗しないDX」の他の記事を読む

『週刊東洋経済』2023年3/4号では「文系管理職のための失敗しないDX」を特集。アマゾンでの購入はこちらから。

要件定義、設計、開発、テスト、リリースの流れで進めていくウォーターフォールモデルの場合、各設計と対になる観点でテストを実施する。これをV字モデルという。

テストは開発に近い設計（詳細設計）から開始する。単体テストは、1つのプログラムに焦点を当て、設計したロジックどおりに稼働するか確認する。条件分岐や限界値、境界値における処理の正しさ、エラー時の動作などを確認する。

結合テストは、それら一つひとつのプログラムを結合し、合わせ技での動作を確認する。例えば入力画面の項目Aに入れた値が、変換処理を経て確認画面の項目Aエリアに変換後の値で表示されることを確認する、といった具合だ。

発注元でないと実施が難しいテストも

総合テストとユーザー受け入れテストは、要件定義の内容を確認する。2つの違いは、前者は開発者自ら実施するのに対し、後者は発注元が納品の検証として実施する点だ。

やや重複感があるが、総合テストはシステム要件定義、ユーザー受け入れテストは業務要件定義との整合性に主眼を置く。またシステムを使わない業務を含めた確認は、発注元でないと実施が難しい。

これらのテストをクリアして、リリース（業務開始）となる。