ソフトウェア評価 step3 テスト技法と選別基準

どういった記事なのか

テストエンジニアとしてテスト設計・テスト実施管理等を行ってきた経験から、
ソフトウェア評価について記事をまとめていく予定

step3として、テスト設計を行ううえで、どのようなテスト技法がありるかと、
テストを選別する基準を簡単にまとめる

どんな人間が書いているか

プログラマー歴10年ちょいの初心者
ITに関わった当初はテストエンジニア、その後プログラマー・SEに転身
C# -> php -> ruby とプログラム未経験から職場とともにメイン言語を渡り歩いてきた

テスト設計におけるテスト技法の選別基準

1. テスト技法の種類と長所短所

1.1 同値分割

入力データをグループ（同値クラス）に分け 各グループから代表値を1つ選んでテストする技法

• 長所: テストケースを効率的に減らすことができる 繰り返しのテストが不要になる
• 短所: 境界付近のバグを見逃しやすい 特に異常値に弱いケースがある

テスト例

• パスワード入力欄に「6～12文字の英数字」とする場合
  • 同値クラス: 6文字未満 6～12文字 12文字超過
  • テストデータ例: "12345"（境界外） "123456"（境界内） "123456789012"（境界内） "1234567890123"（境界外）

1.2 境界値分析

入力の境界付近の値（最大値や最小値）を重点的にテストする技法

• 長所: 境界で発生しやすいバグを検出できる 同値分割と組み合わせることで効果が増す
• 短所: 境界以外のエリアのテストが薄くなることがある

テスト例

• 入力可能な年齢範囲が「18～65歳」の場合
  • テストデータ例: 17（境界外） 18（境界内） 65（境界内） 66（境界外）

1.3 デシジョンテーブル

複数の条件とその組み合わせによる動作を網羅的に確認する技法

• 長所: すべての条件の組み合わせを整理しやすく 確実にカバーできる
• 短所: 条件が多いとテーブルが複雑になり扱いが難しくなる

テスト例

• ショッピングサイトの割引ルール
  • 条件1: 購入金額が10,000円以上
  • 条件2: メンバーシップあり
  • 条件3: クーポン使用
  • デシジョンテーブルを作成し 全8パターンを網羅

1.4 状態遷移テスト

システムや機能の状態変化をモデル化し 各状態間の遷移をテストする技法

• 長所: 状態遷移の異常や未処理の遷移を検出できる
• 短所: 状態が多い場合 テストケースが膨大になり管理が困難になる

テスト例

• ATMの操作フロー
  • 状態: カード挿入 → 暗証番号入力 → 金額選択 → 出金完了
  • テストケース: 正常遷移 誤入力によるエラー遷移 カード未挿入の操作など

1.5 ペアワイズ法

複数の入力パラメータの組み合わせのうち 2つの組み合わせを全て網羅するようにテストする技法

• 長所: テストケースを効率よく減らしながら重要な組み合わせをカバーできる
• 短所: 全てのパラメータの組み合わせを網羅するわけではないので完全な保証にはならない

テスト例

• フォーム入力（年齢 性別 職業）の組み合わせ
  • パラメータ: 年齢（10代, 20代） 性別（男性, 女性） 職業（学生, 社会人）
  • 組み合わせ例: [10代, 男性, 学生] [20代, 女性, 社会人]など

1.6 エクスプロラトリーテスト

計画に基づかず実施する探索的なテスト技法 直感と経験に基づいてシステムの弱点を見つける

• 長所: 思いがけないバグを発見しやすい 柔軟で適応力が高い
• 短所: 体系的でないためテストの漏れやカバレッジの偏りが生じる可能性がある

テスト例

• 新しいUIで自由に操作して意図しない挙動を確認
• 操作順序を変えたり 意図的に異常値を入力してバグを探索

1.7 モンキーテスト

無作為な操作やランダムな入力を行い システムの異常動作を検出する技法

• 長所: 予測不能な状況下でのバグを発見できる
• 短所: 再現性が低く テストの信頼性が乏しい

テスト例

• アプリケーションで無作為に画面をタップしたり ランダム文字列を入力する

2. テストの選別基準

1. リスクの大きさ
   高リスクな機能や障害が発生すると重大な影響を及ぼす部分を優先してテストを行う

2. 変更の影響範囲
   コードや機能の変更による影響範囲を考慮し 影響が大きい箇所を重点的にテストする

3. ユーザーの利用頻度と重要度
   ユーザーが頻繁に利用する機能やシステムのコアとなる機能はテストの優先順位が高い

4. テストコストとリソース
   テストの実行に必要な時間やコスト・人的リソースを考慮し 効果的かつ効率的にテストを実施

5. 過去のバグの発生傾向
   過去にバグが多発した箇所や特定のモジュールは再度バグが発生するリスクが高いため重点的にテストする

6. テストの実施可能性
   テスト環境や条件が揃っているかを確認し 実施が容易なテストから始める

3. テスト技法選定のプロセス

1. プロジェクト要件の整理
   テスト対象の機能範囲 優先度 リスクを明確化する

2. 技法の適合性評価
   技法がプロジェクト要件に適しているかを評価する

3. リソース評価
   利用可能なリソースを考慮して選定する

4. 技法の組み合わせ
   単一の技法に頼らず複数技法を組み合わせて効率的なテストを実現する

4. テストケースの管理方法

1. テストケース設計のベストプラクティス
   一つのテストケースには具体的で簡潔な目的を持たせる
   再利用可能な構造を意識して設計する

2. テスト管理ツールの利用
   テストケースを効率的に管理するためにテスト管理ツールを活用

   • 例: TestRail, Zephyr, TestLinkなど

5. テスト技法選定の事例紹介

1. ウェブアプリケーションの事例

   • 課題: 多くのユーザーがアクセスするECサイトのログイン機能
   • 選定技法: 同値分割 境界値分析 ペアワイズ法
   • 結果: 入力エラーやタイムアウトエラーの検出に成功

2. モバイルアプリの事例

   • 課題: 機能が複雑なチャットアプリの状態管理
   • 選定技法: 状態遷移テスト エクスプロラトリーテスト
   • 結果: 異常遷移のバグを検出し ユーザー体験の向上に寄与

6. テスト技法選定後の最適化

1. フィードバックループの活用
   テスト結果を分析し 技法の適用範囲を調整する
   必要に応じて技法を追加または除外する

2. 自動化の推進
   繰り返しが多いテストケースについては自動化を検討
   ペアワイズ法やモンキーテストは自動化に適している

---

まとめ

プロジェクトごとに適切なテスト技法を選定し その組み合わせと管理を徹底することで 効率的で網羅的なテスト設計を可能にする

効率と効果のバランスを保ちつつ クリティカルな成果を目指してテスト設計を進めてほしい