JSTQBFL2章 まとめ
JSTQB FL2章を読みました。
シラバスの文章が長いので引用して大事だと思うところ、テス友で出題された部分を太字にしてまとめてみます。
🐰JSTQBFL1章 まとめ
🐱JSTQBFL2章 まとめ
🦊JSTQBFL3章 まとめ
🐶JSTQBFL4章 まとめ
🐧JSTQBFL5章 まとめ
🐷JSTQBFL6章 まとめ
■シラバス内容抽出/解釈
✔ ソフトウェア開発ライフサイクルモデル
ソフトウェア開発ライフサイクルモデルには多くの種類があり、モデルが異なれば、テストに対するアプローチも異なる。
📝ソフトウェア開発ライフサイクルモデル（SDLC）
新しいソフトウェアプロダクトが必要であるという決定に始まり、そのプロダクトが使われなくなったときに終わる期間のこと
プロダクトのリリースとサポートに必要な一連のステップのこと
✔ ソフトウェア開発とソフトウェアテスト
早期テストのテスト原則に従い、どのようなソフトウェア開発ライフサイクルモデルであるかに関係なく、テスト活動はライフサイクルの早い段階に開始すべきである。
■ シーケンシャル開発モデル
・ソフトウェア開発プロセスを順次実行する活動。
※シーケンシャル ＝ 順次的な、逐次的な、連続的な、一連の
・開発プロセスのあらゆるフェーズが直前のフェーズの完了とともに始まる。
・理論的にはフ ェーズが重なることはないが、実際には、後続のフェーズからフィードバックを早期に行うのが効果的。
・フィーチャーが完全に揃ったソフトウェアを提供するが、ステークホ ルダーやユーザーが利用できるまでには、典型的に数か月から数年を要する。
シーケンシャル開発モデルの例2つ↓
ウォーターフォールモデル
開発活動（要件分析、設計、コーディング、テストなど） は、逐次完了する。テスト活動はその他の開発活動がすべて完了した後に実行する。
V 字モデル
・開発プロセス全体にテストプロセスを統合しており、早期テストの原則を実装している。
・各開発フェーズにテストレベルが対応している。
・テスト実行は、関連付けられているテストレベルごとに順次進めていくが、重複することもある。
■ インクリメンタル開発
・システムを分割し、分割単位ごとに要件の確定、設計、構築、テストを行 う。
・ソフトウェアのフィーチャーが徐々に増加していく。
📝インクリメンタル (Incremental)
増加の、増分の、徐々に増加する、漸増の
■ イテレーティブ開発モデル
・グループにしたフィーチャー群を、一連のサイクル（固 定された期間）の中で一緒に仕様化、設計、構築、テストする。
・各イテレーションでは、動作するソフトウェアが提供される。
・提供されるソフトウェアは、段階的にフィーチャーを追加して成長させていく。
📝イテレーティブ (Iterative)
反復する、繰り返す
こうイメージすると覚えやすい💡
インクリメンタル開発：
完成するまで価値がない。中間成果物において価値が認められない作り方がインクリメンタル開発。
イテレーティブ開発：
最初から価値を作る。シンプルで最低限の機能しかないが、はじめから利用者の価値を実現するのがイテレーティブ開発。そして、毎回のイテレーションで性能や操作性を高めて洗練させていく。
ラショナル統一プロセス（RUP）：各イテレーションは他と比べて長期（例えば 2～3 か月）に なる傾向にあり、フィーチャー増分は、関連するフィーチャーで構成するいくつかのグループな ど、期間に対応して大きくなる傾向にある。
スクラム：各イテレーションは他と比べて短期（例えば、数時間、数日、数週間）になる傾向に あり、フィーチャーの増分は、わずかな機能強化、および/またはいくつかの新しいフィーチャ ーなど、小さくなる傾向にある。
カンバン：イテレーションの期間の長さが固定されているかどうかに関係なく実装できるので、 完了時に単一の機能強化やフィーチャーをリリースすることも、複数のフィーチャーをまとめて一括してリリースすることもできる。
スパイラル：増分を試行しながら追加する。増分は、後続の開発作業で大幅に作り直すことも破棄することもある。
※システムが成長するにつれてリグレッションテストの重要性は増大する。
✔ 状況に応じたソフトウェア開発ライフサイクルモデル
ソフトウェア開発ライフサイクルモデルは、プロジェクトやプロダクトの特性に応じて選択および調整する必要がある。
プロジェクトの状況によっては、テストレベルおよび/またはテスト活動を組み合わせたり再編成したりすることが必要である。
★例えば、市販ソフトウェア（COTS）プロダクトを大規模なシステムに組み込む場合、システム統合テストレベルと受け入れテストレベルで相互運用性テストを購入者が実施する必要がある。
＋
ソフトウェア開発ライフサイクルモデルを組み合わせる場合がある。
★例えば、バックエンドシステムの統合のための開発とテストに V 字モデル、フロントエンドのユーザーインターフェース（UI）と機能の開発とテストにアジャイル開発モデルを使用する場合がある。
✔ テストレベル
テストレベルとは、系統的にまとめ、マネジメントしていくテストの活動のグループのこと。
【テストレベルの種類】
コンポーネントテスト
統合テスト
システムテスト
受け入れテスト
テストレベルそれぞれに適切なテスト環境が必要である。
例えば、
・コンポーネントテスト：開発担当者は彼ら所有の開発環境を使用するのが一般的
・受け入れテスト：本番環境に類似 したテスト環境が理想
■ コンポーネントテスト
コンポーネントテスト（ユニットテスト、モジュールテスト）は、個別にテスト可能なコンポーネントに焦点をあてる。
【目的】
リスクの軽減
コンポーネントの機能的/非機能的振る舞いが設計および仕様通りであることの検証
コンポーネント品質に対する信頼の積み上げ
コンポーネントに存在する欠陥の検出
欠陥がより高いテストレベルまで見逃されることの防止
【特徴】
特にコード変更が継続して行われるインクリメンタル開発モデルやイテレーティブ開発モデル（アジャイルなど）では、コンポーネントテストのリグレッションテストを自動化して、変更が既存のコンポー ネントを破壊していないという信頼を積み重ねていくことが重要。
ソフトウェア開発ライフサイクルモデルやシステムの特性により、システムの他の部分と切り離したテストが可能。
➡ モックオブジェクト、サービス仮想化、ハーネス、スタブ、ドライバーなどを使う。
📝モックオブジェクト
テストのときに実際のオブジェクトの動作をシュミレートしてくれるオブジェクトのこと
📝ハーネス
テスト実行用のソフトウェアのこと。テスト対象モジュールを呼び出し、テストケースを適用して、実行を制御・監視し、テスト結果のレポートを行う。テストドライバやテストスタブなどで構成される
📝スタブ
テスト用に用意した、まだ完成していない機能の代わりとなる部品のこと
（テスト対象から呼び出される代用品）
📝ドライバー
テスト用に用意した、まだ完成していない機能の代わりとなる部品のこと
（テスト対象を呼び出す代用品）
コンポーネントテストは、機能性（例：計算の正しさ）、非機能特性（例：メモリリークの検出）、構造の属性（例：デシジョンテスト）も含む。
検出した欠陥は、形式に沿った欠陥マネジメントを行わず、見つけたらすぐに修正するのが一般的であ る。
【アプローチと責務】
コンポーネントテストはコードを開発した開発担当者が行うことが一般的であるが、そうでない場合、少なくともテスト対象のコードにアクセスできる必要がある。
開発担当者は欠陥の検出と修正を行って、開発したコンポーネントを差し替えることができる。
コンポーネント用のコードを記述した後で、テストを記述し実行することが多い。
ただし、特にアジャイル開発では、アプリケーションコードを記述する前に、自動化されたコンポーネントのテストケースを記述する場合がある。
高度にイテレーティブであるテスト駆動開発（TDD）は、テストファーストアプローチの一例。
テスト駆動開発は、自動化されたテストケースの開発、小規模なコードの構築と統合、コンポーネントテストの実行、問題の修正、コードのリファクタリングで構成される。
このプロセスはコンポーネントを完全に構築し、すべてのコンポーネント テストが合格となるまで継続する。
エクストリームプログラミング（XP）がオリジナルであるが、アジャイル開発の他のアプローチおよびシーケンシャルライフサイクルにも普及している。
📝テスト駆動開発（TDD）
プログラム開発手法の一種。
プログラムに必要な各機能について、最初にテストを書き（これを『テストファースト』と言う）、そのテストが動作する必要最低限な実装をとりあえず行なった後、コードを洗練させる、という短い工程を繰り返すスタイルのこと
📝エクストリームプログラミング（XP）
迅速で柔軟性の高いソフトウェア開発手法の一つ。
プログラミングを始めた後でも変更や修正、仕様の明確化などが行われることを前提として、小規模な設計、実装、テストを何度も繰り返して段階的に完成度を高めていく反復型開発を採用している。
■ 統合テスト
コンポーネントまたはシステム間の相互処理に焦点をあてる。
【目的】
リスクの軽減
インターフェースの機能的/非機能的振る舞いが設計および仕様通りであることの検証
インターフェース品質に対する信頼の積み上げ
欠陥の検出（インターフェース自体、コンポーネントに内在、またはシステムに内在）
欠陥がより高いテストレベルまで見逃されることの防止
【特徴】
リグレッションテストを自動化する場合があり、自動化したリグレッションテストにより、変更が既存のインターフェース、コンポーネント、システムを破壊しないという信頼を提供できる。
■ コンポーネント統合テスト
統合するコンポーネント間の相互処理とインターフェースに焦点 をあててテストする。
コンポーネントテストの後に実施し、自動化するのが一般的。
イテレーティブ開発およびインクリメンタル開発では、継続的インテグレーションプロセスの一環として行うことが一般的。
■ システム統合テスト
システム、パッケージ、マイクロサービス間の相互処理とインターフェ ースに焦点をあててテストする。
システムテストの後、または実行中のシステムテスト活動と並列に行う。（シーケンシャル開発とイテレーティブ/インクリメンタル開発の両方）
【アプローチと責務】
コンポーネント統合テストとシステム統合テストは、統合だけに集中すべきである。
テストタイプのうち、機能テスト、非機能テスト、構造テストは統合テストで行うことができる。
コンポーネント統合テストは開発担当者が実行するのが一般的。
システム統合テストはテスト担 当者が実行するのが一般的である。
※システム統合テストを実行するテスト担当者はシステムアーキテクチャーを理解すべきであり、統合計画の作成に関与すべきである。
📝システムアーキテクチャー
システムに求められている目標を達成するための効率の良い機能や
データのやり取りの仕組みの枠組みのこと
システムの設計を実装するための工程などが記述されている
欠陥の特定を容易にし、早期に検出するために、統合は「ビッグバン（すべてのコンポーネントやシステムに対して一度に実施）」ではなく、インクリメンタル（同時には少数のコンポーネントまたはシステムを追加）するのが普通である。
統合の範囲が大きくなるほど、欠陥を特定のコンポーネントまたはシステムに絞り込むことが難しくなる。これによりリスクが増え、トラブルシューティングの時間が増大する。
上記により、ソフトウェアをコンポーネントごとに統合する継続的インテグレーションが普及してきている。
リグレッションテストの自動化を複数のテストレベルで行うことが理想。
■ システムテスト
システムが実行するエンドツーエンドのタスクと、タスクの実行時にシステムが示す非機能的振る舞いといったシステムやプロダクト全体の振る舞いや能力に焦点をあてる。
📝エンドツーエンド
「端から端まで」を意味する英語であり、略してE2E（イーツーイー）と呼ばれることがある。
通信を行う二者を結ぶ経路全体、もしくはその両端を示す。
【目的】
リスクの軽減
システムの機能的/非機能的振る舞いが設計および仕様通りであることの検証
システムが完成し、期待通りに動作することの妥当性確認
システムの全体的な品質に対する信頼の積み上げ
欠陥の検出
欠陥がより高いテストレベルまたは運用環境まで見逃されることの防止
【特徴】
システムテストのリグレッションテストを自動化する場合があり、自動化したリグレッションテストにより変更が既存のフィーチャーやエンドツーエンドの能力を破壊していないという信頼 を提供できる。
ステークホルダーは、システムテストの情報に基づいてリリースに関する意志決定を行うことが多い。
法的もしくは規制的要件、または標準を満たすことを確認する場合もある。
テスト環境は、最終的なターゲットまたは本番環境に準じることが理想。
【アプローチと責務】
対象となるシステムにとって最適なテスト技法を使用する。
ex) デシジョンテーブルを使用して、機能的な振る舞いがビジネスルールで規定されている通りであることを検証する。独立したテストチームが仕様を頼りにして行うことが多い。
仕様の欠陥（ユーザーストーリーの欠落、ビジネス要件の正しくない記述など）は、システムの期待される振る舞いに関する正しい理解の欠落や誤解につながる。
テスト担当者がユーザーストーリーを洗練する活動およびレビューなどの静的テストの活動に早期から関与することで、時間の浪費や欠陥検出効率の低下を削減できる。
■ 受け入れテスト
システムテストと同様、システムやプロダクト全体の振る舞いや能力に焦点 をあてる。
【目的】
システムの全体的な品質に対する信頼の積み上げ
システムが完成し、期待通りに動作することの妥当性確認
システムの機能的/非機能的振る舞いが仕様通りであることの検証
【特徴】
受け入れテストからの情報に基づいて、システムが導入に向けて準備できているかどうか、および顧客 （エンドユーザー）が使用できるかを評価できる。
受け入れテストで欠陥が見つかることはあるが、欠陥を見つけることは目的ではない。
とても多くの欠陥が受け入れテスト時に検出されるような事態は、 重要なプロジェクトリスクと見なすことができる。
法的または規制的要件または 標準を満たすことを確認する場合もある。
■ ユーザー受け入れテスト
意図されているユーザーが本番環境または（模擬の）運用環境 にて、想定しているシステムの使用方法と合致していることを確認する
主目的は、システムの使用において、システムがユーザーニーズに合致し、要件 を満たし、最小限の困難さ、コスト、リスクでビジネスプロセスを実行できるという信頼を積み重ねることである。
■ 運用受け入れテスト
運用担当者またはシステムアドミニストレーター（システム管理者）が行う。
（模擬）本番環境で行うのが一般的。
以下のようなものを含む運用面に焦点を置いている。
➡バックアップ/リストアのテスト
➡インストール/アンインストール
➡アップグレード
➡ユーザーマネジメント
➡メンテナンスタスク
➡データのロードと移行のタスク
➡セキュリティの脆弱性のチェック
➡性能テスト主目的は、運用担当者またはシステムアドミニストレーターが、運用環境で（例外的な状況または困難な状況であっても）ユーザー向けにシステムを適切な稼動状態に維持できるという信頼を積み重ねることである。
■ 契約による受け入れテストおよび規制による受け入れテスト
契約による受け入れテスト：
・カスタムメイドのソフトウェアを開発する場合に、契約書に記述した受 け入れ基準に従って行う。
・ユーザーまたは独立したテスト担当者が行うことが多い。規制による受け入れテスト：
・政府、法律、安全の基準などに合致しているかを確認する。
・ユーザーまたは独立したテスト担当者が行うことが多い。
・規制機関が結果を証明または監査する場合もある。主目的は、契約または規制に準拠しているという信頼を積み重ねることである。
■ アルファテストおよびベータテスト
市販ソフトウェア（COTS）の開発担当者がソフトウェアプロダクトを市場へリリースする前に、潜在的または既存のユーザー、顧客、および/またはシステムの運用者からフィードバックを受けるために行う。
目的の1つは、潜在的または既存の顧客、および/またはシステムの運用担当者が日常的な状況において、運用環境でシステムを使う上での困難、コストおよびリスクが最小限で目的を達成できるという信頼を積み重ねることである。
システムが使われる環境（特に、開発チームでは再現できない状況や環境）での欠陥を検出することも目的の1つ。
■ アルファテスト
開発中のソフトウェアやハードウェア、ネットサービスなどを実際に利用してみるテストのこと。（実際に稼働はするものの、まだ仕様や機能が完全には固まっておらず、開発が最終段階に達していない製品を利用して行われるテストである。）
開発組織内（開発環境）にて、開発チームの代わりに潜在的または既存の顧客、および/またはシステムの運用者もしくは独立したテストチームが行う。
■ ベータテスト
発売あるいは公開直前のほぼ完成したもの（ベータ版）を利用者に提供し、実際に使用してもらって性能や機能、使い勝手などを評価してもらうテストのこと。
潜在的または既存の顧客、および/またはシステムの運用者が彼ら自身の作業場所（開発環境以外）で行う。
ベータテストはアルファテストの後に行うことも、アルファテストなしに行うこともある。
【アプローチと責務】
顧客、ビジネスユーザー、プロダクトオーナー、またはシステムの運用担当者の責任で行われる。他のステークホルダーも関与することがある。
シーケンシャル開発ライフサイクルでは最後のテストレベルであるが、以下のよう なタイミングでも実行することがある。
➡ COTSソフトウェアプロダクトの受け入れテストは、インストール時または統合時に行う場合がある。
➡ 機能を新たに強化したときの受け入れテストは、システムテストの前に行うことがある。イテレーティブ開発において、プロジェクトチームは、新しい機能を受け入れ基準に対して検証し、ユーザーニーズを満たすことの妥当性確認を行うために、各イテレーションの実行中および終了時にさまざまな形態の受け入れテストを利用する。
各イテレーションの最後および完了後、または一連のイテレーションの後に、アルファテストとベータテストを実行することがある。
ユーザー受け入れテスト、運用受け入れテスト、契約による受け入れテストおよび規制による受け入れテストも、各イテレーションの最後や完了後、または一連のイテレーションの後に実行する場合がある。
✔ テストタイプ
テストタイプとは、特定のテストの目的から見たソフトウェアシステム（あるいはシステムの一部分）の特性をテストするための活動を束ねたもの。
【特定のテストの目的】
機能の品質特性、例えば完全、正確および適切であることなどを評価する。
非機能の品質特性、例えば信頼性、性能効率性、セキュリティ、互換性、使用性などを評価する。 ★ISO/IEC25010で定義
コンポーネントまたはシステムの、構造またはアーキテクチャーが正しく完全で仕様通りであることを評価する。
欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、ソフトウ ェアや環境の変更によって意図しない振る舞いの変化が発生していないかを探す（リグレッションテスト）。
■ 機能テスト
システムの機能テストでは、システムが実行する機能を評価する。
機能とはシステムが「何を」すべきかである。
機能テストは、すべてのテストレベル（例えば、コンポーネント仕様を基にしたコンポーネントテスト）で行うべきである。
ソフトウェアの振る舞いが関心事であり、コンポーネントまたはシステムの機能のためのテスト条件やテストケースをブラックボックス技法で導出できる。
機能カバレッジを用いてテストが十分かを計測できる。
📝機能カバレッジ
テストした機能の範囲を示し、カバーした要素の種類の割合で表す
機能テストの設計および実行には、ソフトウェアが解決する特定のビジネス問題（石油・ガス業界 での地質モデリングソフトウェア）など、特別なスキルや知識が必要な場合がある。
■ 非機能テスト
システムやソフトウェアの使用性、性能効率性、セキュリティといった 特性を評価する。
システムが「どのように上手く」振る舞うかをテストする。
非機能テストはすべてのテストレベルで行うことができる。（可能な 限り早期に行うべき）
テスト条件やテストケースを抽出するために、ブラックボックス技法を使う場合がある。
ex) 境界値分析で性能テストのストレス条件を定義できる。非機能カバレッジを用いてテストが十分かを計測できる。
📝非機能カバレッジ
テストした非機能要素の種類の範囲を示し、カバーした要素の種類の割合で表す
設計や技術に特有の弱点（特定のプログラム言語に付随するセキュリティの脆弱性）や特定のユーザーに関する知識（医療施設管理システムのユーザ ーの特性）などの特別なスキルや知識が必要な場合がある。
■ ホワイトボックステスト
システムの内部構造や実装に基づいてテストを導出する。
内部構造には、コード、アーキテクチャー、ワークフロー、そして/またはシステム内のデータフローなどがある。
構造カバレッジを用いてテストが十分かを計測できる。
📝構造カバレッジ
テストで実行した構造要素の種類の範囲を示し、カバーした要素の種類の割合で表す
テストで実行済みのインターフェースの割合で計測できる
コードカバレッジ：
コンポーネントテストレベルでは、コンポーネント内のテスト済みのコードの割合に基づき、コンポーネント内の実行可能ステートメントや判定結果のうちテストを実行した割合といった、コードのさまざまな側面（カバレッジアイテム）でカバレッジを計測できる。ホワイトボックステストの設計および実行には、コードのビルド方法、データの格納方法（デ ータベースクエリーを評価するため）、カバレッジツールの使用方法、およびその計測結果を正しく解釈する方法など、特別なスキルや知識が必要な場合がある。
■ 変更関連のテスト
欠陥を修正、または機能の新規追加や変更といったシステムに対する変更をした場合、元の欠陥が修正されたこと、機能が正しく実装されていること、または予測しなかった悪い影響が発生していないことを確認するテスト。
確認テスト：
欠陥が確実に修正されたことの確認を行うリグレッションテスト：
修正および変更でコードの一部に対して行った変更が、同一コンポーネ ント、同一システム内の他コンポーネント、または他システムの振る舞いに意図せず影響を及ぼしていないかの確認を行う確認テストとリグレッションテストは、すべてのテストレベルで行う。
特にイテレーティブ開発ライフサイクルやインクリメンタル開発ライフサイクル（アジャイル）では、機能追加、既存の機能への変更およびコードリファクタリングが頻繁なため、きわめて重要である。
リグレッションテストスイートは何度も実行し、通常は少しずつ拡充をしていく。そのため自動化による効果が非常に大きい。
リグレッションテストの自動化はプロジェクトの早期に開始すべきである。
✔ テストタイプとテストレベル
すべてのテストタイプは、すべてのテストレベルで実行できる。
すべてのソフトウェアに対し て、各テストレベルで示した全テストタイプを適用する必要はない。ただし、各テストレベルで適用可能なテストタイプを行うことが重要である。中でもテストタイプが必要となる最も早いテストレベルで行うことは重要である。
✔ メンテナンス（保守）テスト
本番環境にデプロイしたソフトウェアやシステムは、メンテナンスを行う必要がある。
コンポーネントやシステムを維持している間は、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性の非機能的な品質の特性を確保および改善するためにもメンテナンスは必要である
メンテナンスの一環として変更が発生した場合は、変更が正しく適用されていることを評価し、システムの変更していない部分での副作用（リグレッション）を確認するために、メンテナンステストを行うべきである。
メンテナンスは、計画的なリリースと非計画的なリリース（ホットフィックス）の両方の一環として行われる。
メンテナンスリリースでは、その範囲に基づいて、複数のテストレベルでさまざまなテストタイプを使 用してメンテナンステストを行う。
✔ メンテナンスが必要となる理由
メンテナンスが必要となる理由を以下のように分類する。
変更作業：
計画（リリース計画など）に従った拡張、修正や緊急変更、運用環境の変更（計画的な OS の変更やデータベースのアップグレードなど）、COTS ソフトウェアのアップグレード、 欠陥や脆弱性に対するパッチ。移行作業：
別のプラットフォームへの移行。この場合、新しい環境や変更になったソフトウェア の運用テストを行う。
別のアプリケーションからのデータをメンテナンス対象のシステムに移行する場合にはデータ変換のテストを行う。
o 廃棄作業：アプリケーションの廃棄。アプリケーションやシステムを廃棄する際に長期間のデータ 保有を要求されている場合、データの移行作業や保管作業のテストが必要。
o 長期間のデータ保管後のリストア/抽出の手順のテストも必要。
o 残りのサービスが引き続き動作することを確認するためのリグレッションテストが必要。
IoT システムでのメンテナンステストは、さまざまなレベル（ネットワークレベルやアプリケーションレベル）での統合テストを重要視し、個人データに関連する場合はセキュリティを特に重要視する。
✔ メンテナンスの影響度分析
影響度分析：
メンテナンスリリース向けに行った変更を評価し、変更により意図した結果、変更により 予想される副作用、および変更が影響するシステムの領域を識別する。
既存のテストに対する修正が必要な箇所も識別する。
📝影響度分析
変更が影響するすべての成果物を識別すること。変更を達成するために必要なリソースの見積りを含む。
修正が必要な既存のテストを更新した後に、副作用および影響を 受ける領域に対してリグレッションテストを行う必要がある。
他領域への潜在的な影響度に基づいて変更を行うか判断するため、変更を行う前に実施することもある。
この記事が気に入ったらサポートをしてみませんか？