ソフトウェアテストの概観を識る/Understanding_overview_of_software_testing

ソフトウェアテストの概観を識る Ver. 9.00（2026年度版） 2026年10月16日(金) 於日本科学技術連盟ソフトウェア品質管理研究会（SQiP研究会）ソフトウェア品質保証の基礎コーステスト技術 Copyright
© 2017-2026 Takashi YAMASAKI All right reserved. 1

株式会社ベリサーブ品質保証部プロジェクト推進課課長
兼ソフトウェア品質コンサルティング部山﨑崇（YAMASAKI Takashi） 2001年からセキュリティ対策ベンダーにおいて、さまざまなプロジェクトのソフトウェアテスト活動にQAエンジニアとして従事。その傍ら、さまざまなテストコミュニティに参画し、活動の場を広げる。2015年にベリサーブに入社。現場への技術支援、教育、コンサルテーションなどを担い、少しでも現場が幸せになるように日々奮闘中。主な活動主な講演 • SQuBOKガイドV4 策定部会（’25～） • JaSST’26 Kansai「テスト設計の本質を改めて考えてみる」 • JaSST東京実行委員会（’11～） • SQiPシンポジウム 2024併設チュートリアル「テスト戦略」 • テスト設計コンテストU-30審査委員（’16～） • • ASTER テストプロセス改善研究会（’16～） • JSTQB Foundation Level 認定講師（’12～） WACATE2023夏招待講演「テスト開発について改めて考えてみよう～テスト分析やテスト設計を業務で上手くできるようになるための四方山話」 • JaSST’22四国「テストを学び成長する 2022年度版」 • JaSST’21北陸基調講演「テストを学び成長する」 • JaSST’17東北基調講演「テストの極みを目指して」 • JaSST‘15東京チュートリアル「初心者からの脱出」 • テスト設計コンテストチュートリアル U-30クラス（’17～’19）ちびこん編（’21 など主な著書・訳書 • 実践ソフトウェアエンジニアリング第9版（共訳） • 今さら聞けないソフトウェアテストの国際規格： ISO/IEC/IEEE 29119シリーズを読みはじめる前に（著） • 開発現場で役立つテスト「超」実践講座第9回（著） • システム開発ジャーナル Vol.10 （共著） • テスト技術者資格制度Foundation Level Extension シラバスアジャイルテスト担当者（共訳）） • SQiP研究会品質保証基礎コーステスト技術「ソフトウェアテストの概観を識る」（’17, ’20～） • 第14回SPIトワイライトフォーラム「テストプロセス改善モデルの最新動向」などなどその他 https://www.linkedin.com/in/yamasaki696/ を参照 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 2

ありがたいことに日本語で得られるテストの情報は2001年以降爆発的に増加しました「図：テストを主題とした書籍の年別出版数」※講演者当人の厳格ではない調査に基づいて作成したもの Copyright © 2017-2026 Takashi YAMASAKI All right
reserved. 4

一方ではさまざまな情報の中から自分の求めている情報を的確に見つけるのが難しいとも言えます Copyright © 2017-2026 Takashi YAMASAKI All right
reserved. 5

この研修のゴール 1. ソフトウェアテストについての全体像を俯瞰し、整理できる軸を持つことでさまざまなテストの用語がどういった特性の言葉であるか判断できるようになりましょう 2. テストの要素技術に関するエントリーポイントを把握して、効率よくテストについて学べる下地を持ちましょう Copyright ©
2017-2026 Takashi YAMASAKI All right reserved. 6

理解への第一歩は言葉を知ることから Copyright © 2017-2026 Takashi YAMASAKI All right reserved.
9

でもこの業界「••テスト」や「テスト••」だらけ… デシジョンテーブルテストブラックボックステスト統合テストテスト駆動開発負荷テスト性能テストスモークテストテストデータシステムテスト
テストウェアユニットテストベータテストテストベース非機能テストテストツールテスト戦略テスト環境モンキーテストテスト技法機能テストグレーボックステスト受け入れテストホワイトボックステスト探索的テストアルファテストステートメントテスト結合テストセキュリティテストストレステストテスト設計テスト条件テスト実装パステストテスト実行テストフレームワークテスト分析テスト管理テストアプローチテスト手順テストケーステスト報告コンパチビリティテストテスト計画ペネトレーションテスト Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 10

共通言語としてJSTQB FL 取得のススメソフトウェアテスト技術者の認定資格で、 Foundation Level は基礎レ
ベルを意味します ISTQBを通じて国際的にも有効な技術資格で、日本でも多くの資格所有者がいます JSTQBの言葉を借りてコミュニケーションを取ると、合意形成が捗りますまた、軸を持った上で学習すると、学習効率も高まります ※ JSTQB Foundation Levelシラバスが、v3.1 からv4.0にメジャーバージョンアップしました。試験がv4.0に基づくのは2024年の11月からとなります。なお、本資料は、v4.0の内容に準拠させています（が一部旧シラバスからも引用しています）。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 14

こんな感じで、随時気になったキーワードを独断と偏見によって貼り付けていってください Copyright © 2017-2026 Takashi YAMASAKI All
right reserved. 16

みなさんが思う、ソフトウェアのテストとは、どのようなイメージですか？ Copyright © 2017-2026 Takashi YAMASAKI All right reserved.
18

人によっても違うし成熟度によっても違うし千差万別フェーズ4 テストは行動ではない。大げさなテストをすることなく品質の高いソフトウェアを作るための精神的な訓練である。フェーズ3 テストの目的は、何かを証明することではなく、プログラムが動かないことによって発生する危険性をある許容範囲までに減らすことである。フェーズ2 テストの目的は、ソフトウェアが動かないということを示すこと
にある。フェーズ1 テストの目的は、ソフトウェアが動くことを示すことである。フェーズ0 テストとデバッグには何の差もない。デバッグ以外にはテストには特別な目的はない。ボーリス・バイザー著「ソフトウェアテスト技法」よりテスト担当者の精神面による区分を引用 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 19

テストがなぜ必要なの？テストって何だろう？テストの目的とは？ Copyright © 2017-2026 Takashi YAMASAKI All right
reserved. 20

ハードウェアソフトウェア物質的実体論理的集合体目に見える目に見えない触れられる触れられない物理化学法則に基づき物理化学法則に基づかず
自由度は低く自由度が高すぎ修正に関する修正に関する影響を把握しやすい影響を把握しにくい Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 21

ソフトウェアは人が作り、人は間違える生物誘因① 納期のプレッシャー誘因② 人間の誤りを犯しやすい性質誘因③ プロジェクト参加者の経験不足または技術不足誘因④ プロジェクト参加者間の誤ったコミュニケーション（要件や設計の誤ったコミュニケーションを含む）
誘因⑤ さまざまな複雑さ ※ コード、設計、アーキテクチャー、解決すべき根本的な問題, そして/または使用する技術の複雑さ誘因⑥ システム内またはシステム間のインターフェースに対する誤解 ※ 特に、関連するシステム数が多い場合誘因⑦ 新しく不慣れな技術など出典：テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.2．3 エラー、欠陥および故障」より（一部要約） Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 22

ソフトウェアは社会のいたるところにあり、最悪人が死んだり会社がつぶれたりします Copyright © 2017-2026 Takashi YAMASAKI All right reserved.
24

リリース後に見つかった欠陥の修正コストは高い Industry References:3 B. Boehm and V. Basili, “Software Defect
Reduction Top 10 List” IEEE Computer Society, Vol. 34, No. 1, Jan 2001を Roger S. Pressman(他)が「実践ソフトウェアエンジニアリング」(第9版)で要約したグラフを基に作図 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 25

品質コストという考え方品質コスト適合コスト不適合コスト欠陥を回避するためにプロ障害によりプロジェクト期間中ジェクトの期間中に支出するコおよび期間後に支出するコスストト
予防コスト評価コスト内部失敗コスト外部失敗コスト欠陥の発生を防止するために品質を評価することによって出荷前に欠陥が発見された場出荷後に欠陥が発見された場支出されるコスト品質レベルを維持するために合の処理に付随して支出され合の処理に付随して支出され支出されるコストるコストるコストプロジェクトの期間中に支出される品質コスト Copyright © 2017-2026 Takashi YAMASAKI All right reserved. プロジェクト期間外に支出される品質コスト 26

さまざまな要因からテストは必要になるソフトウェアの特性
誤りを犯す人間の特性 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 経営リスクへの備え経済的合理性 27

テストの目的も一義的ではない 1 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する 2 故障を引き起こし、欠陥を発見する 3 求められるテスト対象のカバレッジを確保する 4 ソフトウェア品質が不十分な場合のリスクレベルを下げる 5
仕様化した要件が満たされているかどうかを検証する 6 テスト対象が契約、法律、規制の要件に適合していることを検証する 7 ステークホルダーに根拠ある判断をしてもらうための情報を提供する 8 テスト対象の品質に対する信頼を積み上げる 9 テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする「テスト技術者資格制度Foundation Level シラバス Version 2023V4.0.J02」の「1.1.1 テスト目的」より引用 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 28

テストを動的テストと静的テストと整理する文脈もあるソフトウェアテスト動ステ的トテアスイ
トテムを実行して確認するテスト静ステ的トテアスイトテムの実行を伴わないテスト動的テスト静的テスト ” テストアイテムを実行して確認するテスト ” テストアイテムの実行を伴わないテスト本日の話は、基本的にこちら静的解析レビュー引用: ISTQB用語集動的テスト(Ver.2)および静的テスト(Ver.4)より。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 29

「テストとは？」を整理すると「品質に関わる新たな情報を得るための諸活動」 ※以下のテストの目的をすべて満たします欠陥を摘出する意志決定のための情報を示す対象ソフトウェアの品質レベルが十分であることを確認する欠陥の作りこみを防ぐ
上記4つのテストの目的は、テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 30

テストの原則原則 1 テストは欠陥があることは示せるが、欠陥がないことは示せない原則 2 全数テストは不可能原則
3 早期テストで時間とコストを節約原則 4 欠陥の偏在原則 5 テストの弱化原則 6 テストはコンテキスト次第原則 7 「欠陥ゼロ」の落とし穴「テスト技術者資格制度Foundation Level シラバス Version 2023V4.0.J02」の「1.3 テストの原則」より引用 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 31

余談:STARによるテスト自動化の8原則原則 1 手動テストはなくならない原則 2 手動でおこなって効果のないテストを自動化しても無駄である原則 3 自動テストは書いたことしかテストしない
原則 4 テスト自動化の効用はコスト削減だけではない原則 5 自動化テストシステムの開発は継続的におこなうものである原則 6 自動化検討はプロジェクト初期から原則 7 自動テストで新種のバグが見つかることは稀である原則 8 テスト結果分析という新たなタスクが生まれる出典: テスト自動化研究会の「テスト自動化の8原則」(テスト自動化研究会)より

余談: テストの7原則（ヘッツェル@1974）原則 1 セグメンテーション原則 2 可テスト性を持つ設計原則 3
シミュレーション原則 4 サンプリング原則 5 論理的簡約原則 6 標準化原則 7 自動化出典: ウイリアム.C.ヘッツェル著「プログラム・テスト法」 (1974) 近代科学社刊) より引用

本質的にテストの価値は情報取得早い安いテストから得られる情報の取得タイミングが早いほど価値が高いテストから得られる情報の取得コストが安いほど価値が高いテストから得られる情報がニーズに合致
旨いしていて正確で分かりやすいほど価値が高い Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 34

テストを通じて得られた情報によって製品やサービスの品質に対する確信度合いを積み上げていく逆説的には、テストをしなくて済むのであれば、誰もがそれをしたくないけれども、ソフトウェアの特性や人の特性やソフトウェア開発の背景などから、テストという手段を用いてその結果を見ないことには、リリースしても大丈夫であるかどうかを判断する術がない Copyright © 2017-2026 Takashi YAMASAKI
All right reserved. 35

情報はそれを使うことで意味を持つテストはテストのみでは存在し得ない活動（テストのことだけ考えても意味がない） Copyright © 2017-2026 Takashi YAMASAKI All right
reserved. 36

テストとは、テストとそれに関係するテスト以外のことについても考えに考え抜いてそれらの本質を知ること Copyright © 2017-2026 Takashi YAMASAKI All right
reserved. 37

テストレベルとは？ “ テストレベルは、系統的にまとめ、マネジメントしていくテストの活動のグループである。「テスト技術者資格制度Foundation Level シラバス Version 2023V4.0.J02」の「2.2 テストレベルとテストタイプ」より
“ 具体的にインスタンス化したテストプロセス。 ISTQB Glossary「テストレベル」(Ver.2)より Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 40

さまざまなテストレベルが存在する大受け入れテスト妥当性確認と、デプロイの準備ができていることの実証に焦点を当てたテストレベルシステム統合テストテスト対象システムと他のシステム、外部サービスとのインターフェースのテストに焦点を当てたテストレベルシステムテストシステム全体が特定の要件を満たしていることを確認することに焦点を当てたテストレベルコンポーネント統合テストコンポーネント間のインターフェースや相互作用に焦点を当てたテストレベル
テスト対象として着目する詳細度コンポーネントテスト個々のハードウェアまたはソフトウェアコンポーネントに焦点を当てたテストレベル Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 小41

上流工程の開発と下流工程のテストにおける責務との対応関係要求分析段階的な詳細化受け入れテスト
アーキテクチャー設計基本設計詳細設計実装システム統合テストシステムテストコンポーネント統合テスト段階的な統合コンポーネントテスト対応関係 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 43

Wモデル: テスト活動をフロントローディングすると効果的テスト活動の開始要求定義システム要件受け入れテストの実施システムテスト
の計画基本設計システムテストの実施統合テストの計画統合テストの実施コンポーネントテストの計画詳細設計コンポーネントテストの実施デバッグと修正デバッグと修正デバッグと修正デバッグと修正実装対応関係サイクル:テスト、デバッグ、修正、再テスト Andreas Spillner 著 The W-MODEL Strengthening the Bond Between Development and Test より引用。翻訳は独自 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 44

ただ、Wモデルの実践は簡単ではありません湯本さんの記事を読むと少しイメージが湧くかも https://note.mu/yumotsuyo/n/n83fee4567b5d Copyright © 2017-2026 Takashi YAMASAKI All right
reserved. 45

Wモデル: テスト活動をフロントローディングすると効果的（マスターテスト計画）プロジェクトテスト計画 project test plan テスト活動の開始
要求定義受け入れテストの実施受け入れテストのレベルテスト計画 level test plan システム要件システムテストの計画システムテストの実施デバッグと修正デバッグと修正システムテストのレベルテスト計画 level test plan 基本設計統合テストの計画統合テストの実施デバッグと修正統合テストのレベルテスト計画 level test plan コンポーネントテストの計画詳細設計コンポーネントテストの実施コンポーネントテストのレベルテスト計画 level test plan デバッグと修正実装各テストレベルだけではなくテスト全体の戦略を考えよう対応関係サイクル:テスト、デバッグ、修正、再テスト Andreas Spillner 著 The W-MODEL Strengthening the Bond Between Development and Test より引用。翻訳は独自 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 46

※シラバスの内容をもとに表として整理したもの（表中の文章はシラバスからの引用。強調は独自）属性特定の目的テス
トベースの例テスト対象の例統合テストコンポーネントテストシステムテストコンポーネント統合テスト受け入れテストシステム統合テスト • リスクの低減 • リスクの低減 • • コンポーネントの機能的/非機能的振る舞いが設計および仕様通りであることの検証 • インターフェースの機能的/非機能振る舞いが設計および仕様通りであることの検証 • システムの機能的/非機能振る舞いが設計および仕様通りであることの検証 • システムの機能的/非機能振る舞いが仕様通りであることの検証 • システムが完成し、期待通りに動作することの妥当性確認 • システムが完成し、期待通りに動作することの妥当性確認 • システムの全体的な品質に対する信頼の積み上げリスクの低減 • コンポーネント品質に対する信頼の積み上げ • インターフェース品質に対する信頼の積み上げ • システムの全体的な品質に対する信頼の積み上げ • コンポーネントに存在する欠陥の検出 • 欠陥の検出（インターフェース自体、コンポーネントに内在、またはシステムに内在） • 欠陥の検出 • 欠陥がより高いテストレベルまで見逃されることの防止 • 欠陥がより高いテストレベルまで見逃されることの防止 • 欠陥がより高いテストレベルまたは運用環境まで見逃されることの防止 • 詳細設計 • コード • データモデル • コンポーネント仕様 • ソフトウェア設計とシステム設計 • シーケンス図 • インターフェースと通信プロトコルの仕様 • ユースケース • コンポーネントレベル又はシステムレベルのアーキテクチャ • ワークフロー • 外部インターフェース定義 • システム要求仕様およびソフトウェア要求仕様（機能および非機能） • リスク分析レポート • ユースケース • エピックおよびユーザーストリー • システム振る舞いのモデル • 状態遷移図 • システムマニュアルおよびユーザーマニュアル • ビジネスプロセス • ユーザー要件またはビジネス要件 • 規制、法的契約、標準 • ユースケースおよび/またはユーザーストーリー • システム要件 • システムドキュメントまたはユーザードキュメント • インストール手順 • リスク分析レポート • コンポーネント、ユニット、またはモジュール • コードとデータ構造 • クラス • データベースモジュール • サブシステム • データベース • インフラストラクチャー • インターフェース • API • マイクロサービス • アプリケーション • ハードウェア/ソフトウェアシステム • オペレーティングシステム • テスト対象システム（SUT） • システム構成および構成データ • テスト対象システム • システム構成および構成データ • 完全に統合されたシステムのビジネスプロセス • リカバリシステムおよび(ビジネス継続性および災害復旧のテスト用の)ホットサイト • 運用プロセスおよびメンテナンスプロセス • 書式 • レポート • 既存または変換(コンバージョン)した本番データ • 正しくない計算 • 正しくない、または期待通りではないシステムの機能的または非機能的振る舞い • システム内の正しくないコントロールフローおよび/またはデータフロー • エンドツーエンドの機能的タスクを適切かつ完全に実行できない • システム環境でシステムが適切に動作しない • システムマニュアルおよびユーザーマニュアに記載されている通りにシステムが動作しない • システムのワークフローがビジネス要件またはユーザー要件を満たさない • ビジネスルールが正しく実装されていないシステムが契約要件または規制要件を満たさない • セキュリティの脆弱性、高負荷時の不適切な性能効率、サポート対象プラットフォームでの不適切な操作などの非機能特性の故障 ― ― 独立したテストチーム顧客、ビジネスユーザ、プロダクトオーナー、またはシステム運用担当者 ※他のステークホルダーも関与する場合あり典型的な欠陥と故障の例 • 正しくない機能（例えば、設計仕様の記述とは異なる） • データフローの問題 • 正しくないコードとロジックロアープチ TDD（テスト駆動開発) 責務コードを開発した開発担当者当人その他モックオブジェクト, サービス仮想化, ハーネス, スタブ, ドライバ, テストファースト • 正しくないデータ、データ不足、正しくないデータエンコーディング • インターフェース呼び出しの正しくない順序またはタイミング • インターフェースの不整合 • コンポーネント間のコミュニケーション故障 • コンポーネント間のコミュニケーション故障の処理不在、または不適切な処理 • コンポーネント間で渡されるデータの意味、単位、境界の正しくない思い込み • システム間で一貫性のないメッセージ構造 • 正しくないデータ、データ不足、正しくないデータエンコーディング • インターフェースの不整合システム間通信による故障 • システム間通信処理不在、または不適切な処理による故障 • システム間で渡されるデータの意味、単位、境界の正しくない思い込み • 必須のセキュリティ規制への非準拠 CI（継続的インテグレーション）開発担当者テスト担当者統合戦略、トップダウン、ボトムアップ、ビックバン Copyright © 2017-2026 Takashi YAMASAKI All right reserved. データ品質偽陽性, 偽陰性 • ユーザー受け入れテスト • 運用受け入れテスト • 契約による受け入れテストおよび規制による受け入れテスト 47 • アルファテストおよびベータテスト

コンポーネントテストレベルでの自動化コンポーネントテスト(ユニットテスト)レベルでの自動化は、xUnitなどのテストフレームワークを使うことが多いので、開発言語など自分の状況に合ったものを選択しましょう。コンポーネントレベルでは実装とテストを同じ人が担うことも多く、特定のアプローチとしてはテスト開発駆動(TDD: Test Driven
Development)が有名です。各地域のコミュニティが中心となって全国各地でテスト駆動開発入門ケント・ベック著/オーム社刊 TDD Boot Camp開催しているので、そこで体験してみるのもお勧めです（コロナ禍以降活動休止中な様子）。 TDDの提唱者ケント・ベックの書籍。ピアソンショックにより絶版となっていたが、2017年にオーム社からt_wadaさんの新訳で復刊され、入手可能 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 48

統合テストレベルでの自動化統合テスト(インテグレーションテスト)レベルでの自動化に関しては、CI環境を用いることが一般化してきました。継続的インテ
グレーション (CI: Continuous Integration)は、日毎、時毎、コミット毎といった短いサイクルでテストを走らすことで、統合に関係する問題を素早く見つけることが目的です。オープンソースではJenkinsが有名ですが商用の CIアプリやサービスなども存在するので自分たち継続的インテグレーション入門にあったものを選択しましょう。著者多数/日経BP刊特定のCI環境に特化したものではなく、概念レベルからしっかりと解説している書籍。特定のCI環境に特化した書籍と合わせて読むと効果的かと。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 49

システムテストレベルでの自動化システムテストのテストレベルにおいても、自動化を行うことは一般化してきました。そのシステムテストレベルにおける自動化を扱った書籍が左記のものです。また、この書籍を翻訳したシステムテスト自動化研究会が毎年開催してるシステムテスト自動化カンファレンス（STAC）の資料も公開も参考になります。特に最近は、AIの技術を使ったテストスクリプトのオートヒーリングなどを備えた自動化ツールなどが、
シスエムテスト自動化標準ガイド利用されています。マーク&ドロシー著/翔泳社刊テスト自動化研究会が翻訳した「Software Test Automation 」。著者はマーク&ドロシー。邦題はシステムテスト全般を指しているように見えるが機能テストの自動化かメイン。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 50

受け入れテストレベルでの自動化受け入れテストのテストレベルは、DevOpsや CD （継続的デリバ
リー Continuous Delivery, 継続的デプロイメント Continuous Delivery）の領域を考慮します。左の書籍は、継続的デリバリーを主題に扱っています。ソースコードに変更を加えてからデプロイまでの一連の流れを「デプロイメントパイプライン」継続的デリバリー Jez Humble & David Farley 著 ASCII DOWANGO刊としてパイプライン化（つまり自動化）することで、アジリティのある開発とリリースを可能にします。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 51

テスト実行の自動化は低いテストレベルから低難遅手動テスト E2E テスト費用対
効果保守性実行速度 APIレベルのテストユニットテスト/ コンポーネントテスト高易速出典：「実践アジャイルテスト」の「テスト自動化のピラミッド」を基に改変・追記 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 53

アイスクリームコーン（自動テストのアンチパターン）手動テスト手動テスト E2E テスト自動化GUIテスト APIレベルのテスト統合テスト
ユニットテスト/ ユニットテストコンポーネントテスト出典: Testing Pyramids & Ice-Cream Cones | Alister Scott より（翻訳は独自） Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 54

テストトロフィー (フロントエンド向けのテスト自動化戦略) E2E 統合ユニット静的解析出典: The Testing Trophy
and Testing Classificationsより（翻訳は独自） Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 55

DevOpsでの継続的テストのループここでテストここでテストここでもテスト RELEASE PLAN BRANCH
ここでテスト CODE さらにここでもテスト DEPLOY Dev Ops OPERATE MERGE そしてここでも BUILD さらにここでもテスト MONITOR そしてここももちろん… ここでテストしないの？もちろんできます！出典：Dan AshbyのContinuous Testing in DevOpsを引用した書籍「A Practical Guide to Testing in Dev Ops」に翻訳本 P.xiii Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 56

テストレベルの本質を考えていくとソフトウェア開発ライフサイクルに留まらずソフトウェアライフサイクル全般におけるテストの全体像を考えていくことに繋がる Copyright © 2017-2026 Takashi YAMASAKI All
right reserved. 57

テストタイプとは？ “ テストタイプは、以下に列挙する特定のテストの目的から見たソフトウェアシステム（あるいはシステムの一部分）の特性をテストするための活動を束ねたものである。テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より引用 “
コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。 ISTQB Glossary https://glossary.istqb.org より引用 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 60

JSTQBによるテストタイプの分類機能テスト非機能テストコンポーネント、およびシステムが実行する機能をコンポーネント、およびシステムが実行する機能特評価する。機能とはテスト対象が「何」をすべきか性以外の属性を評価する。非機能テストは、システである。機能テストの主な目的は、機能完全性、機ムが「どのようにうまく振る舞うか」をテストする。能正確性、および機能適切性をチェックすること
非機能テストの主な目的は、非機能的なソフトである。ウェア品質特性をチェックすることである. ブラックボックステストホワイトボックステスト仕様に基づき、テスト対象の外観を示すドキュメン構造に基づき、システムの実装または内部構造トからテストを導出する。ブラックボックステスト（コード、アーキテクチャー、ワークフロー、データの主な目的は、システムの動作をその仕様に照らフローなど）からテストを導き出す（4.3 節参照）。してチェックすることである。ホワイトボックステストの主な目的は、テストによって基本的な構造を受け入れ可能なレベルまでカバーすることである。テスト技術者資格制度 Foundation Levelシラバス日本語版Ver.4.0J02「2.2.2 テストタイプ」より文章を引用（強調と作図は独自）。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 61

個人的には古いテストタイプの分類の方が扱いやすくておすすめテストタイプの分類機能テスト非機能テスト構造テスト（ブラックボックステスト）（ブラックボックステスト）（ホワイトボックステスト）機能の品質特性、例えば完全、非機能の品質特性、例えば信
正確および適切であることな頼性、性能効率性、セキュリどを評価する。ティ、互換性、使用性などを評価する。コンポーネントまたはシステムの、構造またはアーキテクチャーが正しく完全で仕様通りであることを評価する。変更関連のテスト欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを探す（リグレッションテスト）。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 62

ブラックボックステストとホワイトボックステストの区別入力出力入力出力ブラックボックスとは、対象の中身（内部構造）ホワイトボックスとは、対象の中身（内部構造）が見えないことを言う一般名詞。が見えることを言う一般名詞。ブラックボックステストは、コンポーネントまた
ホワイトボックステストは、コンポーネントまたはシステムの内部構造を参照しない、機能またはシステムの内部構造の分析に基づいたテスは非機能テストのこと。ト（テストタイプ）のこと。ブラックボックステスト技法は、内部構造を参ホワイトボックステスト技法は、コンポーネント照せずに、コンポーネントまたはシステムの仕またはシステムの内部構造の分析に基づいて、様（機能または非機能）の分析に基づいてテステストケースを導出および/または選択するトケースを導出および/または選択する手順の手順のこと。こと。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 63

ISO/IEC 25010の製品品質モデル ※ISO/IEC 25010は2023に改訂されて、上記から構成が変わっています。システム/ソフトウェア製品品質機能適合性性能効率性互換性 • 機能完全性
• 機能正確性 • 機能適切性 • 時間効率性 • 資源効率性 • 容量満足性 • 共存性 • 相互運用性使用性信頼性セキュリティ適切度認識性習得性運用操作性ユーザエラー防止性 • ユーザインターフェース快美性 • アクセシビリティ • 成熟性 • 可用性 • 障害許容性 (対故障性) • 回復性 • 機密性 • インテグリティ • 否認防止性 • 責任追跡性 • 真正性 • • • • 保守性 • • • • • モジュール性再利用性解析性修正性試験性移植性 • 適用性 • 設置性 • 置換性 JIS X 25010:2013 図4「製品品質モデル」より引用（配色は独自）ソフトウェアテストでは機能以外のさまざまな側面について考慮することも重要です Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 64

29119-4における品質特性とテストタイプの紐付けテストのタイプアクセシビリティテスト互換性テスト品質特性使用性互換性コンバージョンテスト機能適合性ディザスタリカバリテスト
（災害復旧テスト）信頼性機能テスト機能適合性設置性テスト相互運用性テスト移植性互換性機能適合性ローカライゼーションテスト（L10Nテスト）使用性移植性保守性テスト保守性副特性アクセシビリティ共存性機能完全性機能正確性機能適切性成熟性障害許容性(対故障性) 回復性機能完全性機能正確性機能適切性設置性相互運用性機能完全性機能正確性機能適切性適切度認識性習得性運用操作性ユーザエラー防止性ユーザインターフェース快美性アクセシビリティ適用性モジュール性再利用性解析性テストのタイプ品質特性保守性テスト保守性性能関連テスト性能効率性移植性テスト移植性手順テストなし信頼性テスト信頼性セキュリティテストセキュリティ使用性テスト使用性副特性モジュール性再利用性解析性修正性試験性時間効率性資源効率性容量満足性適用性設置性置換性なし成熟性可用性障害許容性(対故障性) 回復性機密性インテグリティ否認防止性責任追跡性真正性適切度認識性習得性運用操作性ユーザエラー防止性ユーザインターフェース快美性アクセシビリティ ISO/IEC/IEEE 29119-4：2021 Table A.1 - 「ISO/IEC 25010 製品品質特性とテストタイプの紐付け」より引用 ※翻訳独自 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 65

製品品質モデルをいきなりテストの文脈で引っ張り出して、テストの十分性や網羅性を示すのは難しい・・・ • テストベースが不足している際に、製品品質モデルの各特性をガイドワードとしテストを考えることは良いが、各特性が「どうあるべきか」は、本来的には品質要求事項を識別し、品質測定量の目標値を定める必要がある • 例えば、「時間効率性」（パフォーマンス）に対する品質要求事項として、品質測定量「平均応答時間」の目標値が何msであれば良いかというテストオラクルが必要 •
すべての品質特性がテストによって測れるわけではなく、テストでは測りがたい特性もある（例：保守性とか移植性とか）し、すべての品質特性で100点を取るというものでもないし、各品質の特性は相乗、相克、相反の関係を持つこともあるため、どの特性をどれくらい優先するかが重要 • 前提として品質モデルはテストのために作られたモデルではなく、製品品質モデルが自分たちのテストにおいて、すべての品質の側面を提供してくれるわけではない（利用時品質、データ品質、ITサービスの品質、AIシステムの品質なども検討する必要があるかもしれない） Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 66

製品品質特性間の関係の例機能適合性機能適合性信頼性性能効率性使用性セキュリティ互換性保守性移植性
－－－－－－－＋信頼性＋＋性能効率性－使用性セキュリティ－互換性＋－－－－－－－－保守性－－移植性－－－－＋記号説明＋：正の効果（行の品質特性が列の品質特性に良い影響を与えることがある。）－：府の効果（行の品質特性が列の品質特性に悪い影響を及ぼし、矛盾が発生することがある。）「JIS X 25030:2021(ISO/IEC 25030:2019) 」P.39 「付属書G 製品品質特性間の関係の例」「表G.1 ― 製品品質特性間の関係の例」デザインを一部変更 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 67

製品品質機能適合性性能効率性互換性機能完全性時間効率性機能正確性資源効率性機能適切性容量満足性
インタラクション容易性 (対話性) 信頼性セキュリティ保守性柔軟性安全性共存性適切度認識性無傷害性機密性モジュール性適用性運用制約性相互運用性習得性可用性 (アベイラビリティ) インテグリティ再利用性拡張性リスク識別性運用操作性障害許容性 (耐故障性）否認防止性解析性インストール性 (設置性) フェールセーフユーザーエラー防止性回復性責任追跡性修正性置換性危険警告性真正性テスト可能性 (試験性) ユーザーエンゲージメント (利用者関与性) インクルーシビティ (包摂性) 統合時安全性対攻撃性ユーザー支援性自己記述性出典: JIS X 25010:2025(ISO/IEC 25010:2023)の情報を元に、独自に作図製品品質のモデルも、時代とともに改訂を重ねており、ISO/IEC25010:2013も 2023年に改訂されました。また、製品品質以外にも、SQuaREでは利用時品質、データ品質、サービス品質、AIシステムの品質モデルなども規定しています。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. その他の品質モデルについては、本資料のAppendixを参照 68

品質はソフトウェアライフサイクル全体を通じて考えましょう出典： SEC journal Vol.10 No.5 Jan. 2015 「システム・ソフトウェア品質標準SQuaREシリーズの歴史と概要」東基衞をベースに一部改変

ライフサイクルでの品質プロセスソフトウェア製品影響プロセス品質ソフトウェア製品の効果影響内部特徴依存影響
外部特徴依存利用時の品質依存利用状況プロセス測定内部測定量外部測定量利用時の品質測定量図「ライフサイクルでの品質」/ JIS X 25010:2013(ISO/IEC 25010:2011) P-31 図C.2より Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 70

テストタイプを突き詰めていくと開発している製品やサービスに求められていること、それらの存在意義といった根源的なことに繋がる Copyright © 2017-2026 Takashi YAMASAKI All right
reserved. 71

テストプロセスとは？ “ 相互に関連する活動のセット。テスト計画作業、テストモニタリングとコントロール、テスト分析、テスト設計、テスト実装、テスト実行、テスト完了といった活動から構成される。 ISTQB Glossary 「テストプロセス」(Ver.2)より引用 Copyright

テストプロセスの例（JSTQB）テスト計画テスト分
析テスト設計テスト実装テスト実行テスト完了テストのモニタリングとコントロール t テストプロジェクトのタイムライン Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 75

ISO/IEC/IEEE 29119-2のテストプロセス群組織的テストプロセステストマネジメントプロセス群テスト戦略と計画プロセステストのモニタリングと
コントロールプロセステスト完了プロセス動的テストプロセステスト設計と実装プロセステスト環境とデータマネジメントプロセステスト実行プロセステストインシデントレポートプロセス ISO/IEC/IEEE 29119-2:2021 P-12 「Figure 2. The multi-layer model showing all test processes」を基に一部表現を変更。翻訳は独自 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 76

ISO/IEC/IEEE 29119とJSTQBのテストプロセス対応関係組織的テストプロセステスト計画プロセステスト設計と実装プロセス
テストのモニタリングとコントロールプロセステスト環境構築とメンテナンスプロセステスト実行プロセステスト完了プロセステストインシデント報告プロセス Copyright © 2017-2026 Takashi YAMASAKI All right reserved. テスト計画テスト分析テスト設計テスト実装テスト実行テスト完了テストのモニタリングとコントロール 77

テストポリシー組織的テストプラクティスプロジェクトテスト計画書テストステータスレポート（例：マスターテスト計画など）レベルテスト計画書タイプテスト計画書（例：システムテスト計画など）（例：
セキュリティテスト計画など）テスト完了レポートテストモデル仕様書テストケース仕様書テストデータ要件テストデータ準備レポートテスト環境要件テスト環境準備レポートテスト手順仕様書実際の結果とテスト結果テスト実行ログテストインシデントレポート出典： ISO/IEC/IEEE 29119-3:2021 P. ix 「Figure 1 Overview of test documentation」。一部要約・改変。翻訳は独自。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 78

テストプロセスを通じてツールの活用も検討一連のテストプロセスではさまざまな活動があり、効率や効果の観点か
らツールの活用を検討しましょう左の文書はさまざまなツールの情報をまとめたガイドでありPDF版も公開されています特に、現在のプロセスの習熟度に沿った導入をアドバイスしてくれる診断ツールは面白いので是非試してみてくださいテストプロセスの成熟度が低い場合はツールを使っても効果が得られにくいのでまだ利用する段階ではないと言われますテストツールまるわかりガイド ASTERテストツールWG著 2020年にVersion 2.0.0が公開されました。「プロプライエタリのテストツールの追加情報やオープンソースのテストツールの情報については、今後は随時、記事投稿を募集し、継続的に改訂していく予定です」（ASTERのWebサイトよ Copyright © 2017-2026 Takashi YAMASAKI All right reserved. り） ※左の画像はVersion 1.0.1です 79

その他にもさまざまなテストプロセスモデルが存在しているのでうまく活用しましょう！ Critical Testing Process (CTP) Systematic Test and Evaluation
Process(STEP) 但し、本質的にはコンテキストに沿ったテストのプロセス設計やテーラリングが必要です Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 80

テストプロセスのためのプロセス改善モデルもいろいろあります TMMi Release 1.3 TPI NEXT ISO/IEC 33063 2022年 2009年
2015年8月 (version. 1.0は2008年) (日本語版が2015年9月に発売) (※現在改訂中 ISO/IEC CD 33063) Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 81

各テストプロセス改善モデルの簡易比較項目 TMMi TPI NEXT ISO/IEC 33063 CMMIと同等の枠組み。CMMIのテストプロセス部分を補完する。CMMIにつ
いて既に経験や知識を持っている組織であれば展開は比較的容易であろう改善提案やコツなどまで含めたガイドとして利用可能。内容が具体的かつ実践的で、現場でのセルフアセスメントなどにも使いやすいものになっていると感じる縦軸に ISO/IEC 33020 、横軸に ISO/IEC/IEEE 29119-2を持つ新しいテストアセスメントモデル。GP、GR、 GWPなどの評価指標が示されているリリース年 2022年(Ver. 1.0は2008年) 2015年8月(原書は2009年) 2015年9月（現在改訂中）リリース元 TMMi Foundation (非営利団体) Sogeti社 (オランダの企業) ISO/IEC (国際規格) モデルの種別段階モデル混合モデル(連続モデルより)※1 連続モデル評価軸成熟度レベル成熟度レベル能力レベル評価の水準数 5段階 4段階 6段階測定対象プロセス領域キーエリアプロセス対象数 15 16 8 (＋5＋α)※2 指標固有/共通のプラクティスチェックポイント評価指標(共通プラクティス /リソース/作業生産物など) 言語英語のみ英語/独語/日本語英語のみ※5 (主観的な)特徴 (CMMI)と相似的・補完的実践的・具体的(これだけで完結) (関連規格と)依存的・汎用的 (主観的な)手軽さ重め軽め重めスコープすべてのテストレベルを対象主に高位テストレベルを対象すべてのテストプロセスを対象動的/静的動的テストだけではなく静的テストも対象 TPIのキーエリアにあった静的テスト技法と評価が削除された(謎) (オプショナルとして) 静的テストを含む所感 ※1: TPI NEXTの書籍P-222によれば「混合だが、どちらかとるが、実践のために5プロセスが追加で示されている。こ ※4: ISO/IEC 33063をJSA Web Storeで購入した場合の金額。言えば連続表現」との記述ありれらはAnnexなどにnormativeとして記述されている関連規格を含めると総額は10万円程となる ※2: プロセスリファレンスモデルである ISO/IEC/IEEE ※3: ISO/IEC 33063のみでのページ数。関連規格を含めると ※5: (2023年10月時点では)JIS化されていない 29119-2で定義されているプロセスは8プロセスのみであ 200ページを超える(Annexを含む) Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 82

テストプロセスの中でも特に押さえておきたいのがテストケースを作るまでのイメージを持てること！未成熟なテスト開発プロセス JSTQBのテスト開発プロセス Test.SSFのテスト開発
プロセステスト設計※またはテスト準備、テスト計画など表現はさまざまテスト分析テスト要求分析テスト設計テストアーキテクチャー設計テスト詳細設計テスト実行テスト実装テスト実行テスト実装テスト実行この部分がテスト開発プロセステストを作り込んでいく段階をより詳細化してイメージできるようになればより良いテストが作れるようになる Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 83

良くあるパターンテスト技法を勉強し
て演習では上手く使えたのに実務ではどうやって技法を適用すれば良いのか分からず https://www.pakutaso.com/20141152308post-4790.html Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 上手く使えていません(T_T) 84

テストベースに対していきなり ※ テスト技法を適用している？ Test TestTechnics Design Technic Test Basis
Test Basis Test Cases Test Cases Test Cases ※テストベースとはテストを考える上で入力となる情報全般のこと。例えば要件定義書、仕様書、外部設計書などさまざま Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 85

それは失敗フラグです Test TestTechnics Design Technic Test Basis Test Basis Copyright
© 2017-2026 Takashi YAMASAKI All right reserved. Test Cases Test Cases Test Cases 86

JSTQBのテスト開発プロセスのイメージ例文書 A 文書 B 文書 C 文書 D テストベース
テスト分析テスト設計仕様テスト設計仕様テスト設計仕様テスト設計テストケース仕様テスト実装テスト手順仕様テストケース仕様テスト手順仕様テストケース仕様テスト手順仕様テスト手順仕様テストケース仕様テスト手順仕様テスト条件テストケーステスト手順「テスト技術者資格制度Foundation Levelシラバス日本語版」を基に図にしたもの Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 87

ISO/IEC/IEEE 29119-2:2013におけるテスト開発プロセス（これは、基本的に、JSTQBのテスト開発プロセスと同じ）テスト設計仕様フィーチャーフィーチャーセットセットを識別する
(TD1) テスト条件を得る (TD2) テスト条件テストカバレッジアイテムを得る(TD3) テストケース仕様テストカバレッジアイテムテストケースをテストケース得る (TD4) テスト手順仕様テストセットをテストセットまとめる (TD5) ISO/IEC/IEEE 29119-2：2013 P.32 Figure 10 Test design and implementation process より一部抜粋。翻訳は筆者による Copyright © 2017-2026 Takashi YAMASAKI All right reserved. テスト手順を得る (TD6) テスト手順& テストスクリプト 88

ISO/IEC/IEEE 29119:2023でのテスト開発プロセスイメージテストモデルの作成 (TD1) テストモデルテストカバレッジアイテムの識別 (TD2) テストカバレッジアイテム
テストケースの導出 (TD3) テストケーステスト手順の作成 (TD4) テスト手順 ISO/IEC/IEEE 29119-2：2021 P.32 Figure 10 Test design and implementation process より引用。翻訳は筆者による Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 89

テスト設計コンテストのすゝめ画像はNPO法人ASTERのテスト設計コンテストのWebサイトより引用特にこの分野は日本がリードしており現在進行形で切磋琢磨している状態。成果物も一部公開されており、具体的に見たい、知りたい人にも最適！ OpenクラスとU-30クラスがあるので、若い人の腕試しもできます。また、チュートリアル資料と動画も公開されていますので勉強になります。 Copyright © 2017-2026 Takashi

実際に自分たちがテスト開発できるだけの詳細度でプロセスを設計しましょうテストベーステストすべきことを洗い出すさまざまなテスト観点ドメイン知識/ ガイドなど
テスト観点を構造化するテスト技法テストケース (テスト値) 基準に基づいてケースを導出する構造化されたテスト観点 (中間状態) 網羅基準網羅基準に紐付いたテストパラメータ網羅基準を設定する Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 詳細化されたテスト観点 (テストパラメータ) テスト観点間の関係性を見出すテストフレームリファインする最終的に構造化されたテスト観点同じような意味を持つテスト観点やテストフレームをまとめる 4つのテストモデルテストモデルを特定するテストコンテナ間の関連性を整理するテスト観点を詳細化するモデルに紐付いたテスト観点テストアーキテクチャーテストコンテナ 91

ソフトウェアライフサイクルの中で継続的に行っていく各テストの特徴を見据えたプロセスを設計する Copyright © 2017-2026 Takashi YAMASAKI All right reserved.
92

テストプロセスを突き詰めて考えていくとテストを実現するためのプロセスだけではなくソフトウェア開発ライフサイクルやソフトウェアライフサイクルとの融
合やパイプライン化に繋がる Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 93

テスト技法(テスト設計技法)やテストプラクティステストレベルテストタイプユニットテスト統合テストシステムテストシステム統合テスト受け入れテスト • ユーザー受け入れテスト
• 運用受け入れテスト • 工場受け入れテスト • アルファテスト • ベータテスト • 製品検証テストテストプラクティスモデルベースドテストスクリプトテスト探索的テスト経験ベースドテスト手動テスト A/Bテストバックツーバックテスト数学ベースドテストファズテスト（ファジング）キーワード駆動テスト自動テスト • キャプチャープレイバック駆動 • データ駆動機能テストアクセシビリティテスト互換性テストコンパ―ジョンテスト災害復旧テストインストール性テスト相互運用性テストローカライゼーションテスト保守性テスト性能関連のテスト • 性能テスト • 負荷テスト • ストレステスト • キャパシティテスト • 回復テストポータビリティテストプロシージャ―テスト信頼性テストセキュリティテスト使用性（ユーザビリティ）テスト静的テストレビュー（ISO/IEC 20246) 静的解析モデル検証テスト設計技法/測定仕様ベース： • 同値分割法 • クラシフィケーションツリー法 • 境界値分析 • シンタックステスト • 組み合わせテスト • 全組み合わせ • ペアワイズ • イーチチョイス • ベースチョイス • デシジョンテーブルテスト • 原因結果グラフ法 • 状態遷移テスト • シナリオテスト • ユースケーステスト • メタモルフィックテスト • 要件ベースドテスト構造ベース： • ステートメントテスト • ブランチテスト • デシジョンテスト • ブランチ条件テスト • ブランチ条件組み合わせテスト • MC/DCテスト • データフローテスト ※ 経験ベース： • エラー推測 ※All-deffinitions/All-C-uses/All-P-uses/All-uses/All-DU-pathテスト ISO/IEC/IEEE 29119-1:2022 「図2 テストアプローチ選択の例」より。翻訳と配色は独自。一部改変 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 95

テスト技法とは？ “ テスト条件の定義、テストケースの設計、およびテストデータの明確化をするための手続き。 ISTQB Glossary https://glossary.istqb.org より引用 Copyright

昔ながらのテスト技法の分類入力出力入力出力ブラックボックステスト技法ホワイトボックステスト技法テスト対象の(内部)構造には着目せテスト対象の(内部)構造に着目して、ずにテストケースを導出するテスト技
テストケースを導出するテスト技法の法の総称総称 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 97

JSTQBによるテスト技法の分類ブラックボックステスト技法別名: 仕様ベースの技法「テスト対象の内部構造を参照することなく、仕様上の振る舞いの分析に基づくもの」《補完す
る》ホワイトボックステスト技法別名: 構造ベースの技法「テスト対象の内部構造や処理の分析に基づくもの」経験ベースのテスト技法別名: 特になし「テストケースの設計と実装にテスト担当者の知識と経験を効果的に利用するもの」同値分割法境界値分析デシジョンテーブルテスト状態遷移テストその他ステートメントテストブランチテストその他エラー推測探索的テストチェックリストベースドテストその他ブラックボックステスト技法については、概要を本資料のAppendixで説明しているので、そちらを参照してください。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 98

ISO/IEC/IEEE 29119によるテスト技法の分類 ISO/IEC/IEEE 29119で紹介するテスト技法仕様に基づいた技法構造に基づいた技法同値分割法ステートメントテストクラシフィケーションツリー法
ブランチテスト境界値分析デシジョンテスト構文テストブランチコンディションテスト組み合せテスト技法ブランチコンデション組み合わせテスト全組み合わせテスト改良条件判定カバレッジテストペアワイズテストデータフローテスト Each choiceテスト All-definitions testing Base choiceテスト All-c-uses testing デシジョンテーブルテスト All-p-uses testing 原因結果グラフ All-uses testing 状態遷移テスト All-du-paths testing シナリオテストエラー推測技法の分類は、名称こそ異なるものの、基本的にJSTQB FLとメタモルフィックテスト要件ベースドテスト経験に基づいた技法 29119-4とでは同じ分類となっている。 ISO/IEC/IEEE 29119-4:2021 Figure 2. The set of test design techniques presented in this document より引用。翻訳は独自 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 99

探索的テストはテスト技法なの？スクリプトテスト探索的テストテストを実施するにあたってテストケース（スクリ対象を触ってその反応を観察し、知識・経験・直感プト）を事前に作成し、テストケースに記載されて VS いる手順通りに実行するテストの方法で、探索的テを駆使して次のアクションを決めるテストの方法で、テストの設計・実行・学習を同時に行い、フィード
ストの対義語的に使われることも多いです。どこまバックサイクルを繰り返すのが特徴です。どこまでで詳細にスクリプト化するかに幅があります探索をテスト実行者にゆだねるかに幅があります。純然たるスクリプト漠然としたスクリプト断片的なテストケースフリースタイルの探索チャーター役割上図はCem Kaner & James Bach著「The Nature of Exploratory Testing」P.14 より引用。翻訳は筆者による ISTQBの文脈においてはテスト技法ですが、テスト技法ではなくテストの実施方法やスタイルと言われることもあります。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 100

なぜちゃんとテスト設計しなければならないのか？ Copyright © 2017-2026 Takashi YAMASAKI All right reserved.
101

テスト技法を最初に学ぶにはこちらをオススメソフトウェアテスト技法ドリル第2版秋山浩一著/日科技連出版刊はじめて学ぶソフトウェアのテスト技法リー・コープランド著/日経BP刊代表的なブラックボックステストの技法を取り扱った書ブラックボックステストとホワイトボックステストのさ籍。非常に分かりやすい文章でお勧め。特にさまざまなまざまなテスト技法を掲載。いろいろなテスト技法を
技法を次元という観点でまとめているところが秀逸。知るとっかかりとしてお勧め。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 103

将来的にはこれらの書籍も学んでみましょうソフトウェアテスト技法実践的プログラムテスト入門ボーリス・バイザー著/日経BP刊ボーリス・バイザー著/日経BP刊バイザーによるテスト技法を詳細に説明した書バイザーのブラックボックステスト本。右の書籍からブ籍。ホワイトボックステストのテスト技法をしっラックボックステストに特化した書籍。いかんせん、かり学びたいならこれしかない！ブラックボッ
ちょっと右の書籍は読むのがハードな部分もあるのクステストについても書かれている。で、それよりはハードルが少し低いかも？ Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 104

その際にはSQuBOKガイドなどもオススメします全体の軸を持った上でSQuBOK ガイドなどを効率よく知識を吸収していけます品質やテストに関する用語で分からないものがあればまずはこれにあたり詳細についてはガイドが示す参考資料をあたるのをオススメします Copyright

Guide to the Software Quality Body of Knowledge (V3) 1.
ソフトウェア品質の基本概念 1.1 品質の概念 1.1.1 品質の定義（品質の考え方の変遷） 1.1.2 ソフトウェア品質モデル 1.2 品質マネジメントの概念 1.2.1 品質保証の考え方 1.2.2 改善の考え方 1.3 ソフトウェアの品質マネジメントの特徴 1.3.1 プロダクト品質とプロセス品質 1.3.2 品質の作り込み技術の考え方 1.3.3 システムおよびソフトウェアの測定と評価の考え方 1.3.4 V&V（Verification & Validation） 2. ソフトウェア品質マネジメント組織レベルのソフトウェア品質マネジメント 2.1 ソフトウェア品質マネジメントシステムの構築と運用 3. ソフトウェア品質技術 3.1.1 測定理論 2.1.2 セキュリティのマネジメント 3.1.2 プロダクトメトリクス 2.2.1 ライフサイクルモデル 3.2.1 制御系のモデル化技法 2.3 ソフトウェアプロセス評価と改善 3.2.2 連続的のモデル化技法 2.3.2 ソフトウェアプロセス改善技術 3.3.1 形式仕様記述の技法 2.5 監査のマネジメント 3.3.2 形式検証の技法 2.6 教育および育成のマネジメント 2.6.1 スキル標準 2.6.2 開発現場における教育および育成のマネジメント 2.7 法的権利および法的責任のマネジメントプロジェクトレベル（共有）のソフトウェア品質マネジメント 2.8 意思決定のマネジメント 2.9 調達のマネジメント 2.9.1請負契約による外部委託 2.10 リスクマネジメント 4.2.3 セーフティ･クリティカル･ライフサイクルモデル 4.3.1 セキュリティの品質の概念 4.3.2 セキュリティの技法 4.4 プライバシー 4.4.1 プライバシーの品質の概念工程に個別なソフトウェア品質技術 4.4.2 プライバシーの技法 5.5.3 オープンソフトウェア利用の品質技術 3.7.2 仕様やコードに基づいた技法 3.7.3 フォールトに基づいた技法 3.7.4 リーディング技法 3.8 テストの技法 3.8.1 テスト設計技法 3.8.2 テスト自動化技法 3.9 品質分析および評価の技法 2.12.1 PMBOK（プロジェクトマネジメント知識体系） 3.9.1 信頼性予測に関する技法 2.12.2 プロジェクトマネジメントに関する規格 3.9.2 品質進捗管理に関する技法 2.13 品質計画のマネジメント 2.14 要求分析のマネジメント 5.3.3 アジャイル開発とDevOpsの品質技術 5.4 クラウドサービスにおける品質 3.5.2 詳細設計の技法 3.7.1 レビュー方法プロジェクトレベル（個別）のソフトウェア品質マネジメント 5.3.2 アジャイル開発とDevOpsの品質マネジメント 5.5.2 オープンソフトウェア利用の品質マネジメント 3.5.1 方式設計の技法 2.10.4 リスク評価および対応 2.12 プロジェクトマネジメント 5.3.1 アジャイル開発とDevOpsにおける品質の概念 5.5.1 オープンソフトウェア利用における品質の概念 3.4.4 要求の妥当性確認と評価 3.5 設計の技法 3.7 レビューの技法 2.10.4 トレーサビリティ管理 5.2.3 IoTシスステムの品質技術 5.3 アジャイル開発とDevOpsにおける品質 5.5 オープンソフトウェア利用における品質 3.4.3 要求仕様化 2.10.3 リスク分析および算定 2.11.3 不具合管理 5.2.2 IoTシスステムの品質マネジメント 5.4.3 クラウドサービスの品質技術 3.4.2 要求分析 3.6 実装の技法 2.11.2 バージョン管理 5.2.1 IoTシスステムにおける品質の概念 5.4.2 クラウドサービスの品質マネジメント 3.4.1 要求抽出 2.10.2 リスク識別及び特定 2.11.1 変更管理 5.1.3 人工知能システムの品質技術 5.2 IoTシスステムにおける品質 5.4.1 クラウドサービスにおける品質の概念 3.4 要求分析の技法 2.10.1 リスクマネジメントプロセス 2.11 構成管理 5.1.2 人工知能システムの品質マネジメント 4.3 セキュリティ 3.3 形式手法 2.4 検査のマネジメント 5.1.1 人工知能システムにおける品質の概念 4.2.2 セーフティの技法 3.3.3 ドメイン特化言語 5.1 人工知能システムにおける品質 4.1.2 ユーザビリティの技法 4.2.1 セーフティの品質の概念 3.2 モデル化の技法 5. ソフトウェア品質の応用領域 4.1.1 ユーザビリティの品質の概念 4.2 セーフティ 3.1.3 プロセスメトリクス 2.2.2 プロセスモデル 2.3.1 ソフトウェアプロセス評価モデル 4.1 ユーザビリティ 3.1 メトリクス 2.1.1 品質マネジメントシステム 2.2 ライフサイクルプロセスのマネジメント 4. 専門的なソフトウェア品質の概念と技術工程に共通なソフトウェア品質技術 3.9.3 障害分析に関する技法 3.9.4 データ解析と表現に関する技法 3.10 運用および保守の技法 2.15 設計のマネジメント 3.10.1 運用の技法 2.16 実装のマネジメント 3.10.2 保守の種類と技法 2.17 レビューのマネジメント 2.18 テストのマネジメント 2.18.1 テストプロセス 2.18.2 テストの構造 2.18.3 テストの計画と遂行 2.18.4 テストに関する標準 2.19 品質分析および評価のマネジメント 2.19.1 プロダクト品質とプロセス品質の分析および評価 2.20 リリース判定基準 2.21 運用および保守のマネジメント 2.21.1 ITIL 2.21.2 SLA（サービスレベルアグリーメント）とSLM（サービスレベルマネジメント）ソフトウェア品質知識体系ガイド（第3版） ―SQuBOK Guide V3― 図1 「樹形図概観（カテゴリ層から副知識領域層までの上位4層）」より 2.21.3 サービスマネジメントに関する規格（ISO/IEC 2000シリーズ） 2.21.4 保守に関する規格（ISO/IEC 14764） Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 110

「テストとは？」を整理すると「品質に関わる新たな情報を得るための諸活動」 ※以下のテストの目的をすべて満たします欠陥を摘出する意志決定のための情報を示す対象ソフトウェアの品質レベルが十分であることを確認する欠陥の作りこみを防ぐ
上記4つのテストの目的は、テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 111

JSTQBによるテストタイプの分類機能テスト非機能テストコンポーネント、およびシステムが実行する機能をコンポーネント、およびシステムが実行する機能特評価する。機能とはテスト対象が「何」をすべきか性以外の属性を評価する。非機能テストは、システである。機能テストの主な目的は、機能完全性、機ムが「どのようにうまく振る舞うか」をテストする。能正確性、および機能適切性をチェックすること
非機能テストの主な目的は、非機能的なソフトである。ウェア品質特性をチェックすることである. ブラックボックステストホワイトボックステスト仕様に基づき、テスト対象の外観を示すドキュメン構造に基づき、システムの実装または内部構造トからテストを導出する。ブラックボックステスト（コード、アーキテクチャー、ワークフロー、データの主な目的は、システムの動作をその仕様に照らフローなど）からテストを導き出す（4.3 節参照）。してチェックすることである。ホワイトボックステストの主な目的は、テストによって基本的な構造を受け入れ可能なレベルまでカバーすることである。テスト技術者資格制度 Foundation Levelシラバス日本語版Ver.4.0J02「2.2.2 テストタイプ」より文章を引用（強調と作図は独自）。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 115

テスターのスキルスペース TEST SKILLS SOFT SKILLS IT SKILLS DOMAIN KNOWLEDGE Fig.
“Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf) Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 122

テスト以外の知識も必要です TEST SKILLS SOFT SKILLS IT SKILLS DOMAIN KNOWLEDGE Fig.
“Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf) Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 123

主な参考文献・参考資料 JSTQB/ISTQB関連 • • • • ISTQB Glossary （用語集）テスト技術者資格制度Foundation
Level シラバス Version 2023V4.0.J02 テスト技術者資格制度Advanced Levelシラバス日本語版テストマネージャ JSTQB認定ソフトウェアテスト技術者Foundation Levelトレーニングコース資料（山﨑崇） ISO/IEC/IEEE 29119シリーズ • • • • • • ISO/IEC/IEEE 29119-2:2021 Software testing – Part 2: Test processes ISO/IEC/IEEE 29119-3:2021 Software testing – Part 3: Test documentation ISO/IEC/IEEE 29119-4:2021 Software testing – Part 4: Test techniques ISO/IEC/IEEE 29119 勉強会第1回規格の全体構成と各規格の概要 (山﨑崇) ISO/IEC/IEEE 29119 勉強会第2回 Part 2 Test Processes (山﨑崇) ISO/IEC/IEEE 29119 勉強会第3回 Part3 テストドキュメント (山﨑崇）テストプロセス改善 • テストプロセス改善モデルの最新動向（山﨑崇）その他 • • JaSST‘15 Tokyo 初心者チュートリアル（山﨑崇） JaSST’10 Tokyo 初心者セッション（片山徹郎長谷川聡）主な写真素材フリー写真素材ぱくたそ・無料ダウンロード http://images.freeimages.com/static/images/logo.png 本講を切っ掛けにソフトウェアテストの頂への第一歩を踏み出してください！！ Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 124

改訂履歴 Ver. 作成・更新日備考 1.00 2017/12/13 SQiP研究会品質保証基礎コーステスト技術の研修向けに新規作成 1.10
2017/12/15 微修正（不要部分の削除、見栄えの修正など） 2.00 2019/12/13 2019年度の研修向けへの更新 3.00 2020/12/11 2020年度の研修向けへの更新 4.00 2021/12/10 2021年度の研修向けへの更新 5.00 2022/12/09 2022年度の研修向けへの更新 6.00 2023/10/13 2023年度の研修向けへの更新 7.00 2024/10/18 2024年度の研修向けへの更新 8.00 2025/10/17 2025年度の研修向けへの更新 9.00 2026/10/16 2026年度の研修向けへの更新 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 125

同値分割法同じ結果が得られるグループ（同値パーティション）に分割し、その中から代表値をテストケースとして選定することで、少ないテストケースで効率的なテストが可能（数学の集合論で考えると分かりやすいかもしれない） A 代表値𝒂𝒊 テストしたい全要素が3つの同値パーティションとして分割できる（全集合𝑈 = 𝐴
+ 𝐵 + 𝐶）場合、 1. 𝐴 = 𝑎1 , 𝑎2 , 𝑎3 , ⋯ , 𝑎𝑥 から代表値𝑎𝑖 を選定し、 𝑎𝑖 をテストすることで、同値パーティション𝐴 が含む同値であるすべての要素(𝑎1 ⋯ 𝑎𝑥 )をテス代表値𝒃𝒋 B トしたこととみなす 2. C 𝐵 = 𝑏1 , 𝑏2 , 𝑏3 , ⋯ , 𝑏𝑦 から代表値𝑏𝑗 を選定し、以下同文代表値𝒄𝒌 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 3. 𝐶 = 𝑐1 , 𝑐2 , 𝑐3 , ⋯ , 𝑐𝑧 から代表値𝑐𝑘 を選定し、以下同文 128

同値分割法のカバレッジ 29119-4ではこの技法のカバレッジを以下のように示している。 N 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = × 𝟏𝟎𝟎 % T 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆:
同値パーティションカバレッジ N: 実行したテストケースによってカバーされるパーティション数 T: 識別されたパーティションの総数 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 129

同値分割法の特徴着目する点 • 等価とみなせる値のグループ(同値パーティション)に着目 • 同値パーティションから代表値 1つを選ぶことで、そのグループの値すべてをテストしたことと等価とみなすポイント •
同値パーティションを考える時は、有効な値だけでなく、無効な値のパーティションも考慮する • 各同値パーティションから漏れなく代表値を選ぶ • 無効同値は単独でテストする(隠蔽の可能性に注意) メリット • より少ないテストケース数で対象範囲を網羅できる • 同値パーティション（同値クラスとも呼ぶ）キーワード • 有効パーティション • 無効パーティション Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 130

境界値分析 • 同値分割法の要素に順序性がある場合（数値/時間/回数など）、代表値を任意に選ぶのではなく、同値パーティションの境界に着目して境界の値を代表値（境界値）として選ぶ • 分割した同値パーティションの境界付近に欠陥が潜んでいる可能性が高い • 境界値とは、分割した同値パーティションの端、あるいは端のどち
らか側で最小の増加的距離にある値 • 境界値分析も、すべてのテストレベルで適用できる Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 131

境界値分析の例以下の、パスワードの長さに関する仕様について境界値分析をすると、 • パスワードの長さは、8文字以上24文字以内の範囲とする • 24文字を越える場合、文字の入力を受け付けないパスワードとしては短い無効同値パーティション 0
パスワードとして適切な長さの有効同値パーティション 7 8 パスワードとしては長すぎる無効同値パーティション 24 25 ※25 文字目は存在しないが、入力を無効化する機能をテストするための論理的な値として25文字を上限とする。 ※文字数が負の数はありえないので0を下限とする有効な境界値 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 無効な境界値 132

境界値分析の特徴着目する点 • 同値パーティションの要素に順序性がある場合、その境界付近に着目 • 境界付近に欠陥が埋め込まれるやすいという経験則に基づいている（例: ＞を≧の誤りなど）ポイント
• 上限や下限が定まっていないなど、範囲が開いている場合は、確認の上、決める必要が出てくる（十分に小さい値、十分に大きい値をすり合わせる） • メリット少ないテストケースで、よりバグが潜んでいそうな箇所を狙い打てる（同値分割法よりケース数が増えるが、同値分割法だけでは見つからない欠陥を見つけられる可能性が高まる）キーワード • 最小の増加的距離 • 境界値（本講では扱わないが2値BVAと3値BVAの二流派ある） Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 134

デシジョンテーブルテスト • デシジョンテーブルテストは、デシジョンテーブルを基にテストを導出するテスト技法 • デシジョンテーブルとは、論理（ロジック）条件の組み合わせを包括的にテーブルとて記述したもの 1 2 3
4 タイムサービス時間内である Y Y Y N 対象商品である Y N N - 会員である - Y N - 15％割引する X - - - 5％割引する - X - - 割引なし - - X X Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 135

デシジョンテーブルテストのカバレッジ 29119-4ではこの技法のカバレッジを以下のように示している。 N 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = × 𝟏𝟎𝟎 % T 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆:
デシジョンテーブルテストカバレッジ N: 実行したテストケースによってカバーされる、実行可能な判定規則の数 T: 実行可能な判定規則の総数 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 136

デシジョンテーブルテストの特徴着目する点 • 論理関係に着目(条件の組み合わせによって動作が確定するようなロジックを持つもの) • IF文のような判定文をはじめ、論理関係があるものはすべてデシジョンテーブルとして表現できるポイントメリット
• テーブルを簡単化する場合は、グレーボックステストとしてのアプローチを取り、条件判定の処理順序が確定していることを確認しておかないと、テストの抜け漏れのリスクがある • 複数の条件によって動作が異なるようなロジックを漏れなく整理することができる • デシジョンテーブル（決定表）、制限指定、拡張指定キーワード • 制限記入テーブル/拡張記入テーブル/混合記入テーブル • 条件部/動作部/記述部/指定部、規則 • テーブルの簡単化（圧縮） Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 137

状態遷移テスト • 状態遷移モデルを基にテストを導出するテスト技法 • 状態遷移モデルは、ソフトウェアの状態と、その遷移に着目したモデル • 状態遷移モデルには、状態遷移図と状態遷移表がある • UML
（ Unified Modeling Language ）のステートマシン図も状態遷移モデルの1つ Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 138

状態遷移図の例ライセンス購入 /有効日数+=365日ライセンス確認 [有効日数>=0] /有効日数-=1 ライセンス確認 [有効日数>=0] /有効日数-=1 未登録
新規登録 /有効日数=30日ライセンス購入 /有効日数＋=365日試用中ライセンス確認 [有効日数<0] ライセンス確認 [有効日数<0] 遷移凡例疑似開始状態終了状態状態契約中ライセンス購入 /有効日数+=365日期限切れイベント[ガード条件]/アクション注1: ガード条件がない場合は、[]とともに省略する。注2: アクションしないか示す必要がない場合は/とともに省略する ※ ミリーチャート、ムーアチャート、ハレルチャート、UMLのステートマシン図など、状態遷移図の表現はさまざま存在している。本資料ではミリーチャートをベースに独自にカスタマイズした記法を用いている。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 139

状態遷移表の例ライセンス確認イベント新規作成ライセンス購入遷移前状態 [有効日数<0] [有効日数>=0] N/A N/A
有効期間＝ 30日未登録試用中 N/A 有効日数＋＝ 365 ― 有効日数－＝ 1 試用中 N/A 契約期間中有効日数＋＝ 365 期限切れ ― 試用中有効日数－＝ 1 契約期間中 N/A 契約期間中期限切れ契約期間中 N/A N/A 有効日数＝ 365 期限切れ N/A 契約期間中 ※ アクションを省略しているものや、状態×状態で表したものなど、状態遷移表の表現もさまざま存在している。 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 140

状態遷移テストの特徴着目する点 • テスト対象の状態や、遷移、イベントに着目 • 故障が発生するのは遷移したタイミングとは限らない（例：ある遷移で内部変数を壊しても、故障として現れるのは、壊した内部変数を参照した時になる）ポイント •
特定の経路や状態をテストするのか、すべての状態を網羅するのか、遷移を網羅するのか、nスイッチカバレッジを網羅するのかを決定するメリットキーワード • 状態遷移モデルにすることで、取り得る経路を整理でき、nスイッチカバレッジなども網羅基準を基に、テストケースを導出できる • 状態、遷移、イベント、ガード条件、アクション • 状態遷移表、状態遷移図、ステートマシン図 • nスイッチ Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 141

状態遷移テストのカバレッジ 29119-4ではこの技法のカバレッジとして次の4つを示している。 1. 全状態カバレッジ (all states coverage) 2. 0スイッチカバレッジ (0-switch
coverage) 3. 全遷移カバレッジ (all transitions coverage) 4. Nスイッチカバレッジ (N-switch coverage) Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 142

製品品質（2001年版）外部及び内部品質機能性信頼性使用性効率性保守性移植性合目的性成熟性
理解性時間効率性解析性環境適応性正確性障害許容性習得性資源効率性変更性設置性相互運用性回復性運用性安定性共存性魅力性試験性置換性保守性標準適合性移植性標準適合性セキュリティ機能性標準適合性信頼性標準適合性使用性標準適合性効率性標準適合性 Figure. “外部及び内部品質のための品質モデル” from JIS X 0129-1:2003 ソフトウェア製品の品質 –第1部:品質モデル P-9 図4より Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 144

製品品質モデル(2011年版) システム/ソフトウェア製品品質機能適合性性能効率性互換性 • 機能完全性 • 機能正確性 •
機能適切性 • 時間効率性 • 資源効率性 • 容量満足性 • 共存性 • 相互運用性使用性信頼性セキュリティ適切度認識性習得性運用操作性ユーザエラー防止性 • ユーザインターフェース快美性 • アクセシビリティ • 成熟性 • 可用性 • 障害許容性 (対故障性) • 回復性 • 機密性 • インテグリティ • 否認防止性 • 責任追跡性 • 真正性 • • • • 保守性 • • • • • モジュール性再利用性解析性修正性試験性移植性 • 適用性 • 設置性 • 置換性 JIS X 25010:2013 図4「製品品質モデル」より引用 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 145

製品品質モデル(2023年版) 製品品質機能適合性性能効率性互換性機能完全性時間効率性機能正確性資源効率性機能適切性
容量満足性インタラクション容易性 (対話性) 信頼性セキュリティ保守性柔軟性安全性共存性適切度認識性無傷害性機密性モジュール性適用性運用制約性相互運用性習得性可用性 (アベイラビリティ) インテグリティ再利用性拡張性リスク識別性運用操作性障害許容性 (耐故障性）否認防止性解析性インストール性 (設置性) フェールセーフユーザーエラー防止性回復性責任追跡性修正性置換性危険警告性真正性テスト可能性 (試験性) ユーザーエンゲージメント (利用者関与性) インクルーシビティ (包摂性) 統合時安全性対攻撃性ユーザー支援性自己記述性出典: JIS X 25010:2025(ISO/IEC 25010:2023)の情報を元に、独自に作図 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 146

利用時の品質(2011年版) 利用時の品質有効性 • 有効性効率性満足性 • 効率性リスク回避性
利用状況網羅性 • 実用性 • 経済リスク緩和性 • 利用状況完全性 • 信用性 • 健康・安全リスク • 柔軟性 • 快感性 • 快適性緩和性 • 環境リスク緩和性 “利用時の品質特モデル “ from “JIS X 25010:2013” 図4 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 148

利用時品質(2023年版) 利用時品質便益性リスク回避性受容性 ‐ユーザビリティ ‐経済リスク回避性 ‐ 経験保有性 ‐アクセシビリティ
‐環境及び社会リスク回避性 ‐ トラストワージネス ‐適合性 ‐健康リスク回避性 ‐ 遵守性 ‐人間生命及び生活リスク回避性出典: JIS X 25019:2025(ISO/IEC 25019:2023) 図2 利用時品質モデルより引用 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 149

ITサービス品質モデル ITサービス品質適合性使用性 ITサービス信頼性セキュリティ触知可能性即応性 ITサービス
適応性 ITサービス保守性 • 完全性 • 適切度認識性 • 機密性 • 継続性 • 視認性 • 適時性 • カスタマイズ性 • 解析性 • 正確性 • 習得性 • インテグリティ • ITサービス回復性 • プロ意識 • 反応性 • 自発性 • 修正性 • 適切性 • 運用操作性 • 追跡可能性 • 可用性 • ITサービス • 一貫性 • ユーザエラー防止性 • 試験性インターフェース快美性 • アクセシビリティ • 丁寧さ出典: 「ISO/IEC TS 25011:2017 Figure 4 – IT service quality model」を基に作図。翻訳は独自。ただし、同様の用語はJIS X25010とJIS X25012の訳語を採用している。マークアップ部分は、対応する用語がないため、完全に独自の訳語を用いているが、怪しさ満点 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 151

AIシステムの製品品質モデル AIシステム製品品質機能適合性性能効率性互換性使用性信頼性セキュリティ保守性移植性
機能完全性時間効率性共存性適切度認識性成熟性機密性モジュール性適用性機能正確性m 資源効率性相互運用性可用性インテグリティ再利用性設置性機能適切性容量満足性障害許容性否認防止性解析性置換性責任追跡性修正性真正性試験性週特性運用操作性ユーザエラー機能適応性a (耐故障性) 防止性ユーザインターフェース快美性アクセシビリティ回復性ロバストネスa 介入可能性a ユーザ制御性a 透明性a a：新しい副特性 / m: 変更された副特性 ISO/IEC 25059:2023 P.3「図1: AIシステム製品品質モデル」より。翻訳と着色は独自 Copyright © 2017-2026 Takashi YAMASAKI All right reserved. 152

ソフトウェアテストの概観を識る/Understanding_overview_of_softw...

ソフトウェアテストの概観を識る/Understanding_overview_of_software_testing

More Decks by YAMASAKI Takashi

Other Decks in Technology

Featured

Transcript