ここでは、実際の試験で出題される可能性が高いサンプル問題とその解説を紹介します。

理解のコツや、間違えやすい選択肢の見分け方も一緒に解説していきましょう。

🎯 第1問：テストピラミッド（Test Pyramid）の意味

問題：

「テストピラミッド」という用語は何を指しますか？

選択肢：

A. チームのテスト作業量はスプリントごとに増加する

B. バックログのサイズとテストの数はスプリントごとに減少する

C. 自動化された単体テストの数は、上位レベルの自動テストより多い

D. 自動テストの数はスプリントごとに増加する

正解：C

自動化テストの多くは「単体テストレベル（ユニットテスト）」に集中しています。

アジャイルでは**継続的インテグレーション（CI）**を行うため、単体レベルでの自動化が重要になります。

上位レベル（統合テスト、システムテスト）ほど自動化数は少なくなります。

💡ポイント：

テストピラミッドの形は「下が広く、上が細い」。

つまり「単体テスト（多） → 統合テスト（中） → システムテスト（少）」の構造です。

🧩 第2問：ブラウザ対応の新要件にどう対応すべきか？

シナリオ：

第5イテレーションの開始時、新しいブラウザタイプへの対応要件が追加されました。

既存の自動テストフレームワークはこのブラウザをサポートしていません。

テスターとして最も適切な対応はどれでしょうか？

選択肢：

A. テスターは残業して次の2スプリントで対応する

B. チームに報告し、リスク分析を実施。フレームワーク更新タスクをスプリント計画に追加

C. テスターが独自にリスクを低いと判断し、現行のスプリントを変更しない

D. テスターはすぐにブラウザ互換テストを設計し、他の作業を延期する

正解：B

アジャイルでは「チーム全体でリスクを共有し、スプリント計画を更新する」ことが重要です。

個人判断で進める（C）や独断で作業を止める（D）のはNG。

💡ポイント：

問題は「フレームワーク対応」がテーマ。

単なるブラウザ互換テストではなく、自動化基盤をどう更新するかに注目。

🤝 第3問：プランニングポーカー（Planning Poker）の不一致

シナリオ：

以下のユーザーストーリーに対して、リスク・複雑度などを考慮した見積もり結果は次の通り。

• 顧客：5

• 開発者：5

• テスター：20

この場合、チームとして最適な次のアクションは？

選択肢：

A. 顧客と開発者の見積もりが一致しているので、そのまま進める

B. テスターの理由を話し合い、再度プランニングポーカーを実施する

C. 顧客の見積もりを最優先として採用する

D. 全員の見積もりが完全に一致するまで繰り返す

正解：B

アジャイルでは「コラボレーション（協働）」が基本。

意見が大きくずれた場合、なぜテスターだけ見積もりが高いのかを議論し、再見積もりを行うのが正しい手順です。

💡ポイント：

見積もりは「対話による学習プロセス」。

一致させることより、理解のすり合わせが目的。

🧠 第4問：テスト関連の受け入れ基準（Acceptance Criteria）

問題：

次のうち、テスト関連アクティビティの「テスト可能な受け入れ基準」に該当するものを2つ選べ。

選択肢：

A. 構造ベーステスト（ホワイトボックス）はブラックボックスに加えて実施する

B. 機能リグレッションテストの80%以上が自動化されている

C. セキュリティテストの脅威分析で不具合が見つからなかった

D. 5000ユーザー同時アクセス時も性能が良好である

E. すべての主要ブラウザで正常に動作する

正解：B、C

BとCは「測定可能な条件」であり、受け入れ基準として適切です。

Aはテスト手法、D・Eは一般的な要件に過ぎません。

💡ポイント：

「テスト可能か？」がキーワード。

数値や結果が測定できる表現が◎。

🧭 第5問：探索的テスト（Exploratory Testing）に関する誤り

問題：

次のうち、「探索的テスト」に関して**誤っている（false）**ものはどれでしょう？

選択肢：

A. 探索的テストは学習・設計・実行を同時に行う

B. 探索的テストでは事前にテストアイデアを準備する必要がない

C. 探索的テストは他の手法と組み合わせると効果的

D. 探索的テストにはシステム理解が必要である

正解：B

探索的テストでも**テストチャーター（目的や観点）**など、一定の準備は必要です。

完全に即興ではありません。

💡ポイント：

「false」問題では、一見正しそうな選択肢が罠。

常に「テスト準備の重要性」を意識しましょう。

⚙️ 第6問：ALM（Application Lifecycle Management）ツールの目的

問題：

次のうち、ALMツール（例：Micro Focus ALM）の目的として正しいものはどれですか？

選択肢：

A. 開発とテストの知識ベースを構築する

B. コード変更やビルド品質の即時通知を行う

C. 分散チーム間でアプリケーションの現状を可視化する

D. テスト用に大量のデータ組み合わせを生成する

正解：C

ALMツールは「プロジェクトの全体状況を可視化し、進捗を共有する」ための統合プラットフォーム。

特にリモートチームや分散環境で効果を発揮します。

💡ポイント：

他の選択肢は一部のツール機能を指しているが、ALM全体の目的ではない点に注意。

📝 まとめ

💬 試験対策のコツ

• 「false」「not」など否定表現に注意。

  → 出題者は意地悪な言い回しを使うことがあります。

• シナリオ問題では、文中のキーワード（framework, plan, risk など）を拾う。

  → 話題の焦点を見抜くと、正しい選択肢が自然と浮かび上がります。

• ツール系問題は、特徴と目的を整理。

  → Configuration、Build、ALMなどの違いを明確に。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

その中で重要な役割を果たすのが、**クラウドコンピューティング（Cloud Computing）と仮想化ツール（Virtualization Tools）**です。

この章では、両者の基本的な仕組みと、アジャイル開発・テストでどのように活用できるのかを解説します。

🔹 クラウドコンピューティングとは？

クラウドコンピューティングとは、インターネット経由でサーバー・ストレージ・ネットワークなどのITリソースを利用する仕組みのことです。

簡単に言えば、「自分のパソコン上にないサーバーや環境を、ネット経由で使う」ことです。

✅ 具体例

• Google Drive：ファイルをクラウド上に保存し、どこからでもアクセス可能。

• AWS（Amazon Web Services）：テスト環境や本番サーバーをクラウド上に構築できる。

• GitHub Actions：クラウド上で自動テストを実行するCI/CD環境。

クラウドを利用することで、物理的なサーバーを設置する手間が省け、必要な時に必要なだけリソースを利用できる点が大きなメリットです。

🔹 仮想化（Virtualization）とは？

仮想化とは、1台の物理サーバーを「仮想的に複数のサーバー」に分割して使う技術です。

つまり、「1台のPCの中に、仮想的に複数のPCを作る」ようなものです。

✅ 具体例で理解する

例えば、あなたがデリーにいて、バンガロールにあるサーバーを使いたいとします。

その場合、バンガロールのサーバーを**仮想的に分割（virtualize）**し、その一部をデリーのユーザーが利用できるようにすることで、地理的に離れていてもスムーズにアクセスできます。

GoogleやFacebookのような大規模サービスも、仮想化の仕組みを使って世界中のユーザーに高速アクセスを提供しています。

🔹 アジャイルテストにおける利点

アジャイル開発では、短いスプリントごとにテストを繰り返すため、

「毎回物理サーバーをセットアップする」のは時間もコストもかかります。

そこで仮想化ツールやクラウド環境を使うことで、次のような利点が得られます。

🔹 スナップショット機能とは？

仮想化ツールの多くには、「スナップショット（Snapshot）」機能が備わっています。

これは単なるスクリーンショットではなく、システム全体の状態を丸ごと保存する機能です。

✅ 保存される情報の例

• OSの設定やネットワーク構成

• 実行中のアプリケーションバージョン

• サーバーとクライアント間の通信情報

• 実際のエラーログや負荷データ

このスナップショットを開発者と共有することで、

「テスト中に発生した不具合を再現しやすくなる」

という大きなメリットがあります。

🔹 よく使われるクラウド・仮想化ツール

🔹 テストへの応用例

例1：異なる地域からのアクセス検証

仮想化ツールを使い、東京・フランクフルト・ニューヨークなど異なる拠点から同一アプリにアクセスするテストを実施できます。

例2：負荷試験（Load Test）

クラウド環境上で数千人分のアクセスをシミュレーションして、サーバーがどこまで耐えられるかを確認。

例3：再現性の高いバグ報告

スナップショットを使って、問題が発生した時点の環境を再現。開発者に正確な状況を伝えることが可能。

🔹 まとめ

• クラウドコンピューティング：物理サーバーを使わずにネット経由で環境を利用

• 仮想化ツール：1台のサーバーを複数の仮想マシンに分割

• アジャイル開発に最適：短期間で繰り返すテストに対応、コストと時間を大幅に削減

• スナップショット機能：テスト環境の状態をそのまま保存・共有できる

クラウドと仮想化を上手に組み合わせることで、アジャイルテストの効率と品質は大幅に向上します。

ISTQB Agile Tester の試験でも、この2つの技術の概念理解が問われますので、しっかり押さえておきましょう。

🧩 補足：試験対策ポイント

• 「クラウド」と「仮想化」は似ているが異なる概念

• アジャイルでは物理サーバーよりも仮想・クラウド環境が主流

• 仮想化ツールの「スナップショット」機能の目的を説明できるようにする

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

この章では、ISTQB Agile Tester Extensionの**シラバス第3章（3.4.5）「テスト設計・実装・実行ツール」**で紹介されている代表的なツールとその役割を整理します。

1. テスト設計ツール（Test Design Tools）

目的

テスト設計ツールは、テストケースの作成を自動化または半自動化するために使われます。

特にアジャイル開発では、短期間で多くのテストを用意する必要があるため、設計ツールの活用は重要です。

主な機能

• コードを解析し、自動的にユニットテスト（JUnit, xUnitなど）を生成

• テストカバレッジを確認

• 入力条件・期待結果のテンプレート化

具体例

• JUnit / NUnit / TestNG：JavaやC#で広く使われるユニットテストフレームワーク

• Parasoft Jtest：コード解析とテスト生成を自動化

• EclEmma（Eclipseプラグイン）：カバレッジ可視化ツール

2. テストケース管理ツール（Test Case Management Tools）

目的

テスト管理ツールは、テストケースの作成・実行状況・結果・不具合管理を行うためのものです。

アジャイルでは「軽量な管理」が重視されます。

主な機能

• テストケース数・実行率・合格/失敗率のトラッキング

• テストサイクルの進行管理

• バックログ（ユーザーストーリー）との連携

具体例

• TestRail

• Xray（Jira連携ツール）

• Zephyr Scale

3. テストデータ生成ツール（Test Data Preparation & Generation Tools）

目的

大量のテストデータを準備するのは手作業だと非常に大変です。

そこで、ツールを使ってテストデータを自動生成し、さまざまな組み合わせのテストが可能になります。

主な機能

• ランダムデータやパターン化されたデータの生成

• データの一貫性チェック

• データマスキング（個人情報の保護）

具体例

• Mockaroo：オンラインでランダムデータ生成

• Data Factory（Pythonライブラリ）

• Test Data Manager（CA社）

4. テストデータロードツール（Test Data Load Tools）

目的

外部ソース（例：CSV、SQL、API）からテスト環境へデータを自動的に取り込み・同期するツールです。

手作業によるデータ入力を省き、テスト環境の再現性を高めます。

具体例

• DBUnit：データベースの状態を事前定義してテストに利用

• Talend Data Integration：ETL処理を自動化

• Postman + Newman：APIデータの自動投入

5. 自動テスト実行ツール（Automated Test Execution Tools）

目的

自動テスト実行ツールは、手動テストを自動化し、人的工数の削減・テストスピードの向上を実現します。

アジャイル開発では継続的インテグレーション（CI）やテスト駆動開発（TDD）、振る舞い駆動開発（BDD）に活用されます。

主な機能

• テストスクリプトの自動実行

• 結果レポートの自動生成

• JenkinsやGitHub Actionsとの統合

具体例

• Selenium / Cypress / Playwright（Webアプリ用）

• Appium（モバイルアプリ用）

• Cucumber（BDD対応）

6. 探索的テストツール（Exploratory Testing Tools）

目的

探索的テストでは、事前に定義されたテストケースが存在しないことが多いため、実行中の行動や発見を自動的に記録するツールが役立ちます。

主な機能

• スクリーンショットや動画の自動キャプチャ

• 実行手順や観察結果のログ化

• 不具合報告との連携

具体例

• TestBuddy / Exploratory Testing Chrome Extension

• Microsoft Test & Feedback（Azure DevOps連携）

• Session-Based Test Management（SBTM）ツール

7. アジャイル開発におけるツール活用のポイント

💡補足

アジャイルでは「すべてを自動化する」のではなく、

反復的で再利用可能な部分を自動化し、人間的な探索や発見を補うのが理想です。

例題（ISTQB Agile Tester Extension Sample Question）

Q. 以下のうち、探索的テストツールの特徴として正しいものはどれですか？

A. テスト結果を自動で比較し、差分を検出する

B. テストスクリプトをコードから自動生成する

C. 実行中の操作やスクリーンショットを記録する

D. データベースからテストデータを自動抽出する

✅ 正解：C

探索的テストツールは、テスターがシステムを操作する過程で得た観察・発見を記録するためのツールです。

スクリプトの自動生成やデータ抽出とは異なります。

まとめ

アジャイル開発では、スピードと柔軟性が求められるため、

テスト設計・実装・実行をサポートするツール群を組み合わせて使うことが重要です。

自動化ツールやデータ生成ツールを適切に導入することで、

• リリース速度の向上

• 手戻りの削減

• チーム全体の可視性向上

  が実現できます。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

このような変更の履歴を管理し、どのバージョンがどの成果物と対応しているかを明確にするのが「構成管理（Configuration Management）」です。

今回は、ISTQB Agile Tester Extension（アジャイルテスター拡張シラバス）の 3.4.4 構成管理ツール の内容を、具体例とともにわかりやすく解説します。

🔹 構成管理（Configuration Management）とは？

構成管理とは、**「変更履歴を管理すること」**を指します。

これは「バージョン管理（Version Control）」とも呼ばれ、次のような目的があります。

• どの成果物（要件書、テストケース、ソースコードなど）が、どの時点で、どのように変更されたかを把握する

• 新旧のバージョンを対応づけて、過去の状態をいつでも再現できるようにする

• 誰が、いつ、どんな変更を加えたのかを追跡（トレーサビリティ）できるようにする

アジャイルでは短期間で頻繁に変更が行われるため、構成管理ツールは特に重要な役割を果たします。

🔹 なぜアジャイルに構成管理ツールが必要なのか？

アジャイル開発では、スプリントごとに機能追加や修正が発生します。

例えば以下のようなケースがあります。

• バグ修正によりソースコードが変更される

• ユーザーストーリーの追加によりテストケースが更新される

• 要件の変更によりテスト結果レポートも修正が必要になる

これらをすべて手作業で管理するのは非常に大変です。

構成管理ツールを使うことで、変更の追跡・管理が自動化され、混乱や重複を防ぐことができます。

🔹 構成管理ツールで管理される主な対象

構成管理ツールは、単なるソースコード管理だけではありません。

以下のようなアーティファクト（成果物）をすべて管理できます。

このように、開発とテストの両方の成果物を統合的に管理するのが構成管理ツールの役割です。

🔹 バージョン管理の仕組み

構成管理では、成果物を「バージョン」として管理します。

例えば次のような流れで進みます。

1. チェックアウト（Check-out）：作業者がファイルをローカルにコピーして変更を開始

2. 変更（Edit）：コードや文書を修正

3. チェックイン（Check-in）：変更を保存し、新しいバージョンとして登録

これにより、どの変更がいつ行われたのかが履歴として残ります。

また、誤って新しいコードで不具合が出た場合でも、過去のバージョンに**簡単にロールバック（戻す）**ことが可能です。

🔹 バージョン管理システムの種類

バージョン管理システム（Version Control System, VCS）には主に2種類あります。

💡 例：

• 小規模チーム（1つの拠点） → SVNなどの集中型でも十分

• 大規模・リモートチーム（世界中に分散） → Gitのような分散型が便利

アジャイルチームでは、スピードと柔軟性を重視するため、

近年は Git（GitHub / GitLab / Bitbucket） のような分散型VCSが主流となっています。

🔹 構成管理ツール導入のメリット

1. 変更履歴のトレーサビリティを確保

   　どのコードや要件がどのテストで確認されたかを追跡可能。

2. リスクの軽減

   　間違った修正や削除があっても、すぐに以前のバージョンへ復元できる。

3. チーム間のコラボレーション強化

   　複数の開発者・テスターが同時に作業しても、変更の競合を最小限にできる。

4. 自動化との統合

   　CI/CD（継続的インテグレーション／デリバリー）ツールと連携し、自動テストや自動デプロイを実現できる。

🔹 実際のツール例

🔹 ISTQBサンプル問題（例）

問題：

アジャイルプロジェクトで構成管理ツールを使用する主な目的はどれですか？

選択肢：

A. テストケースの優先順位を自動的に決定するため

B. 要件、コード、テスト成果物の変更履歴を追跡するため

C. テストデータを暗号化するため

D. 不具合修正を開発チームに自動通知するため

正解： ✅ B

構成管理ツールの目的は「変更履歴とトレーサビリティの管理」であり、テストや要件のバージョンを正確に追跡することが中心です。

まとめ：アジャイル開発における「構成管理ツール」の重要性

構成管理は、アジャイル開発を支える「見えない基盤」です。

頻繁に変化するソフトウェアやドキュメントを整理し、チームの混乱を防ぎ、リリースの信頼性を高めます。

特にアジャイルでは、

• 短期間での変更対応

• 複数メンバーの同時開発

• 自動テストとの連携

  といった特徴があるため、構成管理ツールは品質とスピードを両立するための必須ツールと言えます。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

そのため、**コードのビルド（構築）や配布（デプロイ）**を自動化するツールの存在が非常に重要になります。

この記事では、ISTQB Agile Tester Extensionの**3.4.3「Software Build and Distribution Tools」**で扱われている内容を、初心者でもわかるように解説します。

🔧 ソフトウェアのビルドツールとは？

**ビルドツール（Build Tools）**とは、ソースコードをコンパイルし、実行可能な形にまとめるためのツールです。

アジャイル開発では、開発者がコードを変更するたびに新しいビルドを作成し、統合テスト環境に反映する必要があります。

主なビルドツールの例

• Maven（Java）：依存関係の管理とビルドを自動化

• Gradle（Java / Kotlin）：より柔軟なスクリプトで複雑なビルドを制御

• Make（C/C++）：古典的だが堅牢なビルド管理ツール

• npm / yarn（JavaScript）：Node.jsアプリのビルドと依存関係管理

アジャイルでの役割

アジャイル開発では、1日に何度もコードが変更・統合されるため、

手動でのビルドでは時間がかかり、ヒューマンエラーも増えます。

そのため、ビルドツールをCI（継続的インテグレーション）サーバーと連携させて、自動的にビルドが走るように設定します。

代表的なCIサーバーには以下のようなものがあります。

• Jenkins

• GitLab CI/CD

• GitHub Actions

• Bamboo

🚀 配布ツール（Distribution Tools）とは？

ビルドされたソフトウェアを、テスト環境や本番環境に**自動でデプロイ（配布）**するためのツールです。

これにより、開発者が手動でアップロードする手間を省き、ミスを防ぐことができます。

代表的な配布ツールの例

• Ansible：構成管理とデプロイを自動化

• Docker：環境ごとの差異を減らし、どこでも同じ動作を保証

• Kubernetes：コンテナ化されたアプリをスケーラブルに運用

• AWS CodeDeploy / Azure DevOps / Google Cloud Build：クラウド向け自動デプロイツール

これらのツールを使うことで、

• 「開発環境 → テスト環境 → ステージング → 本番」

  という一連の流れを自動化し、リリースをスムーズにします。

🧩 アジャイルとCI/CDの関係

アジャイル開発では、**継続的インテグレーション（Continuous Integration）と継続的デリバリー（Continuous Delivery）**が中心的な考え方です。

継続的インテグレーション（CI）とは？

開発者がコードをコミットするたびに、自動的にビルドとテストを実行する仕組み。

これにより、統合時の不具合を早期に発見できます。

継続的デリバリー（CD）とは？

CIで確認されたソフトウェアを、自動的にテスト環境やステージング、本番へと配布する仕組み。

リリース作業を効率化し、顧客への提供スピードを高めます。

🐞 「バグを先に直す」アジャイルの原則

アジャイル開発には「Fix Bugs First（バグを先に直す）」という文化があります。

次のイテレーションに進む前に、前回の不具合を必ず修正してから進めることで、品質を保ちながらスプリントを継続できます。

CI/CDツールの活用により、バグ修正後すぐに再ビルド→再デプロイできるため、

チーム全体の生産性が大幅に向上します。

🧠 まとめ：ツールが支える“アジャイル品質”

これらのツール群は、アジャイル開発を高速かつ高品質に進めるための基盤です。

手動作業を減らし、継続的な品質改善を支えることで、顧客により早く価値を届けられるようになります。

✅ まとめポイント

• アジャイルでは毎日のビルドと統合が基本

• ビルドツール＋配布ツール＋CI/CDの組み合わせが必須

• **バグ修正優先（Fix Bugs First）**で品質を維持

• 自動化によって開発スピードと信頼性を両立できる

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

今回は、ISTQB Agile Tester Extensionの**Chapter 3.4.2「Communication & Information Sharing Tools」**の内容をもとに、実際の現場で使われるツールやその目的をわかりやすく整理していきます。

🔹 アジャイル開発におけるコミュニケーションの特徴

アジャイルの特徴のひとつは、**「軽量で素早い情報伝達」**です。

ドキュメント中心のウォーターフォール型とは異なり、アジャイルでは次のような手段がよく使われます。

• 口頭での会話（デイリースクラムなど）

• チャットツールによる即時のメッセージ共有

• Wikiやタスクボードなどの情報共有基盤

• 画面共有やリモート会議による迅速な問題解決

このように、**「スピードと透明性」**を重視したツール選びがポイントになります。

🔹 主な3種類のコミュニケーション＆情報共有ツール

ISTQBでは、アジャイル環境でよく活用されるツールを次の3つに分類しています。

① Wiki（ウィキ）／ドキュメント共有ツール

Wikiは、**チーム全体の「知識ベース」**として機能します。

プロジェクトに関するあらゆる情報を集約・整理し、誰でも参照・更新できるのが特徴です。

代表的なツール例

• Confluence（Jiraと連携可）

• Notion / Google Sites / Miro

主な用途

• プロジェクト概要・方針・ルール

• プロダクト仕様・設計図・プロトタイプ

• テスト戦略・テスト方針書・チェックリスト

• 過去のスプリント実績・レトロスペクティブ記録

利点

• チーム全員が「最新の情報源（Single Source of Truth）」を共有できる

• 新メンバーのオンボーディングが容易

• 検索・リンク機能でナレッジを再利用可能

📘 例：

Confluence上に「テストプロセス標準ページ」を作成し、各スプリントのテスト計画、欠陥傾向グラフ、改善点を更新していく。

② Instant Messaging（インスタントメッセージング）

チャットや音声・ビデオ通話など、リアルタイムなコミュニケーションを支えるツールです。

スプリント中に発生する課題を、メールより速く、柔軟に解決できます。

代表的なツール例

• Slack / Microsoft Teams / Discord / Google Chat

主な用途

• 開発者とテスター間の即時確認

• デイリースクラム後のタスク進捗共有

• インシデント発生時のクイックディスカッション

利点

• 時差・地理的距離を超えた連携が可能

• 通話や画面共有も統合されている

• 「誰が何を話したか」が記録として残る

📗 例：

テスターがSlackで「#qa-bugfix」チャンネルを使い、
バグ報告 → 開発者が修正状況を即返信 → テスターが再確認という流れを1時間以内で完結。

③ Desktop Sharing（デスクトップ共有）／画面キャプチャツール

特に**分散チーム（リモート環境）**では、画面共有が重要なサポート手段です。

主な活用シーン

• プロダクトデモやレビュー

• コードレビューやペアプログラミング

• 不具合再現の共有（QA ↔ Dev）

代表的なツール例

• Zoom / Google Meet / Microsoft Teams / AnyDesk / Loom

利点

• チーム全員が同じ画面を見ながら議論できる

• スクリーン録画で「再現手順動画」を保存可能

• 問題解決のスピードアップ

📙 例：

テスターがLoomで「再現手順動画」を撮影し、チケットに添付 → 開発者が即確認 → 修正完了までの時間を短縮。

🔹 アジャイルチームがツールを使いこなすポイント

1. 透明性を高めることを目的にする

   　ツールの導入目的は「記録」ではなく「共有」です。

2. 使う場所を明確にする

   　Wiki＝長期保存、チャット＝短期的連絡、画面共有＝リアルタイム議論、といった使い分けが大切。

3. 全員がアクセスできる状態を維持

   　アクセス制限やフォルダ分けをしすぎると、情報のサイロ化（孤立）が進むので注意。

🔹 まとめ：アジャイルでは「会話＋可視化」が命

アジャイルの原則では、「プロセスやツールよりも個人と対話を重視する」とされています。

しかし実際の現場では、ツールを**“会話を支える補助輪”**として活用することで、

リモートでもチーム全体の一体感と生産性を高めることができます。

🧩 まとめポイント

💡試験対策メモ（ISTQB Agile Tester）

ISTQB試験では、以下のような問題が出ることがあります。

例題：

アジャイルチームにおいて、分散メンバー間のリアルタイムコミュニケーションを促進する最適なツールはどれか？

A. Wiki

B. バージョン管理システム

C. インスタントメッセージング

D. テスト管理ツール

✅ 正解：C（インスタントメッセージング）

🏁 まとめの一言

アジャイルのスピード感を支えるのは、人とツールの協働です。

Wikiで知識を蓄え、チャットで素早く共有し、画面共有で共通理解を深める。

この三位一体の情報共有が、チームのパフォーマンスを最大化します。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

アジャイル開発では、ドキュメントよりも動くソフトウェアと迅速なフィードバックが重視されます。

そのため、すべてのテストケースを事前に細かく設計しておく時間がないことも多いでしょう。

そんなアジャイル環境で非常に有効なのが、**エクスプロラトリテスト（Exploratory Testing）**です。

今回は、ISTQB Agile Tester Extension シラバス「3.3.4 Exploratory Testing and Agile Testing」で解説されている内容をもとに、アジャイル開発におけるエクスプロラトリテストの考え方と進め方をわかりやすく整理します。

■ エクスプロラトリテストとは？

エクスプロラトリテストとは、事前に厳密に設計されたテストケースを用いず、

テスター自身の経験・直感・知識を活かして、ソフトウェアを探索的にテストしていく手法です。

たとえば、

• 仕様書がまだ未完成

• スプリント期間が短く、詳細なテスト設計を行う余裕がない

• 新しい機能の初期リリースで、動作傾向を早く把握したい

といった状況で特に効果を発揮します。

💡つまりアジャイルでは、**「探索的テスト＝日常的なテストスタイル」**と言っても過言ではありません。

■ エクスプロラトリテストの特徴

アジャイルでは、**「仕様の抜け」や「ユーザー視点での違和感」**をいち早く発見することが重要です。

そのため、エクスプロラトリテストでは、スクリプトに縛られず、発見力と観察力が問われます。

■ テストチャーター（Test Charter）の活用

完全な自由ではなく、一定の指針を持つことも大切です。

そこで使用されるのが テストチャーター（Test Charter） です。

テストチャーターとは、エクスプロラトリテストを実施するための簡単な「行動計画書」です。

主に以下の情報を記載します。

テストチャーターは「何を探索するか」を明確にしつつ、柔軟に進めるための“コンパス”のような役割を果たします。

■ セッションベーステストマネジメント（Session-Based Test Management）

エクスプロラトリテストを体系的に進めるために使われる管理手法が、

**セッションベーステストマネジメント（SBTM）**です。

🔸 テストセッションとは？

テストセッションとは、1回あたりの探索的テストの実行単位のこと。

通常は 60〜120分（1〜2時間） の集中した時間枠で行われます。

各セッションの中で1つのチャーターを実施し、結果をまとめます。

🔸 セッションの種類（例）

テスターの経験や観察力が高いほど、セッションの質と発見率も向上します。

■ 探索的テスト中の思考例・質問例

エクスプロラトリテストでは、テスターが常に自問しながら進めます。

代表的な質問例を挙げます。

• どの部分が最もリスクが高いか？

• この操作を逆の順序で行ったらどうなる？

• 無効なデータを入力したら？（ネガティブテスト）

• ユーザーの期待通りの挙動になっているか？

• 異なる環境やブラウザでも動作するか？

このように、「もし〜したらどうなるか？」という思考を繰り返すことで、

スクリプトでは見つけにくい未知の欠陥や潜在的リスクを発見できます。

■ ドキュメントとして残すべき情報

探索的テストは「柔軟」ですが、記録をまったく残さないのはNGです。

後で再現性を確保するために、最低限以下の情報を残しましょう。

このような記録は、**チーム共有やレトロスペクティブ（振り返り）**でも大いに役立ちます。

■ エクスプロラトリテストのメリットまとめ

■ まとめ

エクスプロラトリテストは、「アジャイル開発における柔軟な品質保証」の中心的な考え方です。

形式的なテスト手法と組み合わせることで、リスクの高い部分を迅速に検証し、

短期間でも高品質な成果を実現できます。

アジャイルテスターとして成功するためには、

単にスクリプトを実行するのではなく、**“探索する姿勢”**が何より重要です。

🧩 この記事のまとめ

• アジャイルではエクスプロラトリテストが自然に行われる

• テストチャーターで目的と範囲を明確に

• セッションベースで短時間集中実施（1〜2時間）

• 観察結果を簡潔に記録して再現性を確保

• 経験と好奇心が品質向上のカギ

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

今回は、ISTQB Agile Tester Extensionシラバスの「3.3.3 Functional and Non-Functional Black Box Test Design（機能的・非機能的ブラックボックステスト設計）」についてわかりやすく解説します。

1. ブラックボックステスト技法とは？

ブラックボックステストとは、内部構造を考慮せず、外部から見たシステムの入力と出力の関係を確認するテスト手法です。

代表的な技法には以下があります。

• 同値分割法（Equivalence Partitioning）

  　入力値を「同じ結果をもたらすグループ」に分けて、各グループから1つだけ代表値を選んでテストする方法。

• 境界値分析法（Boundary Value Analysis）

  　エラーが発生しやすい「境界値（境目）」に着目してテストする方法。

• 決定表テスト（Decision Table Testing）

  　条件と結果を表にまとめ、組み合わせを体系的に網羅する方法。

• 状態遷移テスト（State Transition Testing）

  　システムの状態変化をもとに、状態間の遷移やイベントをテストする方法。

これらは、従来型（ウォーターフォールなど）の開発でも用いられてきた正式な技法です。

しかしアジャイル開発でも、必要に応じてこれらの技法を活用することが可能です。

2. アジャイル開発におけるテスト設計の特徴

アジャイルでは「最小限のドキュメントで、迅速にフィードバックを得る」ことが重視されます。

そのため、従来のような長大なテスト仕様書は作成せず、次のような軽量な形式が一般的です。

• テストシナリオを簡潔にまとめる

• 1行で表現した「論理テストケース」を用意する

• ユーザーストーリーや受け入れ基準（Acceptance Criteria）から直接テストを導出する

しかし、すべてを簡略化するわけではありません。

リスクの高い領域や重要な要件に対しては、正式なブラックボックス技法を適用し、より体系的にテストケースを設計することが推奨されます。

3. 機能テストと非機能テストの両方に適用できる

ブラックボックス技法は、機能テストだけでなく非機能テストにも活用できます。

たとえば：

✅ 機能テストの例

• 入力フォームに「年齢」を入力し、0歳未満や150歳以上を入力した場合の動作を確認する（境界値分析）

• ログイン処理の条件を組み合わせて正常・異常パターンを網羅する（決定表テスト）

✅ 非機能テストの例

• 「レスポンスタイムが2秒以内であること」という性能要件に対し、境界値を設定して測定する

  → 例：1.9秒（合格）、2.0秒（境界値）、2.1秒（不合格）

• 「1時間あたりの処理失敗数が5回未満であること」という信頼性要件をテストする

  → 同値分割法を使って「0〜4回」と「5回以上」の区分を定義して確認

このように、非機能要件も“数値的な条件”を持つ場合は、ブラックボックス技法で体系的にテスト設計が可能です。

4. 実務での活用イメージ

アジャイル開発では、テスターと開発者が密に協力します。

例えばスプリント中に次のような流れでテストを設計します。

1. ユーザーストーリーの受け入れ基準を確認

2. リスク分析を行い、重要度の高い項目を特定

3. テスト技法を選択（例：境界値分析）

4. テストケースを作成し、開発者とレビュー

5. 実装と並行してテストを実行

これにより、「開発中にテストが追いつかない」「品質リスクが見落とされる」といった課題を防ぐことができます。

5. 例題：レスポンスタイム要件のテスト設計

問題：

Webアプリケーションのレスポンスタイム要件は「3秒以内」と定義されています。

以下の入力条件のうち、境界値分析を用いると最も適切なテストデータの組み合わせはどれでしょうか？

選択肢：

A. 2秒、3秒、4秒

B. 1秒、2秒、3秒

C. 2.9秒、3.0秒、3.1秒

D. 2秒、3.5秒、4秒

正解：C. 2.9秒、3.0秒、3.1秒

→ 境界値分析では、要件の境界付近（3.0秒前後）を重点的にテストします。

6. まとめ

• アジャイル開発でも、必要に応じて正式なテスト設計技法を活用することが重要。

• ブラックボックステスト技法は、機能・非機能の両面で有効。

• 軽量なドキュメントでも、テストの論理性と網羅性を担保することが可能。

• テスターと開発者が協力してテストケースを並行設計することで、品質向上と開発スピードの両立が実現できる。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

今回のテーマは、**Acceptance Test-Driven Development（ATDD：受け入れテスト駆動開発）**の「適用方法」です。

前回学んだ「TDD（テスト駆動開発）」や「BDD（振る舞い駆動開発）」の延長線上にあり、特にATDDはアジャイル環境で頻繁に使われる手法です。

🔍 ATDDとは？

**Acceptance Test-Driven Development（受け入れテスト駆動開発）**とは、

「開発を始める前に“受け入れテスト”を定義するアプローチ」です。

つまり、「何を作るか」より前に「どうすれば完成とみなせるか（受け入れ条件）」を明確にするという考え方です。

🧩 例：

たとえばユーザーストーリーが

「ユーザーは正しいIDとパスワードを入力すると、ログインできる」

であれば、ATDDでは次のように「受け入れテスト条件」を先に書きます。

このように、**開発前に“テスト観点から仕様を明確化する”**のがATDDの基本姿勢です。

🧠 ATDDの進め方（ステップごとの流れ）

① スペシフィケーション・ワークショップ（Specification Workshop）

まず最初に、開発チーム・テスト担当・ビジネス担当者の3者で集まり、

ユーザーストーリーを分析・議論・文書化します。

この段階で以下の点を確認します：

• 要件の曖昧さや不完全さを修正

• 欠落している条件や例外パターンを洗い出す

• 受け入れ条件を、チーム全体で共通理解する

👉 狙いは、早期に欠陥を防ぎ、修正コストを最小化すること。

✅ 例：

ユーザーストーリー：「パスワードを5回間違えるとアカウントがロックされる」

→ この時点で「何回目で警告を出すか」「解除条件は？」などを明確にしておく。

② テストの作成（Create the Tests）

次に、ワークショップで定義したシナリオをもとに、実際のテストケースを作成します。

これはチーム全体で作る場合もあれば、テスター単独で作成する場合もあります。

• 作成者がテスターなら、ビジネス担当がレビュー・承認する。

• 作成者がチーム全体なら、第三者（例：プロダクトオーナー）が検証する。

👉 この段階では、**「テスト＝ユーザーストーリーの具体例」**という位置づけです。

③ ポジティブテスト（Positive Tests）

まずは**正常動作を確認するテスト（ポジティブテスト）**から始めます。

なぜなら、基本的な動作が通らない状態では、

異常系テストをしても意味がないからです。

例：

• 有効なクレジットカード番号で決済できるか？

• 有効なログイン情報でログインできるか？

④ ネガティブテスト（Negative Tests）と例外テスト

次に、異常パターンや例外条件をテストします。

これには、無効な入力や想定外の操作が含まれます。

例：

• 無効なメール形式を入力したらどうなるか？

• 必須項目を空欄にした場合、警告が出るか？

その後、**非機能要件（パフォーマンス・セキュリティ・UXなど）**も確認します。

⑤ スコープ外を避ける（No Out-of-Scope Examples）

ATDDでは、ユーザーストーリーに明示されていない内容を勝手に追加してはいけません。

つまり「テスト例はストーリー内の仕様に限定する」ことが鉄則です。

❌ 例：

ユーザーストーリーに「ソーシャルログイン機能」が書かれていないのに、

Facebookログインをテストする → スコープ外！

🌱 ATDDの効果まとめ

💬 まとめ

• ATDDは「開発前に受け入れ条件を明確化する」テスト駆動アプローチ。

• チーム全体で協働し、曖昧さを減らし、修正コストを最小化する。

• ポジティブ → ネガティブ → 非機能の順でテストを進める。

• ユーザーストーリー外の内容は含めない。

このように、ATDDはアジャイルの原則「早期・頻繁なフィードバック」を実現するための、

非常に実践的なテクニックです。

🧭 次のステップ

次回は「3.3.3 振る舞い駆動開発（BDD）の適用」について解説します。

TDD・ATDD・BDDを比較しながら、どのように現場で使い分けるかを見ていきましょう。

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon

今回はISTQB Agile Tester Extensionの第3章「アジャイルプロジェクトにおけるテスト技法」より、3.3.1「受け入れ基準・十分な網羅性・その他の情報」の前半部分を解説します。

✅ 1. 受け入れ基準（Acceptance Criteria）とは？

受け入れ基準とは、ユーザーストーリーや要件が「完了」と見なされるための条件を明確にするものです。

たとえば、「ログイン機能の実装」であれば、以下のような基準が設定されます。

• ユーザー名とパスワードを正しく入力するとログインできる

• 間違ったパスワードではエラーメッセージが表示される

• セッション管理が適切に行われ、ログアウト後は再認証が必要

つまり、何をもって“できた”とするのかをチーム全体で共通認識するための基準です。

✅ 2. 受け入れ基準に含まれるべき情報

受け入れ基準には、以下のような項目を含めることで、曖昧さを減らし、テストの抜け漏れを防ぐことができます。

これらを明確にすることで、テストケース作成時にも抜け漏れなく品質を保証できます。

✅ 3. テストレベルごとの「完了の定義（Definition of Done）」

アジャイル開発では、「各テストレベルで何をもって完了とするか」をチームで合意しておく必要があります。

これを Definition of Done（DoD） と呼びます。

🔹 Unit Testing（単体テスト）の完了基準

単体テストでは、コードレベルでの品質を保証します。

以下のような条件を満たすことが理想です。

• 可能な限り 100%の分岐網羅率（Decision Coverage） を達成

• 到達不可能なパスを確認し、レビュー済み

• 重大な未解決欠陥がない

• 技術的負債（テクニカルデット）が残っていない

• 全ての単体テストが自動化され、結果が確認済み

• 性能などの品質特性が許容範囲内

例:

ログイン関数に対して、正常系・異常系・例外処理をすべてテストし、100%分岐網羅できているかを確認します。

🔹 Integration Testing（結合テスト）の完了基準

モジュール間の連携やデータのやり取りを確認する段階です。

• 全ての機能要件（正・負テストケースを含む）を実施

• モジュール間のすべてのインターフェースをテスト

• リスクベースで必要十分な範囲の品質リスクをカバー

• 未解決の重大欠陥がない

• 回帰テストを可能な限り自動化し、リポジトリに保存

例:

「ログインAPI → 認証サーバ → セッション管理DB」間でのデータ連携が正しく行われるか確認。

🔹 System Testing（システムテスト）の完了基準

ここでは、システム全体がユーザー視点で正しく動作するかを確認します。

• エンドツーエンド（E2E）のテストが実施されている

• 想定するすべてのユーザーペルソナをカバー

• 本番に近い環境でハードウェア・ソフトウェア両面から検証

• 合意された範囲内で全ての品質リスクを評価

• 可能な範囲で回帰テストを自動化

• 未解決の重大欠陥がない

例:

「新規登録 → ログイン → 商品購入 → 決済完了」までの一連の流れを、本番と同じ構成でテストする。

✅ 4. まとめ

受け入れ基準とDefinition of Doneは、チーム全員の共通理解を形成するための要です。

それを明確にすることで、品質のばらつきを防ぎ、開発のスピードと安定性の両立が可能になります。

この章は後編（Part 2）に続きます。次回は「テスト網羅性の評価とその他の情報」について解説します。

💡 補足：アジャイルにおける受け入れ基準のコツ

• 曖昧な表現（例：「すぐに」「使いやすい」）は避ける

• テスター・開発者・PO（プロダクトオーナー）の3者で合意

• BDD（行動駆動開発）の“Given-When-Then”形式を使うと明確になる

例:

Given ユーザーが正しい資格情報を入力したとき
When ログインボタンをクリックすると
Then ホーム画面が表示される

ソフトウェアテスト技法練習帳　～知識を経験に変える40問～ [ 梅津正洋、竹内亜未、伊藤由貴、浦山さつき、佐々木千絵美、高橋理、武田春恵、根本紀之、藤沢耕助、真鍋俊之、山岡悠、吉田直史［著］ ]

posted with カエレバ

楽天市場

Amazon

ソフトウェアテスト技法ドリル【第2版】 テスト設計の考え方と実際 [ 秋山 浩一 ]

posted with カエレバ

楽天市場

Amazon