テストというと、
「バグを見つける工程」というイメージが強いかもしれません。
しかし応用情報技術者試験では、
テストを単なる不具合検出ではなく、
品質を保証するための意思決定として捉えられているかが問われます。
この回では、
テストは「バグを見つける作業」ではない理由を、
応用情報視点で整理します。
テストの目的は「合格判定」
テストの本質は、
「不具合を見つけること」ではなく、
この品質で出してよいかを判断することです。
- 要件を満たしているか
- 期待した振る舞いをするか
- 重大なリスクが残っていないか
応用情報では、
テストは品質の“合格判定”のためにある、という視点が重要です。
バグがゼロでも失敗する
バグが見つからないことは、
「問題がない」ことを意味しません。
- そもそも要件が間違っている
- 重要な観点で試していない
- 現場の使い方に合っていない
この状態では、
テストは通っても運用で失敗します。
応用情報は、
テストを「現実に耐えるか」の確認として捉えています。
何をテストすべきかは、設計で決まる
テスト項目は、
場当たりで増やすものではありません。
- 要件
- 設計
- リスク
- 影響範囲
から逆算して、
確認すべきことを決める必要があります。
応用情報では、
テストを“設計の延長”として扱えるかが問われます。
応用情報での典型的な出題意図
午後問題では、
- テストは実施した
- しかし事故が起きた
という状況が描かれます。
このとき問われるのは、
「テストをしたか」ではなく、
何を確認できていなかったかです。
実務で効く考え方
実務でテストの価値が出るのは、
- 仕様の曖昧さを炙り出す
- 影響範囲を見える化する
- リスクに優先順位をつける
といった、
開発チームの判断を支えるときです。
応用情報は、
テストを「工程」ではなく「判断装置」として捉える視点を要求します。
まとめ
- テストは不具合探しではなく合格判定
- バグゼロでも要件・観点がズレると失敗する
- 応用情報は“何を確認したか”を問う
テストを見るときは、
「何を証明したいのか」
から考えることが重要です。
次回予告
次回は、
「障害対応で一番大事なものは何か」
を扱います。
開発から運用へ、さらに踏み込みます。
コメント