【ISTQB /JSTQB FL 4.0対策】Part #20|探索的テスト・チェックリストベース・シナリオ形式・ユーザーストーリー・DevOpsパイプライン

JSTQB Fundation Level 4.0

この記事では、

実際の試験で出題されやすい5つの問題を日本語で丁寧に解説します。


🧩 質問1:探索的テスト(Exploratory Testing)を使うべき理由

問題:

次のうち、探索的テストを使用する最も適切な理由を2つ選びなさい。

選択肢:

A. テスト設計と実行に十分な時間が与えられていない場合

B. 既存のテスト戦略が正式なブラックボックステスト設計技法の使用を求めている場合

C. 仕様がツールで処理可能な形式で書かれている場合

D. テスターがアジャイルチームの一員であり、プログラミングスキルを持っている場合

E. テスターが業務ドメインの知識と優れた分析力を持っている場合

正解:A と E

解説:

探索的テストは、時間や仕様が限られた状況で、

テスターの経験・直感・分析力を活かしてテスト設計と実行を同時に行う手法です。

  • A:時間がない中で、計画よりも柔軟な探索が必要なときに有効。

  • E:業務知識が深く、システムを理解しているテスターが探索的にテストすることで、多くの潜在的欠陥を発見できる。

例:

新しい決済システムを短期間で評価する必要があり、仕様書が未完成の場合、

ドメイン知識のあるテスターが探索的にシナリオを進めることで、重大なバグを早期に見つけられます。


🧾 質問2:チェックリストベーステストの要素

問題:

次のうち、チェックリストベーステストのチェック項目として最も適切なのはどれか?

選択肢:

A. 開発者が実装中にエラーを犯したこと

B. ステートメントカバレッジが85%を超えたこと

C. 機能要件と非機能要件に関してプログラムが正しく動作していること

D. エラーメッセージがユーザーに理解できる言語で書かれていること

正解:D

解説:

チェックリストベーステストは、「確認リスト」をもとにソフトウェアを検証するテスト手法です。

ユーザー視点で「確認すべき項目」が明確であり、定性的な品質の確認に有効です。

例:

チェック項目例:

  • 入力エラーが発生した際に、ユーザーが理解できる日本語でメッセージが表示されるか?

  • 操作ガイドがユーザー層に適した言葉で書かれているか?


🧠 質問3:「Given-When-Then」形式の受け入れ基準

問題:

次のユーザーストーリーの受け入れ基準は、どの形式で書かれているか?

「ユーザーがホームページにログインしている状態で、“商品追加”ボタンをクリックすると、商品登録フォームが表示され、商品名と価格を入力できる。」

選択肢:

A. ルール指向形式(Rule-oriented)

B. シナリオ指向形式(Scenario-oriented)

C. プロダクト指向形式(Product-oriented)

D. プロセス指向形式(Process-oriented)

正解:B

解説:

この書き方は、「Given(前提条件)」「When(操作)」「Then(期待結果)」 で構成される

「シナリオ指向形式」で、行動駆動開発(BDD)でよく用いられます。

例:

  • Given:ユーザーがログインしている

  • When:商品追加ボタンを押す

  • Then:商品登録フォームが表示される

このように、実際のユーザー操作を中心に受け入れ基準を明確化します。


🛒 質問4:ユーザーストーリーに「関係しない」テストケース

問題:

次のユーザーストーリーに対して、関係のないテストケースを選びなさい。

「登録済みの顧客として、自分の過去の注文履歴をウェブサイトで確認したい。」

選択肢:

A. 顧客が自分のアカウントにログインし、「注文履歴」ボタンをクリックする → システムが日付・注文番号・合計金額を含む注文履歴を表示する

B. 顧客が特定の注文をクリックすると、その注文の詳細(商品名・価格・数量)が表示される

C. 顧客が「昇順に並べ替え」ボタンをクリックすると、注文履歴が注文番号順に並び替えられる

D. 未登録の顧客が新規登録を行い、メールアドレスを入力してアカウントを作成する

正解:D

解説:

このユーザーストーリーは「登録済みの顧客」が注文履歴を閲覧する機能についてのもの。

「未登録顧客の新規登録」は別機能のテストであり、関連しません。

例:

Amazonで「注文履歴を確認」するテストと、「新規会員登録」のテストは明確に目的が異なります。


⚙️ 質問5:DevOpsパイプラインにおけるエントリ基準

問題:

あなたのチームはDevOpsパイプラインに従って開発を行っている。

最初の3つのステップは以下の通り:

  1. コード開発

  2. コードをバージョン管理システムに提出し、テストブランチにマージする

  3. コンポーネントテストを実行する

次のうち、ステップ2に入る前のエントリ基準として最も適切なのはどれか?

選択肢:

A. 静的解析の結果、重大度の高い警告がないこと

B. バージョン管理システムにマージ時の競合が発生しないこと

C. コンポーネントテストがコンパイルされ、実行準備ができていること

D. ステートメントカバレッジが80%を超えていること

正解:A

解説:

DevOpsの自動化パイプラインでは、品質を維持しながら継続的デリバリを行うことが重要です。

静的解析ツールで重大な問題がないことを確認してから、リポジトリへ統合するのが正しい手順です。

例:

  • SonarQubeなどでコード解析を実施し、セキュリティリスクや重大なバグを事前に防ぐ。

  • 問題がある場合は修正してからマージする。


✅ まとめ

テーマ

ポイント

試験での狙いどころ

探索的テスト

時間や仕様が限られる状況で有効

テスターの知識・分析力重視

チェックリストベース

明確な確認項目で品質を評価

ユーザー視点の確認

シナリオ形式

「Given-When-Then」で定義

行動駆動開発(BDD)

ユーザーストーリー

関係のないテストを除外

スコープ意識の確認

DevOps基準

静的解析の通過

品質保証とスピードの両立

コメント

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