はじめに
続編です。
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その1 テストの基礎〜
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その2 ソフトウェア開発ライフサイクル全体を通してのテスト〜 ← ここ
注意事項
あくまで、JSTQBのFLシラバス理解に向けた個人的メモです。
「これを読んだら FLシラバスが習得できます！」とかじゃないです。全然違います。
当然ですけど、こんな記事より「JSTQBのHP - JSTQB公認研修コース」に参加するのが正しい道です。（もしくは自力でシラバスを読むか。）
※本記事は「Foundation Level シラバス 日本語版 Version 2018.J03」を対象にしています。
2 ソフトウェア開発ライフサイクル全体を通してのテスト
100min
キーワード
ひとまずぱっと見、分からなかったものだけ調べるようにしてみる。
キーワードで理解できなかったもの
似たような用語が多くて、元々の知識では違いが説明できない・・・
◆受け入れテスト系：思ってたよりそのままだった
| 用語 | 意味 | Qbookの用語説明(JSTQB準拠) |
|---|---|---|
| 受け入れテスト | システムが、ユーザのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。 | link |
| 運用受け入れテスト | 受け入れテストフェーズでの運用テスト。 | link |
| ユーザー受け入れテスト | システムが、ユーザのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。 | link |
| 契約による受け入れテスト | カスタムメイドのソフトウェアを開発する場合に、契約書に記述した受け入れ基準に従って行う。（シラバスp37） | （該当なし) |
| 規制による受け入れテスト | 政府、法律、安全の基準などに合致しているかを確認する。（シラバスp37） | （該当なし) |
◆統合テスト系：思ってたよりそのままだった
| 用語 | 意味 | Qbookの用語説明(JSTQB準拠) |
|---|---|---|
| 統合テスト | 統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト。 | link |
| コンポーネントテスト | 個々のソフトウェアコンポーネントのテスト。 | link |
| コンポーネント統合テスト | 統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。 | link |
| システムテスト | 統合されたシステムが、特定の要件を満たすことを実証するためのテストのプロセス。 | link |
| システム統合テスト | システムやパッケージを統合して行なうテスト。 | link |
◆回帰テスト系：「確認テスト」って普段わざわざ言わないけど、アレのことね。
| 用語 | 意味 | Qbookの用語説明(JSTQB準拠) |
|---|---|---|
| 確認テスト | 修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。 | link |
| リグレッションテスト | 変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのプログラムに対して実行するテスト。 | link |
| メンテナンステスト | メンテナンスの一環として変更が発生した場合は、変更が正しく適用されていることを評価し、システムの変更していない部分（システムの大部分を占める）での副作用（例えば、リグレッション）を確認する（シラバスp42） | （該当なし） |
◆その他テスト：アルファテスト/ベータテストとかはゲームでよく聞くイメージ。
| 用語 | 意味 | Qbookの用語説明(JSTQB準拠) |
|---|---|---|
| アルファテスト | 潜在的なユーザ、顧客又は開発者のサイトではなく、開発組織の外部で独立したテストチームが、シミュレーションや実際のオペレーションにより実行するテスト。 | link |
| ベータテスト | 製品開発環境以外の外部環境で、現在、あるいは、将来のユーザや顧客が実施するテスト。 | link |
◆その他用語：「市販ソフトウェア」はテスト的に注意ポイントがあるから用語化してるのかな？
| 用語 | 意味 | Qbookの用語説明(JSTQB準拠) |
|---|---|---|
| 市販ソフトウェア（COTS） | 一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。 | link |
| テストレベル | 系統的にまとめ、管理していくテストの活動のグループ。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。 | link |
| テストタイプ | コンポーネント又はシステムをテストするためのテスト活動をまとめたものであり、たとえば機能テスト、使用性テスト、回帰テストなどのように特定のテスト目的に焦点を当てている。 | link |
2.1 ソフトウェア開発ライフサイクルモデル
以降は、学習目標が定義されているので、シラバスを読んだ上での理解を学習目標ごとに整理していく。
ただ、学習目標に外れる気になったことは随時記載していく。
K2 ソフトウェア開発ライフサイクルにおけるソフトウェア開発活動とテスト活動の関係を説明する。
どんな場合でも当てはまる、良いテストを行うときの特徴
-
開発活動に対応している
- 各開発活動に対応してテスト活動がある。
-
テストレベル毎に特有の目的がある
- 各テストレベルには、そのレベル特有の目的がある。
-
なるべく早くテストする
- 各テストレベルのテスト分析や設計は、対応する開発活動の間に開始する。
- テスト担当者は要件と設計を定義および洗練する討議に参加し、作業成果物のドラフトができたらすぐにそのレビューに関与する。
- 早期テストのテスト原則に従い、テスト活動はライフサイクルの早い段階に開始する。
「シーケンシャル開発モデル」とテスト活動
ウォーターフォールでは、テスト活動はその他の開発活動がすべて完了した後に実行する。
→設計も実装も終わってから、テストのことを考えるのが、「ウォーターフォールモデル」って定義なんだな。
V字モデルでは、各開発フェーズにテストレベルが対応している。
→基本設計の中で、結合テストを考えて・・・みたいなのが、「V字モデル」って定義なんだな。
※「V字モデル」のことを、一般的に「ウォーターフォール」と呼ぶのかと勝手に思い込んでたけど、シラバス上では厳密に分けて表現しているってことだろうな。
直接的には表現されてないけど「早期テストの原則」を満たしているV字モデルの方を推奨しているように読み取れる。
「イテレーティブ/インクリメンタル開発モデル」とテスト活動
インクリメンタル開発は、システムを分割し、分割単位ごとに要件の確定、設計、構築、テストを行う。
イテレーティブ開発モデルでは、グループにしたフィーチャー群を、一連のサイクル（多くの場合、固定された期間）の中で一緒に仕様化、設計、構築、テストする。
ひとまず以下理解とした。
- インクリメンタル開発モデルは、「システムの分割」を中心に据えた開発モデルの考え方。分割した単位ごとに完成させていくイメージ。
- イテレーティブ開発モデルは、「一連のサイクル（多くの場合、固定された期間）」を中心に据えた開発モデルの考え方。
開発モデルの特徴（テスト活動に関連する部分）：シラバスの記載を分類分けして表現をちょっと直しただけ
- テストの繰り返し/自動化を考える
- 開発全体を通してテストレベルの重複や繰り返しが発生することが多い。
- 複数のテストレベルを大幅に自動化するために、CI/CDを使用する場合がある。
- 提供されるまでに、複数のテストレベルでテストされていることが望ましい。
- 自己組織化されたチームであるべし
- これまでのテストにおける仕事内容の変更、およびテスト担当者と開発担当者の関係を変更できる自己組織化されたチームの概念が必要。
- システムの段階的な成長を可能にする
- 段階的に成長するシステムは、イテレーションごとなどの形態でエンドユーザーに提供される場合がある。
- システムが成長するにつれてリグレッションテストの重要性は増大する。
- 使用可能なソフトウェアを数週間、極端な場合には数日で提供できる。
- ただし、要件が完全に満たされた製品の提供には数か月から極端な場合には数年を要する。
アジャイル開発におけるソフトウェアテストの詳細については、『ISTQB テスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 日本語版』、『Black 2017』、『Crispin2008』、『Gregory 2015』を参照されたい。
日本語版がある！嬉しい。後でこっちも読もう。
K1 ソフトウェア開発ライフサイクルモデルを、プロジェクトやプロダクトの特性に合わせて調整する必要がある理由を識別する。
ソフトウェア開発ライフサイクルモデルの選択と調整
以下に基づいて適切に行うべし。（端的に言えば、ミッションクリティカルなシステムとそうじゃないシステムとでは違うよねーという話。）
- プロジェクトのゴール
- 開発するプロダクトの種類
- ビジネス上の優先度（市場に参入するまでの時間など）
- 識別したプロダクトリスク・プロジェクトリスク
テストレベルおよび／またはテスト活動の組み合わせおよび再編成
市販ソフトウェア（COTS）製品を組み込む場合、「システム統合テストレベル」と「受け入れテストレベル」で相互運用性テストを購入者が実施する必要がある。
※相互運用性テスト：ソフトウェア製品の相互運用性を判定するテストのプロセス。
※相互運用性：共通の仕様やデータ形式、伝送手順などに対応しており、互いに相手にデータを伝達したり、機能を呼び出して使用したりできること。
「システム間インターフェースレベル（システム統合テストレベル）」と、「ユーザーオペレーションレベル（受け入れテストレベル）」の両方を実施する必要があるよ、って理解であっているかな・・・？
ソフトウェア開発ライフサイクルモデルを組み合わせる場合
例えば、バックエンド・・・の開発とテストに V 字モデルを使用し、フロントエンド・・・の開発とテストにアジャイル開発モデルを使用する場合がある。
プロジェクトの初期ではプロトタイピングを使用し、試行フェーズが完了した後ではインクリメンタル開発モデルを採用する場合がある。
はい。
IoT
後期となる本番運用開始後のフェーズ（運用フェーズ、更新フェーズ、廃止フェーズ）がきわめて重要になる。
だいぶ割愛したけど、「バージョン管理含め、運用がものすごい大変だよ！」ってことだと理解した。
2.2 テストレベル
K2 目的、テストベース、テスト対象、典型的な欠陥と故障、アプローチや責務の観点から、さまざまなテストレベルを比較する。
テストレベルは、系統的にまとめ、マネジメントしていくテストの活動のグループである。
はい。
各テストレベルは、1.4 節で説明した活動で構成されるテストプロセスのインスタンスであり、個々のユニットまたはコンポーネントから完成したシステムまでの特定の開発レベル、または必要に応じてシステムオブシステムズまでの開発レベルのソフトウェアに関連している。
一回読んだだけじゃ全然頭に入ってこないぞ、この文章。
ちょっと耳慣れない単語が多いせいだろう。
- 開発レベル：「テストレベル」的な意味合いでの「開発レベル」ってことだと理解する。
- テストプロセスのインスタンス：「インスタンス化」的なニュアンスだとするなら、「テストプロセスの実体」って感じ？「実際の現場に適用された状態のプロセス」だと理解しよう。
- システムオブシステムズ：ひとまず「広い意味で、1つのサービスを提供するシステム群」って理解。
用語を整理したらなんとなく理解できた。
テストレベルは、以下の属性で特徴付けられる。
- 特定の目的
- テストベース（テストケースの導出時に参照）
- テスト対象（すなわち、テストするものは何か）
- 典型的な欠陥と故障
- （そのテストレベルでの）アプローチと責務
| 用語 | 意味 | Qbookの用語説明(JSTQB準拠) |
|---|---|---|
| テストベース | コンポーネント要件やシステム要件を推測できる全てのドキュメント。 | link |
テストレベルそれぞれに適切なテスト環境が必要である。例えば、受け入れテストでは本番環境に類似したテスト環境が理想であり、コンポーネントテストでは、開発担当者は彼ら所有の開発環境を使用するのが一般的である。
「受け入れテストでは本番環境に類似したテスト環境が理想であり」って表現に悲哀を感じる。（理想だけど、現実にはできないことが多いよね的なニュアンスを感じる）
◆比較◆
目的
| 目的 | コンポーネント | 統合 | システム | 受け入れ |
|---|---|---|---|---|
| リスクの軽減 | ◯ | ◯ | ◯ | - |
| ☓☓に存在する欠陥の検出 | コンポーネント | ・インターフェース ・コンポーネント ・システム |
（すべて） | - |
| 欠陥がより高いテストレベルまで見逃されることの防止 | ◯ | ◯ | ◯ | - |
| ◯◯の機能的/非機能的振る舞いが設計および仕様通りであることの検証 | コンポーネント | インターフェース | システム | システム |
| ◯◯品質に対する信頼の積み上げ | コンポーネント | インターフェース | システム | システム |
| システムが完成し、期待通りに動作することの妥当性確認 | - | - | ◯ | ◯ |
＜疑問＞
- 「リスクの軽減」って表現、広すぎない？
- 目的だけだと「システムテスト」と「受け入れテスト」が似てるけど、どう違うの？
- たぶん「アプローチと責務」が違うのだと思われる。「アプローチと責務」については、以降、各テストレベルごとに整理する。
テストベース・テスト対象（例）
※悩んだ結果、上の表と、x軸とy軸を変えてます・・・
当たり前だけど、あくまで例でしかないので、これに則れば良いという話ではない。
| テストレベル | テストベース | テスト対象 |
|---|---|---|
| コンポーネント | ・詳細設計 ・コード ・データモデル ・コンポーネント仕様 |
・コンポーネント、ユニット、またはモジュール ・コードとデータ構造 ・クラス ・データベースモジュール |
| 統合 | ・ソフトウェア設計とシステム設計 ・シーケンス図 ・インターフェースと通信プロトコルの仕様 ・ユースケース ・コンポーネントレベルまたはシステムレベルのアーキテクチャー ・ワークフロー ・外部インターフェース定義 |
・サブシステム ・データベース ・インフラストラクチャー ・インターフェース ・API ・マイクロサービス |
| システム | ・システム要求仕様およびソフトウェア要求仕様（機能および非機能） ・リスク分析レポート ・ユースケース ・エピックおよびユーザーストーリー ・システム振る舞いのモデル ・状態遷移図 ・システムマニュアルおよびユーザーマニュアル |
・アプリケーション ・ハードウェア/ソフトウェアシステム ・オペレーティングシステム ・テスト対象システム（SUT） ・システム構成および構成データ |
| 受け入れ（一般） | ・ビジネスプロセス ・ユーザー要件またはビジネス要件 ・規制、法的契約、標準 ・ユースケース ・システム要件 ・システムドキュメントまたはユーザードキュメント ・インストール手順 ・リスク分析レポート |
・テスト対象システム ・システム構成および構成データ ・完全に統合されたシステムのビジネスプロセス ・リカバリーシステムおよび（ビジネス継続性および災害復旧のテスト用の）ホットサイト ・運用プロセスおよびメンテナンスプロセス ・書式 ・レポート ・既存または変換（コンバージョン）した本番データ |
| 受け入れ（運用） | ・バックアップ/リストアの手順 ・災害復旧手順 ・非機能要件 ・運用ドキュメント ・デプロイメント指示書およびインストール指示書 ・性能目標 ・データベースパッケージ ・セキュリティ標準または規制 |
- |
典型的な欠陥と故障
| テストレベル | 典型的な欠陥と故障 |
|---|---|
| コンポーネント | ・正しくない機能（例えば、設計仕様の記述とは異なる） ・データフローの問題 ・正しくないコードとロジック |
| 統合（コンポーネント統合） | ・正しくないデータ、データ不足、正しくないデータエンコーディング ・インターフェース呼び出しの正しくない順序またはタイミング ・インターフェースの不整合 ・コンポーネント間のコミュニケーション故障 ・コンポーネント間のコミュニケーション故障の処理不在、または不適切な処理 ・コンポーネント間で渡されるデータの意味、単位、境界の正しくない思い込み |
| 統合（システム統合） | ・システム間で一貫性のないメッセージ構造 ・正しくないデータ、データ不足、正しくないデータエンコーディング ・インターフェースの不整合 ・システム間通信による故障 ・システム間通信処理不在、または不適切な処理による故障 ・システム間で渡されるデータの意味、単位、境界の正しくない思い込み ・必須のセキュリティ規制への非準拠 |
| システム | ・正しくない計算 ・正しくない、または期待通りではないシステムの機能的または非機能的振る舞い ・システム内の正しくない制御フローおよび／またはデータフロー ・エンドツーエンドの機能的タスクを適切かつ完全に実行できない ・本番環境でシステムが適切に動作しない ・システムマニュアルおよびユーザーマニュアルに記載されている通りにシステムが動作しない |
| 受け入れ | ・システムのワークフローがビジネス要件またはユーザー要件を満たさない。 ・ビジネスルールが正しく実装されていない。 ・システムが契約要件または規制要件を満たさない。 ・セキュリティの脆弱性、高負荷時の不適切な性能効率、サポート対象プラットフォームでの不適切な操作などの非機能特性の故障。 |
欠陥と故障・・・違いなんだっけな・・・
エラー（人的要因） → 欠陥（故障を引き起こしうる成果物の誤り） → 故障（業務的不都合）
エラー：人、欠陥：モノ、故障：結果（影響は含めない、あくまで直接的な結果）
（前作「テストを学びたくてJSTQBのFLシラバスを読んでみた〜その1 テストの基礎〜」より引用。）
◆コンポーネントテスト◆
コンポーネントテスト（ユニットテストまたはモジュールテストとも呼ばれる）は、個別にテスト可能なコンポーネントに焦点をあてる。
「個別にテスト可能な」か。
というか、「コンポーネント」を「どういう単位」と定義づけるのだろうか。（クラス単位？1つの機能を実現するクラス群？）
特にコード変更が継続して行われるインクリメンタル開発モデルやイテレーティブ開発モデル（アジャイルなど）では、コンポーネントテストのリグレッションテストを自動化して、変更が既存のコンポーネントを破壊していないという信頼を積み重ねていくことが重要である。
コンポーネントテストは、機能性（例えば計算の正しさ）、非機能特性（例えばメモリリークの検出）、構造の属性（例えばデシジョンテスト）も含む。
ほーん。
アプローチと責務
コンポーネント用のコードを記述した後で、テストを記述し実行することが多い。
ただし、特にアジャイル開発では、アプリケーションコードを記述する前に、自動化されたコンポーネントのテストケースを記述する場合がある。
テスト駆動開発は、テストファーストアプローチの一例である。
テスト駆動開発はエクストリームプログラミング（XP）がオリジナルであるが、アジャイル開発の他のアプローチおよびシーケンシャルライフサイクルにも普及している（『ISTQB テスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 日本語版』を参照）。
「そっすね」って感想。
◆統合テスト◆
統合テストは、コンポーネントまたはシステム間の相互処理に焦点をあてる。
「相互処理」。はい。
コンポーネントテストと同様に、統合テストのリグレッションテストを自動化する場合があり、自動化したリグレッションテストにより、変更が既存のインターフェース、コンポーネント、システムを破壊しないという信頼を提供できる。
本シラバスで説明しているように、統合テストには 2 つの異なるレベルがあり、以下のようにさまざまな大きさのテスト対象物に対して実施する。
「本シラバスで説明しているように、統合テストには2つの異なるレベルがあり」って、そんな話あったっけ・・・
コンポーネント統合テストは、統合するコンポーネント間の相互処理とインターフェースに焦点をあててテストする。
システム統合テストは、システム、パッケージ、マイクロサービス間の相互処理とインターフェースに焦点をあててテストする。
外部組織（Web サービスなど）との相互処理、または外部組織により提供されるインターフェースをカバーすることもある。
違和感無い。（だいぶ割愛した。）
アプローチと責務
コンポーネント統合テストとシステム統合テストは、統合だけに集中すべきである。
おっとぉ。統合だけに集中できてないこと多かったかも。コンポーネントテストと被らせるのが一般的かと思ってた。
あ、いや、「テストレベル」と「テストフェーズ」を混同してるわ。「テストレベル」としてこういう定義ってのは理解した。
テストレベルとかの話は、こちらのが整理されているので、そちらを読みましょう・・・
Tsuyoshi Yumoto - フェーズ、レベル、タイプ、技法
＜解消されてない疑問＞
うまくいえないんだけど、コンポーネントの粒度によって、コンポーネントテストも統合テストも、どうとでも捉えられるのでは・・・？
Javaのクラス単位をコンポーネントと捉えたら、クラス間のメソッド呼び出しは統合テストになるのでは・・・？
jUnitでクラス単体でテストできるわけだし。
たぶん、外部から見た振る舞いという点で、「1つの振る舞いを提供するクラス群」をコンポーネントと捉えるのが、この文脈だとは思うけど・・・
う～ん。。。
いまいち腹落ちしてないけど、何度読んでもここだけでは答え出なさそうなので、先に進むことにする。
テストタイプのうち、機能テスト、非機能テスト、構造テストは統合テストで行うことができる。
テストタイプはまだ出てきてないので、出てきたらもう少し掘り下げたい。できれば、「統合テストでできないテストタイプ」も具体例が知りたいところ。
理想的には、システム統合テストを実行するテスト担当者はシステムアーキテクチャーを理解すべきであり、統合計画の作成に関与すべきである。
せやろな。
コンポーネントまたはシステムの構築前に統合テストと統合戦略を計画すると、テストの効率が最大になる順序でコンポーネントとシステムを構築できる。
体系的に統合する戦略は、システムアーキテクチャー（トップダウンやボトムアップなど）、機能的タスク、トランザクション処理シーケンス、その他システムやコンポーネントの側面がベースとなる。
コレ自体は分かるんだけど、アジャイルの時とかのテスト計画ってどう考えればいいんだろうか？
それはアジャイルのシラバスを読めって感じだろうか。きっとそうだろう。
欠陥の特定を容易にし、早期に検出するために、統合は「ビッグバン（すべてのコンポーネントやシステムに対して一度に実施）」ではなく、インクリメンタル（同時には少数のコンポーネントまたはシステムを追加）するのが普通である。
うぃっす。
統合の範囲が大きくなるほど、欠陥を特定のコンポーネントまたはシステムに絞り込むことが難しくなる。
継続的インテグレーションでは、リグレッションテストの自動化を複数のテストレベルで行うことが理想である。
「理想である」。でも、現実は難しい？
自プロジェクトで、統合テスト、コンポーネントテスト双方のテストレベルに対する自動テストはできている。（全ケースが網羅できているわけじゃないし、網羅する必要も無いと思ってるけど。）
ただ、この自動化の勘所みたいなのは、ある種スキルみたいなもんだよなぁと強く感じる。
ISTQBも「Test Automation Engineer」を定義しているくらいだしな。
そういえば、JSTQBで受けられない試験はどこで受ければいいんだ？？？
ちらっと見た限りだと、海外に行く必要あるっぽい。
◆システムテスト◆
システムテストは、システムが実行するエンドツーエンドのタスクと、タスクの実行時にシステムが示す非機能的振る舞いといったシステムやプロダクト全体の振る舞いや能力に焦点をあてる。
信頼できるシステムとなるためには、データ品質の検証も目的とする。
はい。
コンポーネントテストや統合テストと同様に、システムテストのリグレッションテストを自動化する場合があり、自動化したリグレッションテストにより変更が既存のフィーチャーやエンドツーエンドの能力を破壊していないという信頼を提供できる。
ステークホルダーは、システムテストの情報に基づいてリリースに関する意志決定を行うことが多い。
はい。
アプローチと責務
システムテストは、システム全体の機能と非機能の両方について、エンドツーエンドの全体的な振る舞いに焦点をあてる。
システムテストでは、対象となるシステムにとって最適なテスト技法（第 4 章を参照）を使用する。
例えば、デシジョンテーブルを使用して、機能的な振る舞いがビジネスルールで規定されている通りであることを検証する場合がある。
システムテストでは・・・ってあるけど、別にコンポーネントテストでも、結合テストでもテスト技法って使うのでは・・・？？？
テスト技法の章を見るときにちゃんと見てみるか・・・
独立したテストチームがシステムテストを行うことが多い。
仕様の欠陥（例えば、ユーザーストーリーの欠落、ビジネス要件の正しくない記述など）は、システムの期待される振る舞いに関する正しい理解の欠落や誤解につながる。
この状況が偽陽性や偽陰性の結果を招き、時間の浪費や欠陥検出効率の低下となる。
テスト担当者がユーザーストーリーを洗練する活動およびレビューなどの静的テストの活動に早期から関与することで、このような状況が起きることを削減できる。
「偽陽性」「偽陰性」ってなんだっけな。普段使わない用語は、一瞬で忘れてしまうなぁ・・・
偽陽性（誤検出）：実際には欠陥でないものを欠陥として報告してしまうこと。
偽陰性（検出もれ）：検出すべき欠陥を検出しないテスト。
（前作「テストを学びたくてJSTQBのFLシラバスを読んでみた〜その1 テストの基礎〜」より引用。）
◆受け入れテスト◆
システムテストと同様、一般的に受け入れテストはシステムやプロダクト全体の振る舞いや能力に焦点をあてる。
はい。
受け入れテストからの情報に基づいて、システムが導入に向けて準備できているかどうか、および顧客（エンドユーザー）が使用できるかを評価できる。受け入れテストで欠陥が見つかることはあるが、欠陥を見つけることは目的ではない。とても多くの欠陥が受け入れテスト時に検出されるような事態は、重要なプロジェクトリスクと見なすことができる。受け入れテストでは、法的または規制的要件または標準を満たすことを確認する場合もある。
受け入れテストは、「システムが導入に向けて準備できているかどうか、および顧客（エンドユーザー）が使用できるか」を評価するのが目的。
あくまでユーザー目線として、って感じかな。
でも、これに相当する定義がシステムテスト側に記載されていないから、上手く対比できないんだよなぁ・・・。。。アプローチまで見てみれば何かわかるかな・・・
バリエーション
ユーザー受け入れテスト
- 意図されているユーザーが本番環境または（模擬の）運用環境にて、想定しているシステムの使用方法と合致していることを確認することに焦点をあてている。
- 主目的は、システムの使用において、システムがユーザーニーズに合致し、要件を満たし、最小限の困難さ、コスト、リスクでビジネスプロセスを実行できるという信頼を積み重ねることである。
「信頼を積み重ねること」。また1出たよ。
運用受け入れテスト
- 運用担当者またはシステムアドミニストレーターが行うシステムの受け入れテストは、（模擬）本番環境で行うのが一般的である。運用面に焦点を置いている。
- 主目的は、運用担当者またはシステムアドミニストレーターが、運用環境で（例外的な状況または困難な状況であっても）ユーザー向けにシステムを適切な稼動状態に維持できるという信頼を積み重ねることである。
こっちも「信頼を積み重ねること」か。
契約による受け入れテストおよび規制による受け入れテスト
- カスタムメイドのソフトウェアを開発する場合に、契約書に記述した受け入れ基準に従って行う。受け入れ基準は、契約時に当事者間で合意している。契約による受け入れテストは、ユーザーまたは独立したテスト担当者が行うことが多い。
- 規制による受け入れテストでは、政府、法律、安全の基準などに合致しているかを確認する。規制による受け入れテストは、ユーザーまたは独立したテスト担当者が行うことが多いが、規制機関が結果を証明または監査する場合もある。
- 契約による受け入れテストおよび規制による受け入れテストの主目的は、契約または規制に準拠しているという信頼を積み重ねることである。
こっちも「信頼を積み重ねること」。
アルファテストおよびベータテスト
- 市販ソフトウェア（COTS）の開発担当者がソフトウェアプロダクトを市場へリリースする前に、潜在的または既存のユーザー、顧客、および／またはシステムの運用者からフィードバックを受けるために行う。
- アルファテストおよびベータテストの目的の 1 つは、潜在的または既存の顧客、および／またはシステムの運用担当者が日常的な状況において、運用環境でシステムを使う上での困難、コストおよびリスクが最小限で目的を達成できるという信頼を積み重ねることである。また、システムが使われる環境（特に、開発チームでは再現できない状況や環境）での欠陥を検出することも目的の 1 つである。
最後まで丁寧に「信頼を積み重ねること」。
アプローチと責務
受け入れテストは、顧客、ビジネスユーザー、プロダクトオーナー、またはシステムの運用担当者の責任で行われる。
他のステークホルダーも関与することがある。
利用者側は何をテストしていいか分からないのに、テストしろ！みたいに言われているようで、なんかいびつさを感じるんだけど、考えすぎ？
「自分が使いたい機能が、使いたいように使えるか？」が検証できればいいだけだから、そんなに難しく考えなくていいのかなぁ？
でも、網羅的にケースが出せるかというと、それをユーザー主体でやるのは難しいのでは？そこそこサポートが必要な気がするんだけどなぁ。
そこらへんの話はどっかに出てくるのかな・・・
まぁ、ここの定義上は「責任で行われる」だから、それ以外の人が関与しちゃいけないとかではないんだけどな。
受け入れテストは、シーケンシャル開発ライフサイクルでは最後のテストレベルであるが、以下のようなタイミングでも実行することがある。
いろいろ具体例書いてあったけど、ここでは割愛。「必ずしも最後じゃない」ってことだけ抑えておけば良いっしょ。
2.3 テストタイプ
テストタイプは、以下に列挙する特定のテストの目的から見たソフトウェアシステム（あるいはシステムの一部分）の特性をテストするための活動を束ねたものである。
はい。
- 機能の品質特性、例えば完全、正確および適切であることなどを評価する。
- 非機能の品質特性、例えば信頼性、性能効率性、セキュリティ、互換性、使用性などを評価する。
- コンポーネントまたはシステムの、構造またはアーキテクチャーが正しく完全で仕様通りであることを評価する。
- 欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを探す（リグレッションテスト）。
個々の話は個別のテストタイプの中で触れられそうだから、「へー。ふーん。」くらいで済ましておこう。
K2 機能テスト、非機能テスト、ホワイトボックステストを比較する。
【疑問】ホワイトボックスはあるのに、ブラックボックスは無いのはなぜ？？？
→ 【自分なりの回答】ブラックボックステストは、テスト技法としての話。ホワイトボックステストは、テスト技法と、テストタイプ両方で同じ用語が存在する？意味合いはほぼ同じっぽいが。
◆機能テスト◆
システムの機能テストでは、システムが実行する機能を評価する。機能要件は、ビジネス要件仕様、エピック、ユーザーストーリー、ユースケース、機能仕様などの作業成果物で記述してあったり、まったく文書化していない場合もあったりする。機能とはシステムが「何を」すべきかである。
「まったく文書化していない場合もあったりする」
難しいというか、問題になりがちなのはここだよなー。。。
「機能とはシステムが「何を」すべきかである。」
ここの定義は「コンポーネントが」ではなく「システムが」。
コンポーネントテストで考えると、「コンポーネント単独の振る舞いとして正しいか？」という表現よりも「システム全体からみて、そのコンポーネント単独の振る舞いは正しいか？」みたいな表現で考えるのが適切なんだろうな。
機能テストは、すべてのテストレベル（例えば、コンポーネント仕様を基にしたコンポーネントテスト）で行うべきである。各テストレベルで焦点は異なる（2.2 節を参照）。
うぃっす。
機能テストはソフトウェアの振る舞いが関心事であり、コンポーネントまたはシステムの機能のためのテスト条件やテストケースをブラックボックス技法で導出できる（4.2 節を参照）。
それな。「コンポーネントの場合、ホワイトボックスじゃないと導出できない！」みたいな考え方をしてる人がたまにいるけど、そうだとするなら、そのコンポーネントの内部構造が間違っているのでは？って思ってる。（仕様書に書かれてない裏機能みたいなのを実装したいなら、そういうこともあるかもしれんが、普通そういうケースは殆ど無いだろうよ。）
機能テストは、機能カバレッジを用いてテストが十分かを計測できる。機能カバレッジは、テストした機能要素の種類の範囲を示し、カバーした要素の種類の割合で表す。例えば、テストと機能要件の間のトレーサビリティを使用して、テストで対処した要件の割合を計算し、テストが十分でないところを識別できる。
ほほーん。「機能カバレッジ」ってやつの具体例が知りたいな。
何ができていたら、この機能が完成と呼べるのか？をちゃんと定義しようって感じかな？
スクラムとかなら、 Acceptance Criteria をすごく具体的にブレイクダウンしよう！みたいな感じか？
Q「機能カバレッジについて。機能をどこまで評価するかを設計者の能力に大きく依存。客観的な評価ができない。」
A「ハードでメモリアクセスする場合。メモリアクセスをチェックする。作業するからチェックする。コードカバレッジで取れるものは取れる。取れないものは機能カバレッジで取る。設計手順で考えていって、イレギュラーな部分を機能カバレッジで。言ってみればレビュー。」
SWESTレポート - 「ソフトのテストとハードの検証。なにが違って、なにが一緒？（チュートリアル編）」
「イレギュラーな部分を機能カバレッジで。」
まぁ、「こういう使い方もある」くらいで認識しておこうかな。コスパの問題で、どこまでブレイクダウンするかはポイントになりそうだしなぁ。
そういえば、品質とコストってどう考えるのが良いんだろうか・・・。
テストマネージャとかに書いてあるのかな？
◆非機能テスト◆
システムの非機能テストでは、システムやソフトウェアの使用性、性能効率性、セキュリティといった特性を評価する。
ソフトウェアプロダクトの品質特性の分類については、ISO/IEC 25010 を参照されたい。非機能テストは、システムが「どのように上手く」振る舞うかをテストする。
はい。
一般的に誤解されているが、非機能テストはすべてのテストレベルで行うことができる。
そして可能な限り早期に行うべきである。非機能欠陥の検出が遅れることは、プロジェクトの成功にとってきわめて大きな危険となりえる。
わかる。部分的に性能テストをやることを考えていかないといかんよなぁ。
流量整理したら、なんとなく見えてくるものがあるのでは？
Javaのスレッド数とかメモリとかはどうやるのが良いかなぁ・・・
なんかそこらへんも含めて簡単に性能テストできるツール作ってみようかな・・・
なんか作れそうな気がしてきた。
（他にも作りたいものいっぱいあるから、いつになるかわからんけど）
非機能テストではテスト条件やテストケースを抽出するために、ブラックボックス技法（4.2 節を参照）を使う場合がある。
例えば、境界値分析で性能テストのストレス条件を定義できる。
「限界値を定義するためにブラックボックス技法が使える」ってことだと理解した。
非機能テストは、非機能カバレッジを用いてテストが十分かを計測できる。
非機能カバレッジは、テストした非機能要素の種類の範囲を示し、カバーした要素の種類の割合で表す。
例えば、モバイルアプリケーションの場合に、テストとサポート対象デバイスの間のトレーサビリティを使用して、互換性テストで対処したデバイスの割合を計算し、テストが十分でないところを識別できる。
なんでもカバレッジだなぁ。
この場合、テスト対象とするデバイスしか挙げないだろうから、最終ゴールは100%以外無いんだろうな。
「テストが十分か不十分か」ってより、「テストやったかどうか」しか表現できないのでは？？？
進捗指標になるだけな気がするけど、そういう理解であってるのだろうか。
非機能テストの詳細については、『ISTQB テスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト』、『ISTQB テスト技術者資格制度 Advanced Level シラバス 日本語版 テクニカルテストアナリスト』、『 ISTQB-SEC Advanced Level Security Tester Syllabus』、およびその他の ISTQB スペシャリストモジュールを参照されたい。
日本語訳もあるのは嬉しいなぁ。
◆ホワイトボックステスト◆
ホワイトボックステストは、システムの内部構造や実装に基づいてテストを導出する。内部構造には、コード、アーキテクチャー、ワークフロー、そして／またはシステム内のデータフローなどがある（4.3節を参照）。
アーキテクチャーやワークフローもか。
よく考えたらワークフロー系のテストでも、自然とやってたな。
コンポーネントテストレベルでは、（中略）カバレッジを計測できる。
コンポーネント統合テストレベルでは、コンポーネント間のインターフェースなどシステムのアーキテクチャーに基づき、構造カバレッジはテストで実行済みのインターフェースの割合で計測できる。
コンポーネント統合テストレベルでは、テスト済みの割合ってことかな。
テストの進捗を見るという意味合いでしか測ったこと無かったなぁ。
「カバレッジ」って言われると、進捗というより品質指標的に使うイメージがあった。
けど、考えてみたら、統合テストレベルのカバレッジだって、品質の指標とも捉えることはできそうだな。
K2 確認テストとリグレッションテストの目的を比較する。
◆変更部分のテスト◆
欠陥を修正、または機能の新規追加や変更といったシステムに対する変更をした場合、元の欠陥が修正されたこと、機能が正しく実装されていること、または予測しなかった悪い影響が発生していないことを確認するためにテストをしなければならない。
わかる。
- 確認テスト：欠陥を修正したら、その欠陥により不合格となった全テストケースを新しいソフトウェアバージョンで再実行しなければならない。(中略)確認テストの目的は、欠陥が確実に修正されたことの確認である。
- リグレッションテスト：修正および変更でコードの一部に対して行った変更が、同一コンポーネント、同一システム内の他コンポーネント、または他システムの振る舞いに意図せず影響を及ぼす場合がある。（龍略）そのような意図しない副作用をリグレッションと呼ぶ。リグレッションテストでは、テストを実行して、そのような意図しない副作用を検出する。
わかる。
確認テストとリグレッションテストは、すべてのテストレベルで行う。
確認テストは毎回やってるけど、PJによっては、リグレッションは時間かかるからある程度まとめてやることもあるなぁ。
これは「すべてのテストレベルで行う」と言っているだけで、「毎回行う」とまでは言ってないから、良いのか。
特にイテレーティブ開発ライフサイクルやインクリメンタル開発ライフサイクル（例えば、アジャイル）では、機能追加、既存の機能への変更およびコードリファクタリングが頻繁なため、変更に関連したテストも常に必要となる。システムは本質的に進化するものであるため、確認テストとリグレッションテストはきわめて重要である。個々の開発対象（例えば、デバイス）が頻繁に更新または置き換えられるIoT システムでは、このことは特に明白である。
そっすね。
リグレッションテストスイートは何度も実行し、通常は少しずつ拡充をしていく。そのため自動化による効果が非常に大きい。リグレッションテストの自動化はプロジェクトの早期に開始すべきである（第6 章を参照）。
自動化してるしてる。全部じゃないけど。
K1 あらゆるテストレベルで機能テスト、非機能テスト、ホワイトボックステストが行われることを認識する。
◆テストタイプとテストレベル◆
すべてのテストタイプは、すべてのテストレベルで実行できる。銀行システムを使って、すべてのテストタイプについて、各テストレベルで行うことの例を説明する。
銀行システムを使った具体例はここでは割愛しておく。シラバス見てくださいー。
本節では、全テストタイプにおける各テストレベルの適用例を示したが、すべてのソフトウェアに対して、各テストレベルで示した全テストタイプを適用する必要はない。
ただし、各テストレベルで適用可能なテストタイプを行うことが重要である。
中でもテストタイプが必要となる最も早いテストレベルで行うことは重要である。
テストは早いほうが良い。
信頼を積み重ねるのが目的なので、各レベルでやったほうがよい。
2.4 メンテナンステスト
本番環境にデプロイしたソフトウェアやシステムは、メンテナンスを行う必要がある。
本番リリース済みのソフトウェアやシステムには、運用で見つかった欠陥の修正、新機能の追加、またはリリース済みの機能の削除や変更を行うために、さまざまな種類の変更が発生する。
コンポーネントやシステムを維持している間は、性能効率性、互換性、信頼性、セキュリティ、移植性などの非機能的な品質の特性を確保および改善するためにもメンテナンスは必要である。
わかる。
メンテナンスの一環として変更が発生した場合は、変更が正しく適用されていることを評価し、システムの変更していない部分（システムの大部分を占める）での副作用（例えば、リグレッション）を確認するために、メンテナンステストを行うべきである。
メンテナンステストは、システムの変更に焦点をあてるが、変更の影響を受けた可能性のある変更なしの部分に対しても同様に扱う。
メンテナンスは、計画的なリリースと非計画的なリリース（ホットフィックス）の両方の一環として行われる。
リグレッションテストとメンテナンステストは別モノ？？？
そもそも「メンテナンステスト」ってテストレベルに属するもの？テストフェーズに属するもの？テストタイプに属するもの？？何者？
もはやそういう定義から独立した存在？う～ん・・・
「用語集」にも定義が無いぞ・・・
メンテナンスリリースでは、その範囲に基づいて、複数のテストレベルでさまざまなテストタイプを使用してメンテナンステストを行う。
メンテナンステストの範囲は以下の要因で決定する。
- 変更のリスクの度合い。例えば、ソフトウェアの変更領域が他のコンポーネントまたはシステムとコミュニケーションする度合い
- 既存システムの規模
- 変更の規模
「メンテナンスリリース」！急に新しい用語出さないでおくれ・・・
調べても出てこないし・・・
ひとまず、保守フェーズにおける「システムに対する変更」と捉えるか。
ひとまず、メンテナンステストは、テストレベルのくくりでもテストタイプのくくりでも無いのか。
広く「保守フェーズでのテスト」くらいの解釈にしておくか・・・
K2 メンテナンステストを引き起こすものを要約する。
計画的なリリースと非計画的なリリースの両方に対して、さまざまな理由によりソフトウェアのメンテナンスとメンテナンステストが必要になる。
ここでは、メンテナンスが必要となる理由を以下のように分類する。
- 変更作業：計画（リリース計画など）に従った拡張、修正や緊急変更、運用環境の変更（計画的な OS の変更やデータベースのアップグレードなど）、COTS ソフトウェアのアップグレード、欠陥や脆弱性に対するパッチ。
- 移行作業：別のプラットフォームへの移行。この場合、新しい環境や変更になったソフトウェアの運用テストを行う。また、別のアプリケーションからのデータをメンテナンス対象のシステムに移行する場合にはデータ変換のテストを行う。
- 廃棄作業：アプリケーションの廃棄。
メンテナンステストが必要となる理由ではなく、メンテナンスが必要となる理由か。
最初、「メンテナンステストが必要となる理由」として読んだから謎が多かった。
アプリケーションやシステムを廃棄する際に長期間のデータ保有を要求されている場合、データの移行作業や保管作業のテスト、長期間のデータ保管後のリストア/抽出の手順のテストを行う必要がある。
また、残りのサービスが引き続き動作することを確認するためのリグレッションテストも行う必要がある。
「長期間のデータ保管後のリストア/抽出の手順のテスト」って特別やったことないなぁ、とか思ったけど、
長期間だろうが短期間だろうが同じ手順で実現しているからできているのか。
とはいえ、少なくとも観点としては持っておいた方がいいなぁ。
IoT システムでのメンテナンステストは、まったく新しいモノまたは変更したモノ（例えば、ハードウェアデバイスやソフトウェアサービス）をシステム全体に導入したときに行う。
このようなシステムのメンテナンステストは、さまざまなレベル（例えば、ネットワークレベルやアプリケーションレベル）での統合テストを重要視し、個人データに関連する場合はセキュリティを特に重要視する。
IoTだから特別なんやで！って言ってる風だけど、どんな形態のシステムでも同じでは・・・？
K2 メンテナンステストにおける影響度分析の役割を説明する。
影響度分析はメンテナンスリリース向けに行った変更を評価し、変更により意図した結果、変更により予想される副作用、および変更が影響するシステムの領域を識別する。
影響度分析は、既存のテストに対する修正が必要な箇所も識別する。
修正が必要な既存のテストを更新した後に、副作用および影響を受ける領域に対してリグレッションテストを行う必要がある。
影響度分析は、他領域への潜在的な影響度に基づいて変更を行うか判断するため、変更を行う前に実施することもある。
基本、変更を行う前に実施すると思ってたけど、「することもある」ってどういうこっちゃね。
影響度分析は、以下の場合に難しくなる。
- 仕様（例えば、ビジネス要件、ユーザーストーリー、アーキテクチャー）が最新版でない、または存在しない。
- テストケースが文書化されていない、または最新版でない。
- テストとテストベースとの間の双方向のトレーサビリティが維持されていない。
- ツールによる影響度分析のためのサポートが貧弱であるか、まったくない。
- ドメインおよび／またはシステムの知識を持つ担当者がいない。
- 開発時にソフトウェアの保守性が考慮されていない。
わかる。
さいごに
今回も100minどころじゃないくらい時間かかっている・・・
興味が横道にそれすぎている・・・その分理解も深まってる気はするけど・・・
まだまだ先は長い・・・
現場にすぐにでも適用したいこと
（なんとなくゴールイメージが沸いているもの）
- テストタイプ/テストレベルという枠組みを用いて実際のテスト活動を整理してみる。（理解を深めるため）
継続して考え続けたい
（ゴールイメージがそこまで沸いてないもの）
- 「受け入れテスト」ってどうやるのが良いのか？
- ケースのバリエーションってユーザーで出し切れるのか？（そんなイメージは無い）
- 「テストレベル：コンポーネントテスト」「テストレベル：コンポーネント統合テスト」の組み合わせ
- コンポーネントの粒度をどう捉えるが良いか？
以上です。
-
テスト自体の目的である「テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。」について、「テストを学びたくてJSTQBのFLシラバスを読んでみた〜その1 テストの基礎〜」の時もモヤモヤしてたので。 ↩