（※当記事は、2024年12月10日時点での最新版(2023V4.0.J02)のシラバスを元に作成しています。）
この記事では、JSQTB (Japan Software Testing Qualifications Board) の Foundation Level のシラバスを分かりやすくかみ砕いて解説していきます。
6記事に分けて、全ての章を解説していきますので、シラバスのなかの要点を押さえたい、ここが分からないという際に参考にしてください。
この記事では、2章 ソフトウェア開発ライフサイクル全体を通してのテスト を解説します。
その他の章の解説は下記よりご参照ください。
| 各章 | リンク |
|---|---|
| 1章 | 【JSTQB】1章 テストの基礎｜解説 |
| 2章 | 【JSTQB】2章 ソフトウェア開発ライフサイクル全体を通してのテスト｜解説 |
| 3章 | 【JSTQB】3章 静的テスト｜解説 |
| 4章 | 【JSTQB】4章 テスト分析と設計｜解説 |
| 5章 | 【JSTQB】5章 テスト活動のマネジメント｜解説 |
| 6章 | 【JSTQB】6章 テストツール｜解説 |
ソフトウェア開発ライフサイクル（SDLC）モデルは、ソフトウェア開発プロセスを時系列で整理したもので、主なモデルとして以下があります。
| 開発モデル | 実例 |
|---|---|
| シーケンシャル開発モデル | ウォーターフォール、V字モデル |
| イテレーティブ開発モデル | スパイラルモデル、プロトタイピング |
| インクリメンタル開発モデル | 統一プロセスなど |
上記以外にも、より詳細な開発手法やプラクティスで説明できるような開発モデルがあります。
受け入れテスト駆動開発(ATDD)、テスト駆動開発(TDD)、振る舞い駆動開発(BDD)、ドメイン駆動設計(DDD)、エクストリームプログラミング (XP)、フィーチャー駆動開発(FDD)、カンバン、リーンIT、スクラムなどがこれに当たります。
※太字になっているものはテスト主導の開発モデルです。(詳細は後ほど解説しています。)
テストを成功させるにはソフトウェア開発ライフサイクル（SDLC）の各種モデルに合ったテストを設計することが重要になります。
これは、テストの実施タイミング、範囲、方法、ドキュメント作成、役割分担がSDLCモデルに依存するためです。
代表的な開発モデルの例としては下記の通りです。
| シーケンシャルモデル | 初期段階では(コードがないため)、テストの計画・分析・設計までしか実行できない。 テスト実装・実行などテストの実部は後半段階に集中する。 |
| イテレーティブ/インクリメンタルモデル | 各イテレーションで頻繁なプロトタイプテストやリグレッションテストが求められる。 |
| アジャイル | 変更対応と迅速なリグレッションテストのため、テスト自動化が重視される。 そのため、手動テストのほとんどは経験ベースのテストを用いる傾向がある。 |
ソフトウェア開発ライフサイクル(SDLC)とは関係のなく実行できる、よいテストの実践条件には下記4点が挙げられます。
ATDD、TDD、BDDは類似の開発アプローチです。これらはどれもテスト計画が主導して、それに合わせたコーディングを行うものです。
受け入れテスト駆動開発(ATDD)…
受け入れ基準からUTAを作成し、それに準じたコーディングを行う開発モデル
（システム設計プロセスの一番として、受け入れ基準からテストを導き出すアプリケーションの該当部分がテストを満たすよう開発するため、受け入れテストが先にできあがっている）
テスト駆動開発(TDD)とは…
テストケースを最初に作成→テストケースからコーディングを行う開発モデル
（広範なソフトウェア設計の代わりにテストケースを置くことでコーディングを導く、テストを最初に書き、次にテストを満たすようにコードを書き、最後にテストとコードをリファクタリングする）
振る舞い駆動開発(BDD)とは…
アプリケーションの望ましい振る舞いを元に、自然言語で書いたテストケースを元にコーディングを行う開発モデル
「振る舞い」のみをテストの対象とするため、TDDよりもテスト粒度が荒いのが特徴。
テストケースはGiven/When/Thenを使用したフォーマットで表現されることが多い。
（自然言語で書くのはステークホルダーが分かりやすいため！）
すべてのアプローチにおいて、将来の適応やリファクタリングにてコード品質を確実にするため、テストケースを自動テストとして持続させることがある。
DevOpsとは…
開発と運用が協力する文化的転換を重視し、CI/CDを通じた自動化と迅速なフィードバックを実現する手法のことを指す。
テスト視点のメリット
・運用担当から改修内容に対して迅速にフィードバックを得られる
・CI/CDを用いたコンポーネントテスト・リグレッションテストの自動化によりシフトレフトアプローチが促進できる
・非機能品質特性に関する観点が増える
テスト視点の課題
・DevOpsを用いるためにデリバリーパイプラインの構築やツールの保守が必要となる
・テストの自動化により、自動テストと手動テストのバランスや導入への追加リソースが求められる
早期テストの原則のことをシフトレフトアプローチと呼ぶことがあります。
シフトレフトアプローチ…
ソフトウェアやアプリケーションの開発において、セキュリティ対策やテストを、通常より前倒しして実施する開発手法のこと。
（開発プロセスの時系列を左から右に示すことが多く、図の「右側」で行われてきたセキュリティ対策やテストの工程を「左側」に移動して実施することから、シフトレフトと呼ばれる）
シフトレフトアプローチの課題
・追加のトレーニングや労力など初期コストが増加する可能性がある
→後半のコスト削減が期待できるためステークホルダーの納得・受入れが必要
ふりかえりは、プロジェクトのイテレーション終了時やマイルストーンで実施されることが多く、成功例や改善点を共有するためにあります。これらはテスト完了レポートの一部となります。
テストはテストレベルとテストタイプによって分類することができます。
テストレベルは、開発段階に応じたテスト活動を体系的にまとめたグループで、以下の5種類があります。
| テストレベル | テスト内容 |
|---|---|
| コンポーネントテスト (ユニットテスト) | コンポーネント単位で行うテスト (開発者が実施し、特定のツールやフレームワークを使用することが多い) |
| コンポーネント統合テスト (ユニット統合テスト) | 複数コンポーネント間のインターフェースや相互処理を評価するテスト |
| システムテスト | 1つのシステム全体の機能や非機能特性を評価するテスト （プロダクトの振る舞いや能力の全般に焦点を当てる） |
| システム統合テスト | 他のシステムや外部サービスとのインターフェースを評価するテスト （運用環境に近い適切なテスト環境が必要） |
| 受け入れテスト | ユーザーのビジネスニーズやシステムの妥当性を確認するテスト （ユーザー受け入れテスト(UAT)、運用受け入れテスト、アルファ/ベータテストなど） |
テストレベル…
分かりやすい例を挙げるとV字モデル開発の場合、段階ごとに該当するテストの段階があります。それらの各フェーズに対応したテストをテストレベルと呼びます。
（※各テストに異なる目的がある。）
テストタイプは特定の品質特性に焦点を当てたテスト活動で、以下の4種類があります。
| テストタイプ | テスト内容 |
|---|---|
| 機能テスト | システムが「何をすべきか」を評価 機能完全性、正確性、適切性を確認 |
| 非機能テスト | システムが「どのように振る舞うか」を評価 性能効率性、互換性、使用性、信頼性、セキュリティなどをテスト |
| ブラックボックステスト | 仕様に基づき、外部からの挙動を評価 ※コードを見ない |
| ホワイトボックステスト | 内部構造（コードやデータフロー）を基にテストし、構造のカバー率を評価 ※コードを見る |
欠陥の修正(デバッグ)の後は確認テストやリグレッションテストを行うことが推奨されています。
| 確認テスト | 修正された欠陥が正常に修正されていることを確認するテスト (欠陥の影響範囲に応じて新しいテストケースを追加する場合もある) |
| リグレッションテスト | 修正や変更が他の部分に悪影響を及ぼしていないかを確認するテスト (影響度分析を行い、リグレッションテストの範囲を最適化) (テストケースを自動化し、CIツールを活用することを推奨) |
メンテナンス(保守)テストとは…
システム変更時に必要となる確認テストやリグレッションテストのこと。
メンテナンステストの対象範囲は「変更リスク」「既存システムの大きさ」「変更の大きさ」に依存します。主にリグレッションテストとなるため、変更に伴う影響分析を行う必要があります。
| 各章 | リンク |
|---|---|
| 1章 | 【JSTQB】1章 テストの基礎｜解説 |
| 2章 | 【JSTQB】2章 ソフトウェア開発ライフサイクル全体を通してのテスト｜解説 |
| 3章 | 【JSTQB】3章 静的テスト｜解説 |
| 4章 | 【JSTQB】4章 テスト分析と設計｜解説 |
| 5章 | 【JSTQB】5章 テスト活動のマネジメント｜解説 |
| 6章 | 【JSTQB】6章 テストツール｜解説 |
This website uses cookies.