ソフトウェア品質特性のテスト（JSTQB AL TA v3.1.1 第4章）
JSTQB AL TA シラバス v3.1.1 第4章では、ISO/IEC 25010（2011年版）が定義するプロダクト品質モデルをもとに、テストアナリスト（TA）とテクニカルテストアナリスト（TTA）それぞれが担当する品質特性とテスト手法を定義しています。
担当区分の概要
| 品質特性 | 副特性 | TA | TTA |
|---|---|---|---|
| 機能適合性 | 機能正確性・機能適切性・機能完全性 | ○ | |
| 信頼性 | 成熟性・障害許容性・回復性・可用性 | ○ | |
| 使用性 | 適切度認識性・習得性・運用操作性・ユーザーインターフェース快美性・ユーザーエラー防止性・アクセシビリティ | ○ | |
| 性能効率性 | 時間効率性・資源効率性・容量満足性 | ○ | |
| 保守性 | 解析性・修正性・試験性・モジュール性・再利用性 | ○ | |
| 移植性 | 適応性・設置性・置換性 | ○ | ○ |
| セキュリティ | 機密性・インテグリティ・否認防止性・責任追跡性・真正性 | ○ | |
| 互換性 | 共存性 | ○ | |
| 互換性 | 相互運用性 | ○ |
TAはビジネスドメイン視点の品質特性（機能適合性・使用性・相互運用性・移植性の一部）を主に担当し、TTAはより技術的な品質特性（信頼性・性能効率性・保守性・セキュリティ・互換性の共存性）を担当します。
TA担当：機能適合性（Functional Suitability）
テストアナリストは機能適合性テストに主に重点を置きます。機能適合性テストは、テスト対象が「何をするのか」に重点を置き、要件・仕様・固有のドメイン知識・暗黙のニーズをテストベースとします。
4.2.1 機能正確性テスト（Functional Correctness Testing）
明示的または暗黙的な要件にアプリケーションが準拠していることを検証します。計算の精度もテスト対象です。
テスト手法：
- 同値分割法、境界値分析、デシジョンテーブルテスト、状態遷移テストなど多様なブラックボックステスト技法を適用
- テストオラクルとして仕様書または旧システムを使用
適用タイミング： すべてのテストレベルで実施可能
検出できる欠陥： データや状態の誤った処理
4.2.2 機能適切性テスト（Functional Appropriateness Testing）
意図および指定された任務に対して、一連の機能が適切であることを評価・妥当性確認します。
テストベース： ユースケース・ユーザーストーリーなどの機能設計
適用タイミング： 主にシステムテスト時（統合テストの後半段階でも実施する場合あり）
検出できる欠陥： 許容できる方法であってもシステムがユーザーのニーズを満たすことができない問題（機能そのものは正しくても、使われ方として適切でない場合）
4.2.3 機能完全性テスト（Functional Completeness Testing）
実装した機能が指定された任務およびユーザー目的に対するカバレッジを判定するために実行します。
テストのポイント：
- 仕様アイテム（要件・ユーザーストーリー・ユースケースなど）と実装された機能性（機能・コンポーネント・ワークフローなど）の間のトレーサビリティが不可欠
- テストマネジメントツールを使用してトレーサビリティを維持
SDLCごとの特性：
| SDLCモデル | 機能完全性の測定方法 |
|---|---|
| アジャイル | 実装されたユーザーストーリーおよびフィーチャーに基づく |
| システム統合テスト | ハイレベルなビジネスプロセスのカバレッジに重点 |
検出できる欠陥： 期待される機能完全性を達成できない場合はシステムの実装が不完全であることを示す
TA担当：相互運用性（Interoperability）
2つ以上のシステムまたはコンポーネントが情報を交換できることを検証します。互換性（Compatibility）の副特性として分類されますが、TAが担当します。
テストのポイント：
- ハードウェア・ソフトウェア・ミドルウェア・オペレーティングシステムなどのバリエーションを含むすべての意図した対象環境をカバー
- 現実的には代表的な環境グループに限定することがある
- システムは複数のレベルで相互運用を行う可能性があるため、テストアナリストはそれらの相互作用を理解し、様々な相互作用を動作させる条件を作成できる必要がある
適用できるテスト技法： 同値分割法・境界値分析・デシジョンテーブル・状態遷移図・ユースケース・ペアワイズテスト
適用タイミング： コンポーネント統合テスト時およびシステム統合テスト時
検出できる欠陥： 相互作用するコンポーネント間の不適切なデータ交換
特に重要な対象：
- 市販の既成ソフトウェアプロダクトやツール
- システムオブシステムズに基づくアプリケーション
- IoT（モノのインターネット）に基づくシステム
- 他のシステムとの接続を有するWebサービス
TA担当：使用性（Usability）
テストアナリストは使用性の評価作業を調整・支援する立場にあります。使用性テストケースの仕様化、またはユーザーと一緒にテストケースを実施するモデレーターとしての役割を担います。
使用性の3つの側面
使用性（Usability）
ユーザーインターフェースを介して任務をこなすユーザーの操作のしやすさに影響を与えるソフトウェア欠陥を対象とします。
副特性（ISO 25010）：
| 副特性 | 内容 |
|---|---|
| 適切度認識性 | ユーザーが自分のニーズに合っているか理解できる |
| 習得性 | ユーザーが操作方法を簡単に学べる |
| 運用操作性 | ユーザーが容易に操作・制御できる |
| ユーザーインターフェース快美性 | UIが魅力的・美的に優れている |
| ユーザーエラー防止性 | ユーザーが操作ミスをしないよう保護されている |
| アクセシビリティ | 障害を持つ人など多様なユーザーが利用できる |
使用性の問題が引き起こす事象： ユーザー側の混乱・エラー・遅延・タスク完了不能
ユーザーエクスペリエンス（UX）
直接操作だけでなく、テスト対象のUX全体を評価します。
UXに影響する典型的な要因：
- ブランドイメージ（製造元に対するユーザーの信頼）
- 相互に作用する振る舞い
- テスト対象の使いやすさ（ヘルプシステム・サポート・トレーニングを含む）
アクセシビリティ（Accessibility）
特定のニーズまたは制限を持つユーザーのためにソフトウェアへのアクセシビリティを考慮します。
参照すべき標準・法律：
- WCAG（ウェブコンテンツ・アクセシビリティ・ガイドライン）
- 障害者差別禁止法（北アイルランド・オーストラリア）、2010年平等法（英国）、第508条（米国）
アクセシビリティ向上の典型的な手段：
- 音声認識による入力
- テキスト以外のコンテンツへの同等の代替テキストの提供
- コンテンツや機能を損なうことなくテキストサイズを変更可能にすること
適用タイミング： 統合テストレベルから開始し、システムテスト・受け入れテストまで継続
使用性評価の3つの手法
1. 使用性テスト
ユーザーが特定の状況で特定のゴールに到達できるかをテストします。
測定する3つの項目：
| 測定項目 | 内容 |
|---|---|
| 有効性 | 指定された利用状況で、正確かつ安全に指定されたゴールを達成できるか |
| 効率性 | 有効性を達成するために、ユーザーが適切なレベルのリソースを使用しているか |
| 満足性 | 指定された利用状況で、利用者を満足させるか |
使用性テストの設計と仕様化は、テストアナリストが使用性テストの専門スキルを持つテスト担当者・使用性設計エンジニアと協力して行うことが多い。
2. 使用性レビュー
インスペクションとレビューにより、使用性の問題をSDLCの早期（要件仕様・設計段階）に発見します。
ヒューリスティック評価：
- 少数の評価者によりインターフェースを検証し、認識済みの使用性原則（「ヒューリスティック」）に適合しているか判断
- 設計における使用性の問題を発見するために使用
- イテレーティブな設計プロセスの一部として取り組める
3. 使用性の調査およびアンケート
システムを操作するときのユーザーの振る舞いに関する所見やフィードバックを収集します。
標準的な調査方法：
| ツール | 特徴 |
|---|---|
| SUMI（ソフトウェア使用性測定一覧表） | 使用性に関する明確な測定値を提供。過去の測定データベースとベンチマーク比較が可能。完了基準・受け入れ基準を提供できる |
| WAMMI（Webサイト解析と測定一覧表） | Webサイトの使用性測定に特化 |
TA・TTA共同担当：移植性（Portability）
ソフトウェアコンポーネントまたはシステムを新規インストールとして、もしくは既存環境から意図した環境へ移植できる度合いです。リスクの識別とテストケースの設計はTAとTTAが協力して作業します。
ISO 25010の副特性：
| 副特性 | 担当 | 内容 |
|---|---|---|
| 設置性 | TA中心 | 対象とする環境へのインストール・アンインストールをテスト |
| 環境適応性 | TA中心 | 意図したすべての対象環境で正しく機能するかを確認 |
| 置換性 | TA中心 | システム内のコンポーネントやバージョンを他のものに置換できるかをテスト |
設置性テスト（TA担当）
TAが焦点を当てる典型的なテスト目的：
- 様々な構成で正常にインストールできることを確認（構成パラメーターが多い場合はペアワイズ技法を適用）
- インストール・アンインストールの手順の機能正確性をテスト
- インストール・アンインストール後に機能適合性テストを実行して発生欠陥を検出
- インストール・アンインストール手順における使用性の問題を識別（わかりやすい説明・フィードバック・エラーメッセージの提供を検証）
環境適応性テスト（TA担当）
意図したすべての対象環境（ハードウェア・ソフトウェア・ミドルウェア・OS・クラウドなど）でアプリケーションが正しく機能するかを確認します。TAは意図する対象の環境を識別し（様々なモバイルOSのサポート対象バージョン・ブラウザーのバージョンなど）、これらの環境の組み合わせをカバーするテストを設計します。
置換性テスト（TA担当）
システム内のソフトウェアのコンポーネントまたはバージョンを他のものに置換できる能力に焦点を当てます。IoTに基づくシステムアーキテクチャーに特に関係します。完成システムに統合するための複数の代替コンポーネントを使用できる場合、機能統合テストと並行してTAが実行できます。
TTA担当：信頼性（Reliability）
指定された条件下で、指定された時間、システムが障害なく動作し続ける度合い。
| 副特性 | 内容 |
|---|---|
| 成熟性 | 通常運用中の故障を回避できる |
| 障害許容性 | 障害が発生してもシステムが動作を継続できる |
| 回復性 | 中断・障害発生時にデータを復旧しシステムが回復できる |
| 可用性 | ユーザーが必要なときにシステムを利用できる |
TTA担当：性能効率性（Performance Efficiency）
特定の条件下でリソースをどの程度効率的に使用するかの度合い。
| 副特性 | 内容 |
|---|---|
| 時間効率性 | 応答時間・処理時間・スループット率が要件を満たす |
| 資源効率性 | CPU・メモリなどのリソース使用量が適切 |
| 容量満足性 | 最大制限（ユーザー数・データ量など）が要件を満たす |
TTA担当：保守性（Maintainability）
システムの修正・改良、または環境変化への適応が容易である度合い。
| 副特性 | 内容 |
|---|---|
| 解析性 | 欠陥の原因や変更の影響を容易に診断できる |
| 修正性 | 欠陥を発生させずにシステムを修正できる |
| 試験性 | 修正されたシステムをテストしやすい |
| モジュール性 | 変更の影響を局所化できる独立したモジュールで構成されている |
| 再利用性 | 資産・コンポーネントを他のシステムで再利用できる |
TTA担当：セキュリティ（Security）
情報やデータを保護し、権限に応じたアクセスを保証する度合い。
| 副特性 | 内容 |
|---|---|
| 機密性 | 権限のない者からデータを保護できる |
| インテグリティ | データの正確さと完全性を保護できる |
| 否認防止性 | イベント・行動を後から否認されないよう証明できる |
| 責任追跡性 | どのアクションが誰によって行われたかを追跡できる |
| 真正性 | 主体やリソースの身元が本物であることを証明できる |
TTA担当：互換性（Compatibility）—共存性
他のシステムに悪影響を与えずに同じ環境で動作できる度合い。共存性はTTAが担当し、相互運用性はTAが担当します。
| 副特性 | 担当 | 内容 |
|---|---|---|
| 共存性 | TTA | 他のソフトウェアに悪影響を与えずに同じ環境で動作できる |
| 相互運用性 | TA | 他のシステムと正しく情報を交換し利用できる |
参考
- JSTQB AL テストアナリスト シラバス v3.1.1 第4章（4.1〜4.2.6節）
- ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
- 付録A：ISO 25010と旧規格ISO 9126の用語対応表（シラバスp.76）