ソフトウェア評価 step2 テスト技法と選別基準
どういった記事なのか
テストエンジニアとしてテスト設計・テスト実施管理等を行ってきた経験から、
ソフトウェア評価について記事をまとめていく予定
step2として、テスト設計を行ううえで、どのようなテスト技法がありるかと、
テストを選別する基準を簡単にまとめる
どんな人間が書いているか
プログラマー歴10年ちょいの初心者
ITに関わった当初はテストエンジニア、その後プログラマー・SEに転身
C# -> php -> ruby とプログラム未経験から職場とともにメイン言語を渡り歩いてきた
テスト設計におけるテスト技法の選別基準
1. テスト技法の種類と長所短所
1.1 同値分割
入力データをグループ（同値クラス）に分け 各グループから代表値を1つ選んでテストする技法
- 長所: テストケースを効率的に減らすことができる 繰り返しのテストが不要になる
- 短所: 境界付近のバグを見逃しやすい 特に異常値に弱いケースがある
1.2 境界値分析
入力の境界付近の値（最大値や最小値）を重点的にテストする技法
- 長所: 境界で発生しやすいバグを検出できる 同値分割と組み合わせることで効果が増す
- 短所: 境界以外のエリアのテストが薄くなることがある
1.3 デシジョンテーブル
複数の条件とその組み合わせによる動作を網羅的に確認する技法
- 長所: すべての条件の組み合わせを整理しやすく 確実にカバーできる
- 短所: 条件が多いとテーブルが複雑になり扱いが難しくなる
1.4 状態遷移テスト
システムや機能の状態変化をモデル化し 各状態間の遷移をテストする技法
- 長所: 状態遷移の異常や未処理の遷移を検出できる
- 短所: 状態が多い場合 テストケースが膨大になり管理が困難になる
1.5 ペアワイズ法
複数の入力パラメータの組み合わせのうち 2つの組み合わせを全て網羅するようにテストする技法
- 長所: テストケースを効率よく減らしながら重要な組み合わせをカバーできる
- 短所: 全てのパラメータの組み合わせを網羅するわけではないので完全な保証にはならない
1.6 エクスプロラトリーテスト
計画に基づかず実施する探索的なテスト技法 直感と経験に基づいてシステムの弱点を見つける
- 長所: 思いがけないバグを発見しやすい 柔軟で適応力が高い
- 短所: 体系的でないためテストの漏れやカバレッジの偏りが生じる可能性がある
1.7 モンキーテスト
無作為な操作やランダムな入力を行い システムの異常動作を検出する技法
- 長所: 予測不能な状況下でのバグを発見できる
- 短所: 再現性が低く テストの信頼性が乏しい
2. テストの選別基準
-
リスクの大きさ
高リスクな機能や障害が発生すると重大な影響を及ぼす部分を優先してテストを行う
リスクが高いほど優先度も高くなる -
変更の影響範囲
コードや機能の変更による影響範囲を考慮し、影響が大きい箇所を重点的にテストする
特に結合テストや回帰テストでの選別が重要 -
ユーザーの利用頻度と重要度
ユーザーが頻繁に利用する機能やシステムのコアとなる機能はテストの優先順位が高い
ユーザー目線での影響度を考慮する -
テストコストとリソース
テストの実行に必要な時間やコスト・人的リソースの可用性を考慮し、効果的かつ効率的にテストを実施する 無駄なテストは排除 -
過去のバグの発生傾向
過去にバグが多発した箇所や特定のモジュールは再度バグが発生するリスクが高いため重点的にテストする -
テストの実施可能性
テスト環境や条件が揃っているかを確認し、実施が容易なテストから始める
実行可能性の低いテストは後回しにする
まとめ
ソフトウェア評価の歴史は長く、バグを検知するために様々な技法が考案されてきたが、
全てを網羅してテストすることはリソース的に現実的ではない
そのため、プロジェクトごとに適切なテストを選別することによって、
クリティカルに成果を上げていかなければならない
そのための指針として上記を頭に入れて設計に進んでいってもらいたい
Discussion