この記事では、YouTube講座で紹介された サンプル問題2問 を日本語でわかりやすく解説します。

🧩 第1問：メンテナンスフェーズにおけるテストアナリストの対応

■ 問題文

あるビジネスアプリケーションがメンテナンスフェーズにあり、

ビジネスロジックへの変更がすでに実装されている、または次のリリースで予定されています。

テスト自動化は、変更が行われるたびにビジネスケースを回帰テストするために使用されています。

この自動化では「キーワード駆動型アプローチ」が採用されています。

しかし、前回のリリース後にいくつかの緊急修正が必要になり、

自動化レポートでいくつかの異常（anomalies）が検出されました。

この場合、テストアナリストが実施すべきステップはどれでしょうか？

■ 選択肢

A. 変更内容を反映するように、キーワードとデータを更新する

B. 自動化スクリプトを修正する

C. 異常を分析し、問題がキーワード・入力データ・スクリプト・アプリケーションのいずれにあるかを特定する

D. 開発者に依頼して、失敗した自動テストを同じデータで手動実行してもらう

E. 原因が特定できない場合は、そのテストを回帰テストスイートから削除する

■ 解説

この問題では、システムが メンテナンスフェーズ にあり、変更が頻繁に発生している状況です。

キーワード駆動型テストは、キーワード（＝テスト手順を表す再利用可能な部品）を使って自動化を構築します。

変更により異常が出た場合、テストアナリストはまず：

• A：キーワードとデータを最新の仕様に合わせて更新

• C：異常の原因を分析（キーワード・データ・スクリプト・アプリ側のどこに問題があるか）

この2つが正しいアクションです。

❌ 誤答の理由

• B. 自動化スクリプトの修正 → スクリプトの修正はテスト自動化エンジニア（または開発担当）の責任

• D. 開発者に依頼して手動実行させる → 開発者の業務範囲ではない

• E. 原因不明ならテスト削除 → テストを削除するのは不適切。根本原因の分析が先

✅ 正解：

A と C

理由まとめ：

• テストアナリストは、キーワード駆動型自動化において「キーワード定義・入力データの整備・異常分析」を担当します。

• スクリプトのコーディングやツール修正はテスト自動化担当の役割です。

💡 補足例：実務でのイメージ

例えば「注文管理システム」で、税計算ロジックに変更があったとします。

自動テスト実行後、「税込価格の表示異常」が報告された場合：

• テストアナリストは「価格計算キーワード」「テストデータ（税率）」を確認・更新

• さらに、異常が「スクリプトミス」なのか「アプリのバグ」なのかを分析

これにより、問題の原因を明確化できます。

🧩 第2問：「NOT」に注意！ツールの利点を問う問題

■ 問題文

次のうち、**「テストアナリストが使用するツールの利点を正しく表していない（NOT）」**ものはどれでしょうか。

■ 選択肢

A. テストデータ準備ツールは、データの内部整合性を保ちながら匿名化できる。

B. テスト実行ツールは、少ないテスト実行回数でコストを削減し、回帰テストの効率を向上させる。

C. テスト設計ツールは、目標とするテストカバレッジを達成するためのテストタイプ選択を支援する。

D. テスト実行ツールは、同じテストをさまざまな環境で繰り返し実行できる。

■ 解説

この問題のポイントは「NOT（〜でない）」というキーワード。

試験ではこの一語を見落とすと、正反対の回答を選んでしまうことがあります。

❌ Bの説明の誤り

「テスト実行ツールは少ないテスト実行回数でコスト削減」という部分が誤りです。

むしろ、自動化ツールの利点は「テストの繰り返し実行を容易にする」ことであり、

テスト回数を減らすのではなく、何度でも効率的に再実行できることが本質です。

✅ 正解：

B

他の選択肢はすべて正しい利点を示しています。

• A：○ 匿名化ツールにより、個人情報を保護しつつテストデータの整合性を保てる。

• C：○ テスト設計ツールはテストタイプやカバレッジ分析を支援する。

• D：○ 自動実行ツールは同じテストを複数環境で再実行できる。

💡 補足：試験での注意点

ISTQB試験では、「NOT」「EXCEPT」「LEAST」「MOST」などの単語に必ず注意しましょう。

特にツール関連の問題は「どの機能が該当しないか」を問う形式が多いです。

🧠 まとめ：Chapter 6 のポイント

• キーワード駆動型自動化では、テストアナリストが「キーワード設計・データ更新・異常分析」を担当する。

• テストツールの利点は「繰り返し・効率化・品質向上」であり、「テスト回数の削減」ではない。

• 問題文の中の “NOT”や“EXCEPT” に注意して読むことが、試験合格のカギ。

✍️ 練習問題まとめ

💬 まとめのアドバイス

Advancedレベルでは、単なる知識暗記ではなく「役割の違いと責任範囲」の理解が問われます。

特に自動化の問題では、「誰が何を担当するか」を明確に把握することが重要です。

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

この記事では、**6.3「テストツールの種類（Types of Test Tools）」**について、Foundationレベルの復習を交えながら、テストアナリストがどのようにツールを選び、効果的に活用すべきかを詳しく解説します。

1. テストツールの基本分類

Foundationレベルのシラバスでも学んだように、テストツールは大きく以下のように分類されます。

テストアナリストは、どのツールを、どの工程で、どの目的で使うかを正しく判断することが求められます。

単に導入するだけでなく、「効率や品質向上につながるか？」という視点が非常に重要です。

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

テスト設計ツールとは？

テスト設計ツールは、テストケースの作成やテストデータ準備を自動化・支援するためのツールです。

例えば、要件定義書をもとにテストケースを自動生成できるツールなどがあります。

活用のポイント

• 要件書や仕様書のフォーマットがツールに対応しているかを確認

• モデルや入力情報をもとに、自動でテストケースを作成できるかを検討

• プロセスに合わないツールはROI（投資対効果）が低くなるため注意

具体例

例えば、「等価分割法」や「境界値分析」をサポートするツールがあります。

これらを使えば、パラメータや値の組み合わせを自動生成し、抜け漏れのないテストケースを作成できます。

3. テストデータ準備ツール（Test Data Preparation Tools）

テスト設計とは別に、「テストデータ生成」に特化したツールもあります。

主な機能

• 要件書やコードを解析し、必要なデータ項目を特定

• 実際のシステムデータを抽出し、個人情報をマスキング（匿名化）

• 不正データ（システムが受け入れないデータ）を除外し、有効なデータのみを抽出

例：データ生成ツールの用途

• 等価分割や境界値分析で必要な入力データの自動作成

• 組み合わせテスト（Combinatorial Testing）用のパラメータ生成

• 実際の顧客データをもとにしたテスト環境構築（匿名化済み）

テストアナリストは、どんなデータがどんな機能の妥当性を検証できるかを見極め、

信頼性の高いテストデータを準備する必要があります。

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

自動化とは？

自動テスト実行ツールは、テストスクリプトを自動的に実行するツールです。

これにより、人手による操作を減らし、再現性のあるテスト実行が可能になります。

代表的な用途

• 回帰テスト（Regression Testing）

• 継続的インテグレーション（CI）／アジャイル開発環境

• 環境依存テスト（複数ブラウザ・OSでの実行）

活用する際の判断ポイント

• プロダクトの開発言語や通信プロトコルと適合しているか

• 投資に見合うリターン（ROI）が見込めるか

• 長期的な保守やフレームワーク構築コストを考慮できるか

自動化のメリット

• テストの繰り返し実行コストを削減

• 同じテストを複数環境で高速に実施可能

• 人手では困難なテスト（大量データ、夜間実行など）を実行可能

例：テスト自動化ツール

• Selenium／Playwright（Webアプリ向け自動テスト）

• JUnit／TestNG（単体テストの自動実行）

• Jenkins／GitHub Actions（自動ビルド＋テスト統合）

5. テストアナリストが担う「ツール選定の責任」

ツールの導入にはコストが伴うため、テストアナリストには次のような責任があります。

• プロジェクトに適したツールを選定する

• ROI（投資対効果）を評価する

• ツールがプロセスやチームに適合するかを確認する

もし導入したツールが現場のワークフローに合わなければ、

「使われない高価なツール」になってしまいます。

そのため、「導入すること」よりも「活かせること」が最重要です。

6. まとめ：ツールを“使う”より、“活かす”ことが大切

ISTQB Advancedレベルで求められるのは、単なるツール操作スキルではなく、

**「どのツールを、どの目的で、どの場面で活用するか」**を判断する能力です。

• テスト設計ツールで効率的にケースを生成する

• テストデータツールで安全かつ妥当なデータを用意する

• 自動化ツールで再現性と効率を高める

• そして、ROIの視点でツール導入を評価する

これらを意識してツールを「プロセスに組み込む」ことが、

上級テストアナリストとしての実践力につながります。

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

はじめに：Chapter 6の概要

ISTQB Advanced Test Analystの**Chapter 6「Test Tools and Automation」では、テストツールと自動化に関する知識を扱います。

この章の6.1「Introduction」は復習的な内容で、メインとなるのは6.2「Keyword Driven Automation（キーワード駆動型自動化）」**です。

本記事では、この6.2で学ぶ内容を初心者にもわかりやすく解説します。

1. テストツールの基本復習

Foundation Level（基礎レベル）で学んだように、テストツールには以下のような役割や特徴があります。

• テスト効率の向上：自動化により手作業を削減できる

• 品質向上：繰り返しテストで人為的ミスを減らす

• リスク：ツール導入にはコスト・学習時間・メンテナンス負荷がある

• ツール選定のポイント：組織のプロセスやスキルに適しているか

• パイロット導入：一部プロジェクトで試験的に導入し、効果を検証する

これらを踏まえたうえで、キーワード駆動型テストの理解を深めましょう。

2. キーワード駆動型テスト自動化とは？

● 定義

**キーワード駆動型テスト（Keyword Driven Testing）**とは、

テストケースを「キーワード（＝アクションを表す言葉）」によって制御するテスト自動化の手法です。

各テストケースに、**一意のキーワード（アクションワード）**を割り当てます。

このキーワードを使って、テストスクリプトを動的に呼び出す仕組みです。

● 例：ECサイトのテストを自動化する場合

スクリプトのメイン部分では「login」「place_order」などのキーワードを呼び出して、

必要なテストケースだけを実行します。

たとえばシステムアップデート後に「注文関連だけ再テストしたい」ときは、

place_orderとcancel_orderのみ呼び出せばOKです。

これがキーワード駆動の強みです。

3. なぜキーワード駆動型が使われるのか？

この手法は特に**回帰テスト（Regression Testing）**で効果を発揮します。

主な目的

• テストスイート（多数のテストケース）の中から、変更に関連するものだけを効率的に実行できる

• 各テストケースが独立して管理でき、再利用性が高い

• ビジネスロジックの変更があっても、スクリプト全体を書き直す必要がない

4. キーワード駆動型テストのメリット

1. ドメイン専門家がキーワードを定義できる

   　→ 例えば「顧客登録」「注文確定」など、業務用語に沿った命名が可能。

   　→ テストアナリストが業務理解をもとに、プロジェクト標準に沿ってキーワードを設計します。

2. コーディング知識が不要

   　→ テストケースの実行はキーワード呼び出しで完結するため、

   　　ドメイン知識はあるがプログラミングが得意でない担当者でもテストを実施可能。

3. 再利用性と保守性が高い

   　→ スクリプトの関数部分（アクション定義）は一度書けば、何度でもキーワードから呼び出せる。

   　→ UI変更などがあっても、関数の一部修正で済む。

4. 仕様と実装の分離

   　→ テスト仕様書（何をするか）と自動化コード（どのようにするか）を分離できるため、

   　　ドキュメントとスクリプトの両方の保守が容易になります。

5. テストアナリストの役割

キーワード駆動型自動化では、**Test Analyst（テストアナリスト）**の責任が大きくなります。

テストアナリストが担うべき業務

• 適切なキーワードの設計と命名（業務・技術の両視点から）

• キーワードとビジネスプロセスのマッピング

• 自動化スクリプト担当者（Automator）との連携

• 実行時の異常（アノマリ）解析

  　　→ 不具合がキーワード定義・テストデータ・スクリプト・アプリ側の欠陥のどこにあるかを特定

6. 継続的インテグレーション（CI/CD）との関係

キーワード駆動型テストは、**継続的インテグレーション（CI）**や

**継続的デプロイメント（CD）**環境にも適しています。

• 新しいビルドごとに自動的にテストスイートが実行される

• 回帰テストを短時間で効率的に行える

• 開発とテストのサイクルを高速化できる

これにより、品質保証と開発スピードの両立が可能になります。

7. 注意点と実践上のポイント

8. まとめ

キーワード駆動型自動化は、

再利用性・保守性・チーム連携性に優れた自動化フレームワークです。

• テストケースごとに一意のキーワードを設定

• キーワードを通して自動化スクリプトを呼び出す

• ビジネス知識と技術スキルの橋渡しをするのがテストアナリストの役割

テスト自動化の基盤を強化したいチームにとって、非常に有効なアプローチといえます。

💡まとめ図：Keyword Driven Automationの構造イメージ

[テストケース一覧]
↓（キーワード）
[キーワードマッピング表]
↓（対応する関数呼び出し）
[自動化スクリプト群]
↓
[アプリケーション実行]

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

この記事では、YouTubeチャンネル「ISTQB Tutorials」で紹介された サンプル問題2問 をもとに、

試験で問われるレビューの考え方と、チェックリストの使い方を具体的に解説します。

✅ 第1問：要求仕様書レビューとチェックリストの適用

■ 問題文（シナリオ）

あなたは以下のような要求仕様書をレビューしています。

要求仕様書の内容（抜粋）

• オブジェクト: 新システム

• 著者: 開発担当者A

• バージョン: 0.23

• サブシステム: 顧客管理

• 作成日: 2025/01/15

• 対象ユースケース: Yes（プロジェクト適用）

この仕様書には機能要求がいくつか記載されています。

また、レビューのために以下のチェックリストが提供されています。

■ チェックリスト項目

■ 解答の考え方

この問題では、「要求仕様」と「チェックリスト」を比較し、

どの項目が**満たされていない（Not Met）**かを判断します。

上記の確認結果から、

満たされていない項目は以下の通りです。

• ④ 要求の一意識別（Requirement IDの欠如）

• ⑥ ビジネス要求とのトレーサビリティ

• ⑦ ユースケースとのトレーサビリティ

✅ 正解：

B（4・6・7が未達）

💡 解説ポイント

この問題は、レビューにおけるトレーサビリティと一意性の重要性を問うものです。

テストアナリストとしては、

• 各要求に「一意のID」を付与すること

• 要求からビジネス要件・ユースケース・テストケースへ追跡できること

  が品質保証上の基本原則となります。

✅ 第2問：要求文の品質チェック

■ 問題文

あなたは、オンラインバンキングアプリ開発プロジェクトのテストアナリストです。

要件レビューに参加する際、以下の要求仕様が提示されました。

REQ-03
ソフトウェアに不慣れなユーザーでも、銀行振込を行えること。

あなたは以下の要求記述チェックリストを使ってレビューを行います。

■ チェックリスト項目

■ 選択肢

A. すべての項目が満たされている

B. ①と②が満たされている

C. ②のみが満たされている

D. ①のみが満たされている

■ 解答の考え方

要求をチェックリストに照らし合わせて確認します。

✅ 正解：

C（②のみ満たされている）

💡 解説ポイント

この問題は、要求が曖昧であってはテストできないことを確認する例です。

「不慣れな人」とは誰か？

「振込を行える」とはどの範囲か？

など、具体的・客観的な条件が欠けています。

要求がテスト可能になるためには、

• 明確な入力条件と期待結果

• 測定可能な基準（例：操作回数・時間など）

  を定義する必要があります。

🧩 Chapter 5で学ぶべきポイント

🏁 まとめ

ISTQB Advanced Test AnalystのChapter 5では、

レビューとチェックリストを通じて欠陥を早期に発見するスキルが求められます。

特に試験では、

• 「どのチェック項目が満たされていないか」

• 「要求の曖昧さをどう判断するか」

  が問われることが多いため、チェックリストの目的を理解し、

  例題で練習しておくことが重要です。

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

ここでは、**5.2「Using Checklists in Review（レビューにおけるチェックリストの活用）」**の要点を、例を交えてわかりやすく整理します。

■ チェックリストとは何か？

チェックリストとは、レビュー対象（要求仕様書・設計書・テストケースなど）に対して共通の観点で抜け漏れを確認するための質問リストです。

例えば、次のような項目がチェックリストに含まれます。

• 要求が明確で一意に識別できるか？

• テスト可能な内容になっているか？

• 関連するユースケースや業務要件とのトレーサビリティは取れているか？

• 用語は一貫して使われているか？

これらを体系的に確認することで、レビューの品質を標準化し、個人の経験や感覚に依存しないレビューが可能になります。

■ チェックリストの目的と利点

チェックリストを使う主な目的は以下の通りです。

1. レビューの効率向上

   　→ 確認すべき観点が明確になるため、時間の無駄が減ります。

2. 品質の一貫性確保

   　→ 全メンバーが同じ基準でレビューできます。

3. 組織標準の維持

   　→ 組織で定めた基準を全てのプロジェクトに適用できます。

4. リスク低減

   　→ よくある欠陥パターンを事前に検出できます。

また、チェックリストはレビュー活動以外にも役立ちます。

たとえば「開発者やテスターのスキル基準」や「リスク評価項目」を整理する際にも利用可能です。

■ チェックリストの種類

テストアナリストは、レビュー対象のドキュメントごとに異なるチェックリストを活用します。

代表的な例を見ていきましょう。

① 要求仕様書レビュー用チェックリスト（Requirement Review）

要求仕様書をレビューするときは、次のような質問項目が使われます。

このようなチェックを通じて、要求の曖昧さ・抜け・重複を早期に発見することができます。

② ユーザーストーリーレビュー用チェックリスト（User Story Review）

アジャイル開発では、要求仕様の代わりに**ユーザーストーリー（User Story）**が用いられます。

そのため、アジャイル版チェックリストとして次のような観点が使われます。

このように「INVEST原則（Independent, Negotiable, Valuable, Estimable, Small, Testable）」にも対応する観点を含めるとよいでしょう。

■ チェックリストのカスタマイズ（Tailoring）

組織やプロジェクトごとに適切なチェックリストを作成する際は、以下の要素を考慮します。

良いチェックリストは、既知の問題を確実に検出できるだけでなく、潜在的な問題の議論を促すことができます。

複数のチェックリストを組み合わせることで、より包括的なレビューが可能になります。

■ まとめ

• チェックリストはレビュー品質を安定させる強力なツール。

• 組織標準として整備し、要求やユーザーストーリー、設計、テストケースなど各文書に適用可能。

• プロジェクト特性やリスクに応じて柔軟にカスタマイズすることが大切。

効果的なレビューの鍵は、**「体系的な確認」＋「改善の議論」**です。

チェックリストはその両方を支える「品質の土台」と言えるでしょう。

💡例：実務での活用ヒント

• 要件定義フェーズで「要求レビュー用チェックリスト」を導入 → 仕様漏れの早期発見

• スプリントレビュー前に「ユーザーストーリー検証チェックリスト」を使用 → 受け入れ条件の抜け漏れ防止

• プロジェクト完了後に「チェックリスト改善会」を実施 → 組織知見の蓄積

🧭 まとめ図（簡易）

レビュー対象
↓
チェックリスト（標準化質問集）
↓
レビュー実施（形式的・体系的に確認）
↓
欠陥・改善点の早期検出
↓
製品品質の向上

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

この章では主に以下の2つのトピックを扱います：

• 5.1：レビューの概要（Introduction to Reviews）

• 5.2：チェックリストを使ったレビュー（Using Checklists in Reviews）

この記事では、5.1 レビューの概要について、Foundationレベルで学んだ内容を復習しながら、Advancedレベルの観点も加えて解説します。

🔍 レビューとは何か？

レビューとは、静的テストの一種であり、ソフトウェアの成果物（仕様書、設計書、コード、テストケースなど）を実行せずに評価する活動です。

目的は、早期に欠陥を発見し、開発コストを削減することにあります。

ISTQBでは、レビューを以下の2つに大きく分類しています。

Advancedレベルでは、この「静的レビュー」をより体系的・効果的に活用する方法を学びます。

🧩 レビューの種類と特徴

ISTQBで定義されている主なレビューの種類は次のとおりです。

🧠 レビューの目的とメリット

レビューの主な目的は、欠陥の早期発見と品質向上です。

具体的なメリットは以下の通りです。

1. 開発初期に不具合を発見できる → 修正コストが低い

2. 成果物の理解を深める → チーム全体の知識共有

3. 標準やガイドラインの遵守確認 → 一貫性ある品質保証

4. テスト設計の早期改善 → テストケース作成の効率化

🧾 チェックリストの活用（次章への導入）

Advancedレベルでは、テストアナリストとしてチェックリストを作成・活用する能力が求められます。

チェックリストは、レビューを体系的に行うための指針です。

例えば、仕様書レビュー用チェックリストの一例を見てみましょう。

このように、チェックリストを用いたレビューは、欠陥発見率を高め、レビュー品質を測定可能にします。

💡 テストアナリストの役割

Advancedレベルでのテストアナリストは、単にレビューに参加するだけでなく、

次のような役割を担います。

• チェックリストの作成・改善

• レビュー対象の選定（どの成果物をレビューするか）

• レビュー会議での技術的観点からの意見提示

• レビュー結果の分析（欠陥傾向、改善点の特定）

これにより、レビューが「形式的な作業」ではなく、品質向上の実践的プロセスとして機能するようになります。

🧩 まとめ

Chapter 5.1では、Foundationレベルの「レビューの基礎」を振り返りながら、

Advancedレベルとしての次の理解へ進む準備をします。

• レビューは静的テストの中心的活動

• 目的は欠陥の早期発見と品質向上

• チェックリストがレビュー品質を向上させるツール

• テストアナリストはレビュー設計と分析に積極的に関与する

次回の「5.2 チェックリストを活用したレビュー」では、

実際にどのようにチェックリストを使って効果的なレビューを行うかを具体的に解説していきます。

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

ここでは実際に出題されるサンプル問題を通じて、それぞれの考え方を確認していきましょう。

問題1：アジャイル開発で行うテストの種類

シナリオ：

あなたは通信業界のアジャイル開発プロジェクトに参加しています。

新しいアプリケーションでは、顧客が自分で携帯電話プランを変更できる新しいインターフェースを開発中です。

あなたはシステムテストを担当しており、「US-34」というユーザーストーリーをテストしています。

「顧客として、オンライン上で新しいモバイルプランを選択し、変更できるようにしたい。」

テストの一環として、あなたとプロダクトオーナーはビジネスの専門家を招き、画面を使って探索的テストを実施し、改善点があるか確認しています。

質問：

このとき、あなたたちはどの種類のテストを実施しているでしょうか？

選択肢：

1. ユーザビリティテスト

2. 機能適切性テスト（Functional Appropriateness Testing）

3. 相互運用性テスト

4. 移植性テスト

正解：

👉 2. 機能適切性テスト

解説：

このシナリオでは、「システムがユーザーの要求（モバイルプラン変更）を適切に満たしているか」を確認しています。

したがって、これは**機能が目的に適しているかを確認する「機能適切性テスト」**に該当します。

問題2：機能適合性（Functional Suitability）テストの実施段階

シナリオ：

あなたの会社は外国為替取引用のソフトウェアを開発しています。

新しいバージョンでは、取引量に応じて異なる手数料を計算できる機能が追加されました。

さらに、「初心者」「中級者」「上級者」という3つのユーザーカテゴリがあり、それぞれ異なる機能が提供されます。

あなたは機能適合性テストを担当しています。

質問：

これらのテストは、どの開発ライフサイクル段階で最初に実施すべきでしょうか？（2つ選択）

選択肢：

A. 低取引量の手数料計算をコンポーネントテストで確認する

B. ユーザーカテゴリ別の機能割り当てを受け入れテストで確認する

C. 他システムとの連携をシステムテストで確認する

D. 高取引量の手数料計算をシステムテストで確認する

E. 高レベルのビジネスケースをシステム統合テストでカバーする

正解：

👉 D と E

解説：

機能適合性（Functional Suitability）は、通常統合テストやシステムテストで実施されます。

• D：高取引量の手数料計算はシステムレベルで確認するのが適切

• E：高レベルのビジネスケースを網羅するのは統合テストレベルが妥当

問題3：相互運用性（Interoperability）の欠陥に該当しないもの

シナリオ：

あなたの会社はパスワード管理コンポーネントを開発しています。

Google Chromeのように、ログイン時に「パスワードを保存しますか？」と表示する仕組みです。

このコンポーネントは世界中の数百のウェブサイトに統合されており、次のバージョンでは特定のOSとの統合機能が追加されます。

ただし、一部のOSはこのコンポーネントをサポートしていません。

質問：

次のうち、相互運用性の欠陥ではないものはどれでしょうか？

選択肢：

A. 一部のウェブサイトでパスワードが保存されない

B. 一部のウェブサイトが特定のOS上で動作しない

C. 一部のブラウザでパスワードが途中で切れてしまう

D. 一部のユーザーにとって、パスワード保存手順が複雑すぎる

正解：

👉 D

解説：

A～Cは「システム間のやり取り（連携）」に関する問題＝相互運用性の欠陥です。

一方、Dは「ユーザーが使いづらい」という**ユーザビリティ（使いやすさ）**の問題に分類されます。

問題4：移植性（Portability）テストで考慮しない欠陥

質問：

次のうち、移植性テストで通常考慮しない欠陥はどれでしょうか？（2つ選択）

選択肢：

A. すべての対象環境でアプリが正常に動作しない

B. 特定の設定ではソフトウェアをインストールできない

C. 障がいのあるユーザーがアプリを操作できない

D. 一部のソフトウェアコンポーネントが交換できない

E. コンポーネント間で誤ったデータがやり取りされる

正解：

👉 C と E

解説：

• C：これは**アクセシビリティ（Accessibility）**の問題であり、移植性ではない。

• E：データ交換の不具合は**相互運用性（Interoperability）**の問題。

  一方、A・B・Dはすべて「環境間の移行」「インストール」「置換性」に関わるため、移植性に該当します。

問題5：ユーザビリティテストに関する正しい記述

質問：

次のうち、ユーザビリティテストに関して正しい記述はどれでしょうか？

選択肢：

A. ヒューリスティック評価を使ってユーザーにアンケートを取り、問題を見つける

B. 既存の不合格製品と比較してユーザビリティを確認する

C. 要件に基づきユーザビリティを検証し、実際のユーザーによって妥当性を確認する

D. 製品リリース後にユーザーを巻き込んで検証する

正解：

👉 C

解説：

ユーザビリティテストは「ユーザー視点での使いやすさ」を評価します。

したがって、要件に基づいて評価し、実際のユーザーが検証（Validation）を行うことが最も適切です。

Dのようにリリース後に検証するとコストが増大するため、テスト段階で実施するのが理想です。

まとめ

Chapter 4のサンプル問題は、単に定義を暗記するだけではなく、どの品質特性がどのシナリオに当てはまるかを判断する力が問われます。

これらを区別できるように、試験前にそれぞれの定義と例題を整理しておくことをおすすめします。

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

本記事ではISTQBアドバンストシラバス第4章「品質特性（Quality Characteristics）」の中から、

**ポータビリティテスト（Portability Testing）**の考え方・目的・テスト観点を詳しく解説します。

■ ポータビリティテストとは？

ポータビリティテストとは、

「開発したシステムやアプリケーションが、異なるハードウェアやソフトウェア環境にどの程度適応できるかを確認するテスト」

を指します。

環境（Environment）とは、OS・ハードウェア構成・ミドルウェア・ネットワーク設定など、

ソフトウェアを実行するための技術的な土台を意味します。

● テスト対象の具体例

たとえば、あるアプリケーションが次のような環境で動作できるかを確認します。

• OSの違い：Windows / macOS / Linux

• プロセッサの違い：Intel / AMD / ARM

• メモリ容量：4GB / 8GB / 16GB

• 外部ライブラリやミドルウェアのバージョンの違い　など

このような多様な環境で問題なく動作できるかを検証することで、

**移植性（Portability）**の高さを確認します。

■ ポータビリティのサブ特性（Sub-characteristics）

ISO/IEC 25010（旧ISO 9126）の品質モデルにおける「ポータビリティ」には、以下の3つのサブ特性があります。

1. インストール性（Installability）

2. 適応性（Adaptability）

3. 置換性（Replaceability）

それぞれの意味とテスト観点を具体的に見ていきましょう。

① インストール性（Installability）

■ 概要

インストール性テストとは、アプリケーションが異なる環境で正しくインストールできるかを確認するテストです。

■ 目的

• ソフトウェアが指定された環境で正常にインストールできるかを確認する

• アンインストール（削除）後も不要なデータが残らないことを確認する

• インストール手順（セットアップウィザードなど）がユーザにとって明確で使いやすいかを評価する

■ 具体例

例）ある業務アプリのインストーラーを使用して次を確認します。

• Windows 10／11 の両方で正しくインストールできるか

• インストール時の「次へ」「戻る」ボタンの動作が正しいか

• 管理者権限が必要な場合、エラーを出さずに案内が表示されるか

• アンインストール時に関連フォルダやレジストリが適切に削除されるか

② 適応性（Adaptability）

■ 概要

適応性テストとは、ソフトウェアが将来の変更や異なる環境に適応できるかを確認するテストです。

■ 目的

• OSやブラウザなどのアップデートに対応できるか

• 他のシステムやAPIとの連携に柔軟性があるか

• 地域・言語設定・通貨単位などを変更しても正常に動作するか

■ 具体例

例）PayPalの決済モジュールを開発した場合：

• 複数のECサイトやCMS（Shopify、WooCommerceなど）で統合できるか

• OSのバージョンアップ（Windows 10 → 11）後も正常に動作するか

• 多言語・多通貨設定（円／ドル／ユーロ）に対応しているか

このように、異なる利用条件でも機能を維持できるかがテストの焦点となります。

③ 置換性（Replaceability）

■ 概要

置換性テストとは、システムの一部コンポーネントを新しいものに置き換えられるかを確認するテストです。

■ 目的

• 新しいバージョンや機能に容易に置き換えられる設計か

• 交換後も他のコンポーネントと整合性が保たれているか

■ 具体例

例）自動車のインフォテインメントシステムを想定してみましょう。

• 古いUIモジュールを新デザインに変更しても、既存機能が影響を受けないか

• 音声認識エンジンを別ベンダー製に差し替えても動作するか

• ソフトウェア部品をアップデートしても、車載ネットワーク全体が安定しているか

また、日常的な例として「フォトフレームの写真を入れ替える」ように、

既存の枠組みを保ちながら中身を交換できることが置換性の本質です。

■ ポータビリティテストの重要性

現代のシステムは、クラウド、モバイル、IoT、車載など多様な環境で稼働します。

そのため、ポータビリティテストを実施することは以下のメリットにつながります。

• 異なる環境でのユーザー体験の一貫性を保証できる

• バージョンアップやマイグレーション時のリスクを低減できる

• 製品の長期的な維持管理コストを削減できる

特にテストアナリストは、**どの環境の組み合わせをテスト対象にするか（構成テスト戦略）**を

リスクベースで優先順位づけることが求められます。

■ まとめ

■ 例題（ISTQB風）

Q. 次のうち、ポータビリティテストに該当するものはどれか？

A. 新機能が正しく実装されていることを確認するテスト

B. システムが異なるOSで動作するかを確認するテスト

C. システムが負荷下でも応答時間を維持できるかを確認するテスト

D. ユーザーインターフェースの使いやすさを評価するテスト

正解：B

→ 異なるOSや環境間で動作を確認するのはポータビリティテストの目的です。

■ まとめの一言

ポータビリティテストは、ソフトウェアの長寿命化と市場適応力を高める重要な非機能テストです。

テストアナリストは、開発チームと協力して多様な環境を網羅し、

「どこでも動くソフトウェア」を保証する責任を担っています。

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

その中で「4.2.5 ユーザビリティテスト（Usability Testing）」は特に、実際のユーザー視点からソフトウェアの使いやすさを評価する重要なテーマです。

前回（Part 1）では、ユーザビリティの基本概念を紹介しました。

今回はその続きとして、ユーザビリティ評価の3つのアプローチを詳しく見ていきます。

🔍 ユーザビリティ評価の3つのアプローチ

ユーザビリティを評価するための代表的な方法は、次の3つです。

1. Usability Testing（ユーザビリティテスト）

2. Usability Reviews（ユーザビリティレビュー）

3. Usability Surveys & Questionnaires（アンケート・調査）

これらはそれぞれ異なる目的と実施方法を持ち、状況に応じて使い分けられます。

① Usability Testing（ユーザビリティテスト）

● 概要

ユーザビリティテストとは、実際のユーザーやテスターが製品を操作し、その使いやすさを検証する実行型テストです。

たとえば、オンラインショッピングサイトで「カートに商品を追加して購入手続きを完了する」というタスクを実際に操作して評価します。

● 目的

ユーザが特定の目的をどれだけ正確に、効率的に、そして満足して達成できるかを測定することが目的です。

● 主な評価指標（3つのE）

1. Effectiveness（有効性）

   　ユーザーが目標を正確かつ完全に達成できる能力。

   　例：「支払い画面まで迷わずに到達できたか」「誤操作がなかったか」

2. Efficiency（効率性）

   　ユーザーが目標達成のために必要とするリソース（時間・操作回数など）。

   　例：「購入手続きに何クリック必要だったか」「説明文を読む時間がどの程度だったか」

3. Satisfaction（満足度）

   　ユーザーが体験にどれだけ満足したか。

   　例：「使いやすいと感じたか」「他人に勧めたいと思うか」

● 実践例

例えば銀行アプリで「振込操作」を評価する場合、

• 入力フォームがわかりやすいか？

• エラーメッセージが適切か？

• 一連の操作がスムーズに完了できるか？

  といった観点で観察します。

テストアナリストはこれらを踏まえ、テスト設計時点でどのユーザビリティ特性を検証するかを明確化することが重要です。

② Usability Reviews（ユーザビリティレビュー）

● 概要

レビューとは、製品のUI（ユーザーインターフェース）設計や画面デザインを分析し、改善点を発見する手法です。

ドキュメントレビューと異なり、実際の画面やナビゲーションの流れを確認することがポイントです。

● 実施方法

• インスペクション（Inspection）：最も正式なレビュー。設計仕様やガイドラインを基準に、抜けや不整合を厳密にチェックします。

• ヒューリスティック評価（Heuristic Evaluation）：専門家が「ユーザビリティ原則（例：Nielsenの10原則など）」に照らしてUIを評価します。

● 具体例

たとえば、ユーザ登録画面をレビューするときに以下の点を確認します：

• ボタンや入力欄の配置が直感的か？

• エラーメッセージはユーザーに理解できる表現か？

• ナビゲーションが一貫しているか？

● ポイント

レビュー時は画面キャプチャやモックアップを用いると、テキストの仕様書よりも理解しやすく、改善提案が具体的になります。

ユーザビリティレビューでは、「目で見えるインターフェース」こそが重要な評価対象です。

③ Usability Surveys & Questionnaires（アンケート・調査）

● 概要

最後は、ユーザーからの主観的な意見を収集する方法です。

企業や団体が、世界中のユーザーから使いやすさに関するデータを集めています。

● 主な代表機関

1. SUMI（Software Usability Measurement Inventory）

   　ソフトウェアの使いやすさを測定するための標準的な質問票。

   　例：「操作に迷いがなかった」「システムが反応するまで待たされなかった」などを5段階評価で回答。

2. WAMMI（Website Analysis and Measurement Inventory）

   　Webサイト専用のユーザビリティ測定手法。

   　サイト訪問者に対して操作性・信頼性・デザインなどを評価してもらいます。

● 活用例

企業はこれらの調査データを参考にして、

• 自社製品のUI改善のベンチマークとして利用

• アクセシビリティや国際化対応の指標として活用

  することができます。

🧭 まとめ：ユーザビリティ評価で“本当の使いやすさ”を見極めよう

ユーザビリティテストは単なる「見た目の評価」ではなく、

ユーザーの体験（UX）全体を科学的に測定する活動です。

• 実行による検証（Usability Testing）

• 専門家による設計レビュー（Usability Review）

• エンドユーザーによる意見収集（Survey & Questionnaire）

この3つのアプローチをバランスよく組み合わせることで、

**「使いやすく、愛される製品」**を実現できます。

💡 補足：テストアナリストに求められるスキル

• ユーザー心理の理解力

• UI/UXデザインの基礎知識

• 定量・定性データの分析力

• コミュニケーションと観察スキル

これらのスキルがあることで、単なるテスト担当者ではなく、

**「ユーザー視点で品質をデザインできるQAプロフェッショナル」**になれます。

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon

はじめに

本記事では、**ISTQB Advanced Test Analyst シラバスのChapter 4（品質特性のテスト）**の中から、「4.2.5 ユーザビリティテスト（Usability Testing）」について解説します。

ユーザビリティテストとは、開発した製品やソフトウェアが**「ユーザーにとってどれだけ使いやすいか」**を評価するテストです。

シンプルに言えば、「このシステム、ユーザーにとって本当に分かりやすい？」という問いに答えるためのテストです。

1. ユーザビリティとは何か？

「ユーザビリティ（Usability）」とは、製品やシステムがどれだけ簡単に、効果的に、満足感を持って使えるかという品質特性を指します。

ユーザーが目的のタスクを完了するまでに感じる「使いやすさ」や「理解しやすさ」を評価します。

例えば、次のような観点で判断されます：

• 画面構成がわかりやすいか

• 用語がターゲットユーザーに合っているか

• 操作手順が自然でスムーズか

• エラーメッセージが理解しやすいか

2. テストアナリストに求められる役割

テストアナリストは、システムのユーザビリティ要件を理解し、

ターゲットユーザーの視点でテストを設計・実施する責任を持ちます。

たとえば：

• 銀行職員向けシステムの場合：

  専門用語（「借方」「貸方」「残高照会」など）が業務用語として自然か確認する。

• データ入力オペレーター向けシステムの場合：

  タブキーで入力項目を移動できるか、項目の並びが業務フローに沿っているか確認する。

ユーザー層（ITリテラシーの高い層・一般ユーザー・高齢者など）に応じて、評価基準を変える必要があります。

3. ユーザビリティの3つの主要側面

ISTQBでは、ユーザビリティに関連する要素を以下の3つに分類しています。

以下、それぞれ詳しく見ていきましょう。

4. Usability（ユーザビリティ）

ユーザビリティとは、ユーザーが簡単に学び、効率よく操作できるかという観点です。

この中には、さらにいくつかの**サブ特性（sub-characteristics）**が存在します。

主なサブ特性と例

これらを満たすことで、「直感的に使えるシステム」へと近づきます。

5. User Experience（ユーザー体験）

ユーザー体験とは、ユーザーが製品を使って感じる全体的な満足度や印象を意味します。

単なる操作性だけでなく、「また使いたい」と思えるかどうかも重要です。

ユーザー体験を左右する主な要素

• ブランドイメージ：その製品や企業への信頼感

• 操作の快適さ：反応速度やデザインの統一感

• ヘルプ機能の充実：サポート情報やチュートリアルが充実しているか

• インタラクティブ性：アニメーションやガイドがユーザーを助けるか

たとえばGoogleマップのUIが変更されたとき、初回起動時に「ツアー表示」で操作方法を案内するのも、UX向上の一例です。

6. Accessibility（アクセシビリティ）

アクセシビリティとは、障がいを持つ利用者を含め、誰でも公平に利用できるようにする配慮です。

たとえば、視覚・聴覚・身体的制限を持つユーザーにも使いやすくする設計が求められます。

代表的なアクセシビリティ機能の例

また、各国にはアクセシビリティの標準ガイドラインがあります。

例：

• WCAG（Web Content Accessibility Guidelines）

• ISO 9241-171

テストアナリストはこれらに準拠しているかどうかを、統合テストレベルや受け入れテストレベルで確認します。

7. ユーザビリティテストの実施タイミング

ユーザビリティテストは通常、以下のフェーズで行われます。

• 統合テスト段階：UIの一貫性や操作フローを確認

• 受け入れテスト段階：最終ユーザーによる実使用テスト（ユーザ評価）

ここでのフィードバックは、製品の最終品質とブランドイメージを大きく左右します。

8. まとめ

ユーザビリティテストは、機能が動くかどうかを確認するテストではなく、

ユーザーが満足して使えるかを確認するためのテストです。

ポイントを整理すると：

• ターゲットユーザーを明確にする

• 学習容易性・操作性・エラー防止などを評価する

• 見た目だけでなく「使って気持ちいい」体験を重視する

• アクセシビリティも含めて、誰にでも優しい設計を意識する

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

posted with カエレバ

楽天市場

Amazon

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

posted with カエレバ

楽天市場

Amazon