【ISTQB /JSTQB ALTA 解説】1.7 テスト実行(Test Execution)完全解説|具体例付きで理解しよう

JSTQB Advanced Level Test Analyst

はじめに

本記事では、ISTQB Advanced Test Analystの第1章「テストプロセス」における最後のトピック、**1.7 テスト実行(Test Execution)**をわかりやすく解説します。

テスト実行は、テストプロセス全体の中で最も重要なフェーズのひとつです。

ここでは、テストケースの実行方法・結果の確認・欠陥報告・実行時の注意点などを、実践的な観点からまとめています。


1. テスト実行とは?

テスト実行(Test Execution)とは、テスト設計・テスト実装フェーズで作成したテストケースを実際に実行し、アプリケーションが期待どおりに動作するかを確認する工程です。

このフェーズでは、以下のような活動が行われます:

  • テストスイートの順序や優先順位に従って実行する

  • 実行結果(実際の結果と期待結果)を比較して、合否を判断する

  • 不具合(バグ)を発見したら、詳細な欠陥報告を作成する

  • 実行進捗をモニタリングし、障害やボトルネックを解消する

テスト実行フェーズは、テストアナリスト・テストマネージャー・テスター全員が最も活発に動くステージです。


2. テスト実行前に確認すべきこと

テスト実行を始める前に、**「エントリ基準(Entry Criteria)」**を必ず満たしているかを確認します。

これは前工程(テスト実装)で決められた条件のことで、以下のようなチェック項目が含まれます:

  • テスト環境が準備完了しているか

  • テストデータやツールが利用可能か

  • テストスイート(実行セット)が完成しているか

  • 欠陥修正が完了しているか

すべての条件が整って初めて、テスト実行を「開始(kick-off)」できます。


3. 実行結果の確認と「誤判定(False Positive / False Negative)」

テスト結果を判定するとき、「期待結果」と「実際の結果」を正しく比較することが非常に重要です。

この際によく起こるのが、**誤った判定(False Positive / False Negative)**です。

用語

意味

False Negative(偽陰性)

実際には成功しているのに、失敗と判断してしまう誤り

システムが正しく動作しているのに「失敗」と記録してしまう

False Positive(偽陽性)

実際には失敗しているのに、成功と判断してしまう誤り

エラーが発生しているのに「成功」と誤って記録する

テストアナリストは、テストログや実行結果のレビューを行い、こうした誤判定を防ぐ責任があります。


4. 欠陥(Defect)の記録と管理

テスト中に期待結果と実際の結果が一致しない場合、それは**欠陥(Defect)です。

発見した欠陥は、以下の情報を含めて詳細な欠陥報告書(Defect Report)**として記録します:

  • 不具合が発生したテストケース名

  • 手順・環境・再現条件

  • 実際の結果と期待結果

  • スクリーンショットやログなどの証拠

  • 発生頻度や影響範囲

この情報が充実していないと、**根本原因分析(Root Cause Analysis)**が難しくなります。

テストアナリストは、報告内容が正確かつ完全であるかを確認し、チーム全体の品質を高めます。


5. 外部チームや顧客が関わる場合の注意点

特に**アジャイル開発や受け入れテスト(UAT)**では、ビジネスユーザーや顧客自身がテスト実行に参加することがあります。

ただし、以下の点に注意が必要です:

  • 顧客はプロダクトの全体仕様に詳しくない場合がある

  • 検出できる欠陥の数が限られる(経験不足・観点不足)

そのため、内部のテストチームが主要な欠陥を先に発見しておくことが重要です。

顧客によるテストは、品質確認ではなく「信頼確認」の意味合いが強いと理解しておきましょう。


6. テスト実行中に重視すべきポイント(テストアナリストの視点)

① 不自然な挙動(Irrelevant Oddities)を見逃さない

「なんとなくおかしい」「一瞬遅い」「想定外の動きがある」など、一見問題なさそうに見える小さな異常が大きな欠陥の前兆である場合があります。

氷山の一角のようなサインを見逃さず、追加テストで深掘りするのがプロのアナリストです。

② 正常系だけでなく、異常系テストも実施する

ポジティブテスト(要求どおりの入力)だけでなく、**ネガティブテスト(不正なデータや操作)**も設計・実行します。

例:

  • 必須入力欄を空欄にする

  • 数値欄に文字を入力する

  • 許可されていない操作を試す

これにより、製品が「やってはいけないことをしていないか」を検証できます。

③ テストスイートは継続的に拡張・更新する

ソフトウェアが進化すれば、テストスイートも進化します。

新しい機能追加や変更に合わせて、テストケースを増やしたり修正したりすることが重要です。

④ 次回リリースに向けたメモを残す

テスト中に「次のバージョンで検討すべき課題」などをメモしておくと、次の開発サイクルで役立ちます。

改善サイクルを回すことが品質向上の鍵です。

⑤ 全てのテストを再実行しない

手作業で全テストケースを再実行するのは非効率です。

リスクベースドアプローチや自動化テストを活用し、重要度に応じて効率的に再実行しましょう。

⑥ 探索的テスト(Exploratory Testing)の結果も正式に記録

探索的テストで得られた気づきは、新たな正式テストケースとして再利用できます。

「偶然見つけた不具合」も、文書化して再現可能な形にしておくのが理想です。

⑦ 回帰テスト前にできる限り欠陥を見つける

回帰テスト(Regression Testing)は「既存機能が壊れていないか」の確認ですが、新しい欠陥を発見する段階ではないという意識が重要です。

できるだけ前工程で欠陥を検出しきることが、納期遅延の防止につながります。


まとめ:テスト実行は「品質保証の心臓部」

テスト実行フェーズは、単にテストを「実施する」だけではありません。

品質を見極める・問題を早期発見する・次の改善につなげるための重要なステップです。

テストアナリストは、実行中の状況を常に把握し、正確な報告・効果的な欠陥管理・継続的な改善提案を行うことが求められます。


💡例題(理解チェック)

質問:次のうち、テスト実行フェーズにおけるテストアナリストの責任として最も適切なものはどれですか?

A. テスト戦略の作成

B. テスト環境の構築

C. 実行結果のレビューと誤判定の検出

D. プロジェクトリスクの分析

正解:C

テストアナリストは実行段階で結果のレビューを行い、False PositiveやFalse Negativeを防ぐ役割を担います。

コメント

タイトルとURLをコピーしました