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

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

View Slide

株式会社ベリサーブ品質保証部プロジェクト推進課課長兼ソフトウェア品質コンサルティング部
山﨑崇（YAMASAKI Takashi）
2001年からセキュリティ対策ベンダーにおいて、さまざまなプロジェクトの
ソフトウェアテスト活動にQAエンジニアとして従事。その傍ら、さまざまなテ
ストコミュニティに参画し、活動の場を広げる。2015年にベリサーブに入社。
現場への技術支援、教育、コンサルテーションなどを担い、少しでも現場が幸
せになるように日々奮闘中。
主な活動
• JaSST東京実行委員会（’11～）
• テスト設計コンテストU-30審査委員（’16～）
• ASTER テストプロセス改善研究会（’16～）
• JSTQB Foundation Level 認定講師（’12～）
など
主な著書・訳書
• システム開発ジャーナル Vol.10 （共著）
• 実践ソフトウェアエンジニアリング第9版（共訳）
• 開発現場で役立つテスト「超」実践講座第9回（著）
• テスト技術者資格制度Foundation Level Extensionシ
ラバスアジャイルテスト担当者（共訳）
など
主な講演
• JaSST’21北陸基調講演「テストを学び成長する」 🔗
• JaSST’17東北基調講演「テストの極みを目指して」 🔗
• JaSST‘15東京チュートリアル「初心者からの脱出」 🔗
• テスト設計コンテストチュートリアル
U-30クラス（’17～’19）ちびこん編（’21 🔗）
• SQiP研究会品質保証の基礎コース第7回
「ソフトウェアテストの概観を識る」（’17, ’20～） 🔗
• 第14回SPIトワイライトフォーラム
「テストプロセス改善モデルの最新動向」 🔗
など
その他 https://www.linkedin.com/in/yamasaki696/ を参照

View Slide

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

View Slide

一方では様々な情報の中から
自分の求めている情報を的確に
見つけるのが難しいとも言えます

View Slide


View Slide

理解への第一歩は
言葉を知ることから

View Slide

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

View Slide

「分かることは分けられること」
「思考・論理・分析 ―「正しく考え、正しく分かること」の論理と実践―」波頭亮(著)
10

View Slide

分けるためにも概観できるテストの軸が重要
テストレベル
テストプロセス
テストタイプ
テストの空間のどこに対しての
要素であるかを意識した上で
テスト技術などの要素を考える
※図はイメージです
11

View Slide


View Slide

共通言語としてJSTQB FL 取得のススメ

View Slide

本日使う道具はこの三点です

View Slide

テスト分析
テストタイプ
システムテストの
自動化
非機能テスト
ブラックボックス
テスト
こんな感じで、随時
気になったキーワードを
独断と偏見によって貼り付けて
いってください

View Slide


View Slide

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

View Slide


View Slide

Industry References:3 B. Boehm and V. Basili, "Software Defect Reduction Top 10 List" IEEE Computer Society, Vol. 34, No. 1, Jan 2001
リリース後に見つかった欠陥の修正コストは高い

View Slide

適合コスト
欠陥を回避するためにプロジェクト
期間中に支出する金額
不適合コスト
障害によりプロジェクト期間中
および期間後に支出する金額
予防コスト
品質上の欠陥の発生を早い段階で
防止するために支出される欠陥コスト
検出コスト
製品ないし部品の品質を評価する
ことによって品質レベルを維持する
ために支出される評価コスト
内的障害コスト
製品の出荷以前に欠陥や品質不良が
発見された場合の処理に付随して
発生する内部障害コスト
外的障害コスト
製品出荷後に市場で欠陥や品質不良が
発生する外部障害コスト
図：品質コスト / 出典：Rex Black著「ソフトウェアテスト12の必勝プロセス」の品質コストの説明をもとに図にしたもの
品質コスト

View Slide

製品をリリースするまでにかかる品質コスト
適合コスト
欠陥を回避するためにプロジェクト
期間中に支出する金額
不適合コスト
障害によりプロジェクト期間中
および期間後に支出する金額
予防コスト
品質上の欠陥の発生を早い段階で
防止するために支出される欠陥コスト
検出コスト
製品ないし部品の品質を評価する
ことによって品質レベルを維持する
ために支出される評価コスト
内的障害コスト
製品の出荷以前に欠陥や品質不良が
発生する内部障害コスト
外的障害コスト
製品出荷後に市場で欠陥や品質不良が
発生する外部障害コスト
図：品質コスト / 出典：Rex Black著「ソフトウェアテスト12の必勝プロセス」の品質コストの説明をもとに図にしたもの
22

View Slide


View Slide

”全てのライフサイクルを通じて静的および動的に実施
するプロセス。成果物が特定の要件を満足するかを判
定し、目的に合致することを実証し、欠陥を見つけるた
め、コンポーネントやシステムおよび関連作業成果物に
対し、計画、準備、評価をすること。”
ISTQB Glossary https://glossary.istqb.org より

View Slide

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

View Slide

テストの目的も一義的ではない
要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することに
よって欠陥を防ぐ
明確にしたすべての要件を満たしていることを検証する
テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通
りの動作内容であることの妥当性確認をする
テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する
欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する
ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分
な情報を提供する
契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象
がそのような要件や標準に準拠していることを検証する
テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.1.1 テストに共通する目的」より引用
26

View Slide

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

View Slide

テストの7原則
欠陥がないことは示せない
原則 1
全数テストは不可能
原則 2
早期テストで時間とコストを節約
原則 3
欠陥の偏在
原則 4
殺虫剤のパラドックスにご用心
原則 5
テストは状況次第
原則 6
「バグゼロ」の落とし穴
原則 7
テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.3 テストの7原則」より引用
テストは欠陥がある
ことは示せるが、
28

View Slide

早
い
テストから得られる情報の
取得タイミングが早いほど価値が高い
安
い
テストから得られる情報の
取得コストが安いほど価値が高い
旨
い
テストから得られる情報がニーズに合致
していて正確で分かり易いほど価値が高い
本質的にテストの価値は情報取得

View Slide

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

View Slide

テストはテストのみでは存在しえない活動
（テストのことだけ考えても意味がない）
情報はそれを使うことで意味を持つ

View Slide

テストとは、テストとそれに関係する
テスト以外のことについても考えに考え
抜いてそれらの本質を知ること

View Slide


View Slide

テストレベル
テストタイプ
34

View Slide

テストレベルとは？
テストレベルは、系統的にまとめ、マネジメント
していくテストの活動のグループである。
“
具体的にインスタンス化したテストプロセス。
“
ISTQB Glossary https://glossary.istqb.org より
テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.2テストレベル」より
35

View Slide

開発したシステムがユーザの求めているものに合致して
いるか確認する（受け入れ可能かどうか判断する）テスト
最終的に統合されたシステム全体を、実環境
（またはそれに準ずる環境）で実施するテスト
統合テスト
テスト済みのコンポーネントや
システムを統合して行うテスト
コンポーネントテスト
分離してテストが可能なソフトウェアコンポーネント
（部品）ごとに単体で行うテスト
テ
ス
ト
対
象
と
し
て
着
目
す
る
詳
細
度
小
大
様々なテストレベルが存在する

View Slide

要件定義
外部設計
内部設計
実装
テスト
実装終わったらテストって乱暴すぎよね

View Slide

外部設計
内部設計
実装
要件定義
コンポーネント
テスト
統合テスト
対応関係
上流工程の開発と下流工程のテストにおける責務との対応関係
段
階
的
な
詳
細
化
段
階
的
な
統
合
38

View Slide

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

View Slide

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

View Slide

システム
要件
基本設計
詳細設計
実装
テストの計画
要求定義
テスト活動の
開始
の計画
統合テストの
計画
テストの実施
統合テストの
実施
の実施
の実施
Andreas Spillner 著 The W-MODEL Strengthening the Bond Between Development and Test より引用。翻訳は独自
対応関係サイクル:テスト、デバッグ、修正、再テスト
Wモデル: テスト活動をフロントローディングすると効果的
マスター
テスト計画
master test plan
レベルテスト計画
level test plan
level test plan
level test plan
level test plan
各テストレベルだけではなくテスト全体の絵を描こう

View Slide

テスト実行の自動化は低いテストレベルから
出典：「実践アジャイルテスト」の「テスト自動化のピラミッド」を元に改変・追記
GUI
テスト
APIレベルの
テスト
ユニットテスト/
手動テスト
高
低
費
用
対
効
果
保
守
性
難
易
実
行
速
度
遅
速

View Slide

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

View Slide

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

View Slide

システムテストレベルでの自動化
シスエムテスト自動化標準ガイド
マーク&ドロシー著/翔泳社刊
コンポーネントテストや統合テストレベルでの
テスト自動化は一般化してきたものの、システ
ムテストレベルはまだまだこれからといった感
じです
そのシステムテストレベルにおける自動化を
扱った書籍が左記のものです
また、この書籍を翻訳したシステムテスト自動
化研究会が毎年開催してるシステムテスト自動
化カンファレンス（STAC）の資料も公開も参考
になります
テスト自動化研究会が翻訳した「Software Test Automation 」。著者は
マーク&ドロシー。邦題はシステムテスト全般を指しているように見えるが機
能テストの自動化かメイン。

View Slide

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

View Slide

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

View Slide

テストレベルの本質を考えていくと
ソフトウェア開発ライフサイクルに留まらず
ソフトウェアライフサイクル全般における
テストの全体像を考えていくことに繋がる

View Slide


View Slide

テストレベル
テストタイプ
50

View Slide

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

View Slide

JSTQBによるテストタイプの分類
テストタイプ
機能テスト
機能の品質特性、例えば完全、
正確および適切であること
などを評価する。
非機能テスト
非機能の品質特性、例えば信頼
性、性能効率性、セキュリティ、
互換性、使用性などを評価する。
ホワイトボックス
テスト
コンポーネントまたはシステム
の、構造またはアーキテク
チャーが正しく完全で仕様通り
であることを評価する。
変更関連のテスト
欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、
ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを
探す（リグレッションテスト）。
52
テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より文章を引用し、独自に作図。

View Slide

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

View Slide

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

View Slide

• さまざまなテストを考慮するにあたり、品質モデルの各特性をガイ
ドワードとして利用するのは良いですが、テストの中にすべて押し
込むのは乱暴で、テストでは測りがたい特性もあります（たとえば、
保守性とか移植性とか）
• 前提として品質モデルはテストのためのモデルではないですし、各
品質の特性は相関関係があります。そして、すべての品質特性をフ
ル天にすれば良いわけでもありません
• 各特性が「どうあるべきか」は、本来的には品質要求として定める
必要があり、テストではその要求を満たしているのかを確認するこ
とになります
• 例えば、時間効率性（パフォーマンス）として、何msの応答であれば妥当である
かは品質要求次第

View Slide

品質特性間の相関関係の例
図：品質属性間のプラスとマイナスの相関関係 Karl E.著「ソフトウェア要求第3版」 P.333より。※なお、デザインに手を入れている
可
用
性
効
率
性
導
入
可
能
性
完
全
性
相
互
接
続
性
修
正
可
能
性
性
能
移
植
性
信
頼
性
再
利
用
性
堅
牢
性
安
全
性
拡
張
性
セ
キ
ュ
リ
テ
ィ
ユ
ー
ザ
ビ
リ
テ
ィ
検
証
可
能
性
可用性＋＋
効率性＋－－＋－－＋－
導入可能性＋＋＋
完全性－－－－＋＋－－
相互接続性＋－－－＋＋＋－－
修正可能性＋＋－－＋＋＋＋
性能－－－－－－－
移植性－＋－－＋－－＋
信頼性＋－＋＋－＋＋＋＋＋
再利用性－－＋＋－＋－＋
堅牢性＋－＋＋＋－＋＋＋＋＋
安全性－＋＋－＋＋－－
拡張性＋＋＋＋＋＋＋
セキュリティ＋＋＋－－＋＋＋－－
ユーザビリティ－＋－－＋＋＋－
検証可能性＋＋＋＋＋＋＋＋＋＋

View Slide

Product Quality
Functional
suitability
Performance
efficiency
Compatibility
Interaction
capability
Reliability Security Maintainability Flexibility Safety
Functional
completeness
Functional
correctness
Functional
appropriateness
Appropriateness
recognizability
Learnability
Operability
User error
protection
User
engagement
User
assistance
Self-
descriptiveness
Time behavior
Resource
utilization
Capacity
Co-existence
Interoperability
Confidentiality
Non-
repudiation
Integrity
Accountability
Authenticity
Resistance
Operational
constraint
Risk
identification
Failsafe
Hazard
warning
Safe
integration
Faultlessness
Availability
Fault
tolerance
Recoverability
Modularity
Reusability
Analyzability
Modifiability
Testability
Adaptability
Scalability
Installability
Replaceability
変更
新規追加
既存
凡例
図は、現在策定中（まだリリースされていない、ISO/IEC 25010の新しい製品品質モデルの主特性と副特性の案が出典。
策定中の情報についてはオフィシャルに表にでていませんが、この規格を策定するワーキンググループのコンビーナ（議長）である込山さんの資料を参照してください。
https://speakerdeck.com/washizaki/squareguan-lian-falsebiao-zhun-hua-falsequan-ti-dong-xiang-25010-25019gai-yao-ip-shan-jun-bo
製品品質のモデルも、時代と共に改訂を重ねてきており、先ISO/IEC25010:2013も
現在絶賛改訂作業中です。また、製品品質以外にも、SQuaREには利用時の品質、
データ品質、サービス品質なども規定されていています。

View Slide

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

View Slide

テストタイプを突き詰めていくと開発している
製品やサービスに求められていること、それら
の存在意義といった根源的なことに繋がる

View Slide


View Slide

テストレベル
テストタイプ
61

View Slide

テストプロセスとは？
相互に関連する活動のセット。テスト計画作業、
テストモニタリングとコントロール、テスト分析、
テスト設計、テスト実装、テスト実行、テスト完了
といった活動から構成される。
“
62

View Slide

テストプロセスの例（JSTQB）
テストプロジェクトのタイムライン
テ
ス
ト
分
析
テ
ス
ト
設
計
テ
ス
ト
実
装
テ
ス
ト
実
行
テストのモニタリングとコントロール
テ
ス
ト
計
画
テ
ス
ト
完
了
t
63

View Slide

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

View Slide

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

View Slide

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

View Slide

その他にも様々なテストプロセスモデルが
存在しているのでうまく活用しましょう！
但し、本質的にはコンテキストに沿ったテストのプロセス設計やテーラリングが必要です
Critical Testing Process
(CTP)
Systematic Test and
Evaluation Process(STEP)

View Slide

テストプロセスのためのプロセス改善モデルも色々あります
TPI NEXT
2009年
(日本語版が2015年9月に発売)
ISO/IEC 33063
2015年8月
TMMi Release 1.2
2018年
(version. 1.0は2008年)

View Slide

項目 TMMi TPI NEXT ISO/IEC 33063
所感
CMMIと同等の枠組み。CMMIのテスト
プロセス部分を補完する。CMMIについ
て既に経験や知識を持っている組織で
あれば展開は比較的容易であろう
改善提案やコツなどまで含めたガイドと
して利用可能。内容が具体的かつ実践的
で、現場でのセルフアセスメントなどにも
使いやすいものになっていると感じる
縦軸に ISO/IEC 33020 、横軸に
ISO/IEC/IEEE 29119-2を持つ新し
いテストアセスメントモデル。GP、GR、
GWPなどの評価指標が示されている
リリース年 2018年(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によれば「混合だが、どちらかと
言えば連続表現」との記述あり
※2: プロセスリファレンスモデルである ISO/IEC/IEEE
29119-2で定義されているプロセスは８プロセスのみであ
るが、実践のために5プロセスが追加で示されている。こ
れらはAnnexなどにnormativeとして記述されている
※3: ISO/IEC 33063のみでのページ数。関連規格を含めると
200ページを超える(Annexを含む)
※4: ISO/IEC 33063をJSA Web Storeで購入した場合の金額。
関連規格を含めると総額は10万円程となる
※5: (2016年3月時点では)JIS化されていない
各テストプロセス改善モデルの簡易比較

View Slide

テストプロセスの中でも特に重要なのが
テストケースを作るまでのイメージを持てること！
テスト設計※またはテスト準備、テスト計画など表現は様々
テスト
実行
テスト
要求分析
テスト
ｱｰｷﾃｸﾁｬ
設計
テスト
詳細設計
テスト
実装
テスト
実行
テスト分析テスト設計テスト実装
テスト
実行
未成熟な
テスト開発
プロセス
JSTQBの
テスト開発
プロセス
Test.SSFの
テスト開発
プロセス
この部分がテスト開発プロセス

View Slide

テスト技法を勉強して
演習では上手く使えたのに
実務ではどうやって技法を
適用すれば良いのか分からず
上手く使えていません(T_T)
https://www.pakutaso.com/20141152308post-4790.html

View Slide

Test Design
Technic
Test
Basis
Test
Cases
Test
Basis
Test
Cases
Test
Cases
テストベース
※
に対していきなり
テスト技法を適用している？
※テストベースとはテストを考える上で入力となる情報全般のこと。例えば要件定義書、仕様書、外部設計書など様々
Test Design Technics

View Slide

Test Design
Technic
Test
Basis
Test
Cases
Test
Basis
Test
Cases
Test
Cases
Test Design Technics
それは失敗フラグです

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

ソフトウェアライフサイクルの中で継続的に行っていく
各テストの特徴を見据えたプロセスを設計する

View Slide

ライフサイクルの中にパイプラインも構築していく
Deploy
Stage
Test
Build
Commit
継続的デリバリー（CD）
継続的インテグレーション（CI）
継続的デプロイメント（CD）

View Slide

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

View Slide


View Slide

テスト技法とは？
テスト条件の定義、テストケース
の設計、およびテストデータの明
確化をするための手続き。
“
82

View Slide

Input Output
ブラックボックステスト
テスト対象の(内部)構造には着目せ
ずにテストケースを導出するテスト
技法の総称
テスト対象の(内部)構造に着目して、
テストケースを導出するテスト技法
の総称
Input Output
昔ながらのテスト技法の分類

View Slide

JSTQBによるテスト技法の分類
ブラックボックステスト技法
同値分割法
境界値分析
ﾃﾞｼｼﾞｮﾝﾃｰﾌﾞﾙﾃｽﾄ
状態遷移テスト
ユースケーステスト
その他
ホワイトボックステスト技法
デシジョンテスト
その他
経験ベースのテスト技法
その他
ﾁｪｯｸﾘｽﾄﾍﾞｰｽﾄﾞﾃｽﾄ
探索的テスト
エラー推測
組み合わせられる組み合わせられる
84

View Slide

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

View Slide

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

View Slide

なぜちゃんとテスト設計
しなければならないのか？

View Slide


View Slide

同値分割法
同じ結果が得られるグループ（同値パーティション）に分割し、
その中から代表値をテストケースとして選定します
代表値a
i
代表値c
k
代表値b
j
89

View Slide

着目する点 • 等価とみなせる値のグループ(同値パーティション)
ポイント
• 同値パーティションから代表値一つを選ぶことで、
そのグループの値すべてをテストしたことと等価とみなす
• 同値パーティションを考えるときは、有効な値だけでなく、
無効な値の同値パーティションも考慮する
• 分割する範囲を誤るとテスト漏れが起きる点に注意
メリット • より少ないテストケース数で対象範囲を網羅できる
キーワード
• 同値パーティション（同値クラスとも呼ぶ）
• 有効同値パーティション
• 無効同値パーティション
同値分割法の特徴

View Slide

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

View Slide

同値分割の対象に順序性がある場合(数値/時間/順番など)、代表値を
任意に選ぶのではなく、同値パーティション間の境界の値をテストケー
スとして選定します
境界値分析
7 8 24 25
パスワードとして適切な
長さの有効同値
パーティション
パスワードとしては
短い無効同値
パスワードとしては
長すぎる無効同値
0
※25文字目は存在しないが、入力を
無効化する機能をテストするための
論理的な値として25文字を上限とする。
※文字数が負の数はあり
えないので０を下限とする
有効な境界値無効な境界値
92

View Slide

着目する点 • 同値パーティションに順序性がある場合の境界近傍
ポイント
• 欠陥が境界付近に埋め込まれることが多いという
経験則に基づいている（例：＞を≧と誤ってしまう）
• 上限や下限が定まっていないなど、範囲が開いている
場合はテストとして別途上限と下限を決める必要あり
メリット
• 少ないテストケースで、よりバグが潜んでいそうな箇所を
狙い打てる（同値分割法では見つからない欠陥を見つけ
られる可能性が高まる）
キーワード
• 境界値（2値の境界値、3値の境界値）
• 下限
• 上限
境界値分析の特徴

View Slide

境界値分析のカバレッジ
N
T
× 𝟏𝟎𝟎 %
𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: 境界値分析カバレッジ
N: 実行したテストケースによってカバーされる明確な境界値の数
T: 境界値の総数

View Slide

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

View Slide

着目する点 • 論理関係(条件の組み合わせによって動作が確定するような
ロジックを持つもの。有則や禁則)
ポイント • IF文のような判定文をはじめ、論理関係があるものは
おしなべてデシジョンテーブルとして表現できる
メリット • 複数の条件によって動作が異なるようなロジックを
漏れなく整理することができる
キーワード
• 決定表
• テーブルの簡単化（圧縮）
デシジョンテーブルテストの特徴

View Slide

デシジョンテーブルテストのカバレッジ
N
T
× 𝟏𝟎𝟎 %
𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: デシジョンテーブルテストカバレッジ
N: 実行したテストケースによってカバーされる、実行可能な判定規則の数
T: 実行可能な判定規則の総数

View Slide

• 状態遷移モデルをもとにテストを導出するテスト技法
• 状態遷移モデルは、ソフトウェアの状態と、その遷移に
着目したモデルで、UMLのステートマシン図も状態遷移
モデルのひとつ
• 組込みソフトウェアではよく使われるが、それ以外にも
ビジネスシナリオのモデル化や、画面遷移なども状態
遷移モデルとして整理することもある

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

OS アーキテクチャブラウザ
1 Windows 10 32bit IE11
2 Windows 8.1 32bit Chrome
3 Windows 7 32bit Firefox
4 Windows 10 64bit Edge
5 Windows 8.1 64bit IE11
6 Windows 10 64bit Chrome
9 Windows 8.1 32bit IE10
13 Windows 8.1 32bit Firefox
17 Windows 10 32bit Edge
任意の2因子間に含まれる水準の組み合わせが最低でも1回以上出現する
ように作られた組み合わせ表の各行をテストケースとして選定します
因
子
OS ｱｰｷﾃｸﾁｬブラウザ
水
準
Windows 7
Windows 8
Windows 8.1
Windows 10
32bit
64 bit
IE11
Edge
Chrome
Firefox
2因子網羅100％とは以下の因子のペアにおいて、因
子に含まれる全ての水準の組み合わせが少なくとも1
つ以上存在します
• OSとアーキテクチャ
• OSとブラウザ
• アーキテクチャとブラウザ
全網羅の場合38通りの組み合わせになりますが、
2因子網羅100％で良い場合は17になります
※制約: 取り得ない組み合わせは省いています
ペアワイズテスト

View Slide

着目する点 • 意図しない影響を及ぼす組み合わせ（無則）
ポイント
• 禁則(組み合わせることができないペア）を考慮しないと、実
施不可能なテストケースの組み合わせが作られる
• 2因子網羅で充分かどうか、3因子網羅でなくとも
よいかどうかは、別途検討する必要がある
メリット
• 2因子間網羅100％を可能な限り少ないテストケースで実施
できる（組み合わせを現実的な数のテストケース数に圧縮で
きる）
キーワード
• 因子（Factors)/水準（Levels）
• 制約（とりえない組み合わせ)
• n-wiseカバレッジ（n因子網羅）
ペアワイズテストの特徴

View Slide

ペアワイズテストのカバレッジ
N
T
× 𝟏𝟎𝟎 %
𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: ペアワイズテストカバレッジ
N: 実行したテストケースによってカバーされる、P-Vペアの数
T: ユニークなP-Vペアの総数
※P-Vペア（Parameter-Value pair）は組み合わせテストにおけるカバレッジアイテム。ペアワイズテストにおけるPVペアは、
2因子間の水準のペア。例えば「Windows7とChrome」という2因子間の水準のペアが1つのP-Vペア

View Slide

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

View Slide

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

View Slide


View Slide

その際にはSQuBOKガイドなどもオススメします
全体の軸を持った上でSQuBOKガイドな
どを効率よく知識を吸収していけます
品質やテストに関する用語で分からない
ものがあればまずはこれにあたり詳細に
ついてはガイドが示す参考資料をあたる
のをオススメします
※ ついこの間、第3版にアップグレードさ
れて出版されたので、いまが買い時です

View Slide

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

View Slide

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

View Slide

テストレベル
テストタイプ
114

View Slide

テストプロセスの例（JSTQB）
プロジェクトタイムライン
テ
ス
ト
分
析
テ
ス
ト
設
計
テ
ス
ト
実
装
テ
ス
ト
実
行
テストのモニタリングとコントロール
テ
ス
ト
計
画
テ
ス
ト
完
了
115

View Slide

開発したシステムがユーザの求めているものに合致して
いるか確認する（受け入れ可能かどうか判断する）テスト
最終的に統合されたシステム全体を、実環境
（またはそれに準ずる環境）で実施するテスト
統合テスト
テスト済みのコンポーネントや
システムを統合して行うテスト
分離してテストが可能なソフトウェアコンポーネント
（部品）ごとに単体で行うテスト
テ
ス
ト
対
象
と
し
て
着
目
す
る
詳
細
度
小
大
様々なテストレベルが存在する

View Slide

JSTQBによるテストタイプの分類
テストタイプ
機能テスト
機能の品質特性、例えば完全、
正確および適切であること
などを評価する。
非機能テスト
非機能の品質特性、例えば信頼
性、性能効率性、セキュリティ、
互換性、使用性などを評価する。
ホワイトボックス
テスト
コンポーネントまたはシステム
の、構造またはアーキテク
チャーが正しく完全で仕様通り
であることを評価する。
欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、
ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを
探す（リグレッションテスト）。
117
テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より文章を引用し、独自に作図。

View Slide

テストの空間の第1面（テストタイプ×テストレベル）
統合テスト
機
能
テ
ス
ト
セ
キ
ュ
リ
テ
ィ
テ
ス
ト
相
互
運
用
性
テ
ス
ト
使
用
性
テ
ス
ト
・・・
ホ
ワ
イ
ト
ボ
ッ
ク
ス
テ
ス
ト
変
更
関
連
の
テ
ス
ト
非機能テスト

View Slide

テストの空間の第2面（テストプロセス×テストレベル）
統合テスト
テ
ス
ト
計
画
テ
ス
ト
分
析
テ
ス
ト
設
計
テ
ス
ト
実
装
テ
ス
ト
実
行
テ
ス
ト
完
了
テ
ス
ト
の
Ｍ
＆
Ｃ

View Slide

テストの空間の第３面（テストプロセス×テストタイプ）
機能テスト
非
機
能
テ
ス
ト
セキュリティテスト
相互運用性テスト
使用性テスト
･･･
テ
ス
ト
計
画
テ
ス
ト
分
析
テ
ス
ト
設
計
テ
ス
ト
実
装
テ
ス
ト
実
行
テ
ス
ト
完
了
テ
ス
ト
の
Ｍ
＆
Ｃ

View Slide


View Slide

テスターのスキルスペース
TEST
SKILLS
DOMAIN
KNOWLEDGE
SOFT
SKILLS
IT
SKILLS
Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)
123

View Slide

テスト以外の知識も必要です
TEST
SKILLS
DOMAIN
KNOWLEDGE
SOFT
SKILLS
IT
SKILLS
Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)
124

View Slide

主な参考文献・参考資料
JSTQB/ISTQB関連
• ISTQB Glossary （用語集）
• テスト技術者資格制度Advanced Levelシラバス日本語版テストマネージャ
• テスト技術者資格制度Foundation Levelシラバス日本語版Version 2018V3.1.J03
• JSTQB認定ソフトウェアテスト技術者Foundation Levelトレーニングコース資料（山﨑崇）
ISO/IEC/IEEE 29119
• ISO/IEC/IEEE 29119-2:20２１ Software testing – Part 2: Test processes
• ISO/IEC/IEEE 29119-3:20２１ Software testing – Part 3: Test documentation
• ISO/IEC/IEEE 29119-4:20２１ 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 初心者セッション (片山徹郎長谷川聡)
主な写真素材

View Slide

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

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

YAMASAKI Takashi

More Decks by YAMASAKI Takashi

Other Decks in Technology

Featured

Transcript