シラバス

2.1 コンテキストに応じたソフトウェア開発ライフサイクルでのテスト

2.1.1 ソフトウェア開発ライフサイクルがテストに与える影響

開発モデル	テストのアプローチと特徴
シーケンシャル開発モデル（例：ウォーターフォール）	・初期段階で要件レビューやテスト設計に参加する。・実行可能なコードが後半にできるため、動的テストは初期には実施できない。
イテレーティブ / インクリメンタル開発モデル	・各イテレーションで成果物が出るため、静的・動的テストの両方を毎回実行する可能性がある。・頻繁な提供のため、迅速なフィードバックと広範なリグレッションテストが必要。
アジャイルソフトウェア開発	・変更を想定し、文書化を軽量化する。・リグレッションテストを容易にするテスト自動化が好まれる。・手動テストは、事前設計が少なくて済む経験ベースのテスト技法が中心。

インクリメンタル開発 は、いわゆる増分開発です。一つひとつ機能を足していき、完成系を目指す手法を指します。
中間成果物に価値が認められないのが大きな特徴です。
イテレーティブ開発 は、イテレーション(=繰り返し)毎に開発目標を定め、機能を強化していきます。インクリメンタルに対して、最初から価値を作り出します。最初は最低限の機能しかありませんが、イテレーション毎に洗練されていくイメージです。

参考記事：「順番通りやる」の落とし穴 - 私がイテレーティブ開発に惚れた理由

2.1.2 ソフトウェア開発ライフサイクルとよい実践例

各開発活動に対応してテスト活動がある。そのため、すべての開発活動が品質コントロールの対象となる。

異なるテストレベル（2.2.1 項参照）には、冗長性を避けつつ適切に包括したテストをすることができる、そのレベル特有の異なる目的がある。

各テストレベルのテスト分析や設計は、対応する SDLC の開発フェーズの間に開始する。そうすることで、テストが早期テストの原則（1.3 節参照）に従うことができる。

テスト担当者は作業成果物のドラフトができたらすぐにそのレビューに関与する。そうするこ
とで、この早期テストと欠陥検出がシフトレフト戦略（2.1.5 項参照）を支援できる。

2.1.3 テストが主導するソフトウェア開発

以下のアプローチはいずれも、シフトレフトアプローチ（2.1.5 項参照）を採用することができている。

手法	特徴・アプローチ	プロセス・詳細
テスト駆動開発 (TDD)	テストケースを通じてコーディングを導く。（広範な設計の代わりとして機能）	1. テストを最初に書く 2. テストを満たすコードを書く 3. リファクタリングする
受け入れテスト駆動開発 (ATDD)	システム設計の一環として、受け入れ基準からテストを導き出す。	開発前にテストを書き、アプリケーションがそれを満たすように開発を進める。
振る舞い駆動開発 (BDD)	望ましい振る舞いを、ステークホルダーが理解しやすい自然言語（Given/When/Then形式など）で記述する。	記述されたテストケースを、実行可能なテストへ自動的に変換して使用する。

2.1.4 DevOps とテスト

テストをする観点から、DevOps の利点として、以下のようなものがある：

コード品質や、変更が既存のコードに悪影響を及ぼすかどうかに対する迅速なフィードバック

CI は、コンポーネントテストや静的解析による高品質なコードのサブミットを開発担当者に促すことで、テストにおけるシフトレフトアプローチ（2.1.5 項参照）を促進する。

安定したテスト環境の構築を容易にする CI/CD などの自動化プロセスを促進する。

非機能品質特性（性能、信頼性など）に対する観点が増える。

デリバリーパイプラインによる自動化により、手動テストを繰り返す必要性を削減する。

自動化したリグレッションテストの規模と範囲から、リグレッションのリスクを最小化する。

2.1.5 シフトレフトアプローチ

テストがより早い段階（例えば、コードが実装されるのを待たない、コンポーネントが統合されるのを待たない）で行われるべきだが、下流のテストを軽視するという話ではない。

テストにおける「シフトレフト」を実現する方法を示すよい実践例は次の通りである：

テストをする観点から仕様書をレビューする。このような仕様書のレビュー活動では、曖昧さ、不完全さ、矛盾など、潜在的な欠陥を発見することが多い。

コードを書く前にテストケースを書き、コード実装時にテストハーネスでコードを実行する。

ソースコードをコードリポジトリへサブミットする際に、付随する自動コンポーネントテスト、そして高速フィードバックが伴うようにするため、CI や CD を用いる。

動的テストの前に、または自動化したプロセスの一部として、ソースコードの静的解析を完了する。

実施可能であれば、コンポーネントテストレベルで非機能テストの実施を始める。システムが完成し、本番相当のテスト環境が利用可能になる SDLC の後半に実施される傾向がある非機能テストをこのように実施することは、シフトレフトの一形態である。

memo:
「テストをする観点から仕様書をレビューする」
これができるのは、QMエンジニアという役割になると思うが、
仕様の「曖昧さ、不完全さ、矛盾」を確認するにはドメインエキスパート並みの知識が必要になりそう。

2.1.6 ふりかえりとプロセス改善

SDLC モデルに従って、振り返りを実施しよう。

2.2 テストレベルとテストタイプ

テストレベル・・・系統的にまとめ、マネジメントしていくテスト活動のグループである。各テストレベルは、個々のコンポーネント単位から完成したシステムまで、または必要に応じてシステムオブシステムズまでの開発段階に応じたテストプロセスのインスタンス
（例：コンポーネントテスト、統合テスト、システムテスト、受け入れテスト）
テストタイプ・・・特定の品質特性に関連するテスト活動のグループであり、それらのテスト活動のほとんどは、すべてのテストレベルで実行することができる
（例：機能テスト、非機能テスト）

2.2.1 テストレベル

テストレベルの分類と特徴

テストレベル	焦点	環境・戦略・ツール	実施者・備考
コンポーネントテスト（ユニットテスト）	コンポーネント単独	・テストハーネス・ユニットテストフレームワーク・開発環境	・通常、開発担当者が行う。
コンポーネント統合テスト（ユニット統合テスト）	コンポーネント間のインターフェース、相互処理	・統合戦略に依存（ボトムアップ、トップダウン、ビッグバン）
システムテスト	システム/プロダクト全体の振る舞い（E2E、機能・非機能）	・本番相当の環境（一部の非機能特性で望ましい）・シミュレーションも使用可能	・システム仕様に関連。・独立したテストチームが実施する場合がある。
システム統合テスト	対象システムと他システム・外部サービスとのIF	・運用環境に近い適切なテスト環境が必要
受け入れテスト	妥当性確認、デプロイ準備の実証（ビジネスニーズの充足）		・想定ユーザーが実施するのが理想的。・形式：UAT、運用受入、契約/規制、α/βテスト。

テストレベルは、テスト活動の重複を避けるため、以下の代表的な属性のリストで区別する：

テスト対象

テスト目的

テストベース

欠陥、および故障

アプローチと責務

2.2.2 テストタイプ

テスト種別と特徴の要約

テスト種別	評価対象・概要	視点（キーワード）	主な目的・詳細な特徴
機能テスト	コンポーネントおよびシステムが実行する「機能」	その機能が何をすべきか (What)	【目的】以下の3点をチェックする。 1. 機能完全性 2. 機能正確性 3. 機能適切性
非機能テスト	機能特性以外の属性（品質特性）	どのようにうまく振る舞うか (How well)	【目的】非機能的な品質特性（ISO/IEC 25010）をチェックする。・性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性【特徴・注意点】・ライフサイクルの早期に開始可能な場合がある。・機能テストと同じケースを用い、制約（時間、移植性等）を評価する。・欠陥発見の遅れはプロジェクトへの重大な脅威となる。・特殊な環境（ユーザビリティラボ等）が必要な場合がある。
ブラックボックステスト	仕様書、外観を示すドキュメント	仕様に基づく	【目的】システムの動作をその仕様に照らしてチェックする。
ホワイトボックステスト	システムの実装、内部構造（コード、アーキテクチャ、データフロー等）	構造に基づく	【目的】テストによって基本的な構造を受け入れ可能なレベルまでカバー（網羅）する。

2.2.3 確認テストとリグレッションテスト

確認テスト・・・元の欠陥が正常に修正されたことを確認するテスト

リグレッションテスト・・・すでに確認テスト済みの修正を含め、変更によって悪影響が生じないことを確認する（デグレードが発生していないか）
リリースごとに増えていくので、自動化チャンス。

2.3 メンテナンス（保守）テスト

メンテナンステストのカテゴリ

修正を伴うもの
環境の変化に適応するもの
パフォーマンスや保守性を改善するもの

メンテナンステストの範囲は、典型的には次に依存する

変更のリスクの度合い
既存システムの大きさ
変更の大きさ

メンテナンステストのきっかけ

計画的な機能拡張（普通にリリースするとき。リグレッションテスト）
運用環境の更新、または移行
アプリケーションの寿命などによる廃棄