テストレベル

社内では資格取得勉強会を実施しています。ITパスポートから応用技術者試験までIPAの資格取得勉強会に加えて、JSTQB Foundationの資格取得のための勉強会も実施しています。
JSTQBはQAエンジニアで取得されている方をよく見かけるようになりました。社内では1名取得していて、さらに1名が学習中です。

JSTQBの勉強で躓くのが言葉の定義です。普段使っている言葉と同じものもありますが、似たような言い回しで普段利用しないものがあります。
その一つがテストレベルとテストタイプです。

次回の勉強会のテーマにするので、テストレベルについて記録しておきます。

参考にしたのは、以下の２つのシラバスですが、英語のシラバスの方が理解しやすい点もありましたので、日本語のシラバスとは異なる表現で記載しています。
シラバス2023V4.0.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
シラバス2018V3.1.J03
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
 ISTQB CTFL Syllabus v4.0
https://www.istqb.org/certifications/certified-tester-foundation-level

テストレベル

基本的にはシステム開発が進んでくると、テストレベルが次に進んでいきます。ただし多くの場合でテストレベルは重複します。
そして、各テストレベルにおいてテストタイプが実行されます。
コンポーネントテスト（ユニットテストまたはモジュールテスト）
⇩
コンポーネント結合テスト（ユニット結合テスト）
⇩
システムテスト
⇩
システム結合テスト
⇩
受入テスト

それぞれのレベルについて以下の属性のリストを記載する
１．コンポーネントテスト
⚫ テスト対象・・・個別にテスト可能なコンポーネント
⚫ テスト目的・・・コンポーネントの機能的/非機能的振る舞いが設計および仕様通りであることの検証
⚫ テストベース（テスト分析と設計のベースとして使用する情報）・・・詳細設計／コード／仕様
⚫ 欠陥、および故障・・・正しくない機能
⚫ アプローチと責務・・・コンポーネントテストはコードを開発した開発担当者が行うことが一般的であるが、アプリケーションコードを記述する前に、自動化されたコンポーネントのテストケースを記述する場合がある

２．結合テスト（コンポーネント結合テストとシステム結合テスト）
⚫ テスト対象・・・コンポーネントまたはシステム間の相互処理
API／マイクロサービス／サブシステム
※結合だけに集中すべき
⚫ テスト目的・・・インターフェースの機能的/非機能的振る舞いが設計および仕様通りであることの検証
⚫ テストベース（テスト分析と設計のベースとして使用する情報）・・・ソフトウェア設計とシステム設計／ シーケンス図／ インターフェースと通信プロトコルの仕様／ユースケース／外部インターフェース定義
⚫ 欠陥、および故障・・・正しくないデータ、データ不足／インターフェースの不整合／コンポーネント間のコミュニケーション故障／
⚫ アプローチと責務・・・コンポーネント統合テストは開発担当者が実行するのが一般的であり、システム統合テストはテスト担当者が実行するのが一般的である。理想的には、システム統合テストを実行するテスト担当者はシステムアーキテクチャーを理解すべきである

３．システムテスト
⚫ テスト対象・・・システムやプロダクト全体の振る舞いや能力
アプリケーション／ハードウェア／ソフトウェア
⚫ テスト目的・・・システムの機能的/非機能的振る舞いが設計および仕様通りであることの検証
⚫ テストベース（テスト分析と設計のベースとして使用する情報）・・・システム要求仕様およびソフトウェア要求仕様（機能および非機能） ／状態遷移図 ／システムマニュアルおよびユーザーマニュアル
⚫ 欠陥、および故障・・・正しくない、または期待通りではないシステムの機能的または非機能的振る舞い
⚫ アプローチと責務・・・通常、独立したテストチームが仕様を頼りにして行うことが多い

４．受け入れテスト（ユーザー受け入れテスト／運用受け入れテスト等）
⚫ テスト対象・・・システムやプロダクト全体の振る舞いや能力
アプリケーション／ハードウェア／ソフトウェア
⚫ テスト目的・・・システムが完成し、期待通りに動作することの妥当性確認
⚫ テストベース（テスト分析と設計のベースとして使用する情報）・・・ユーザー要件またはビジネス要件 ／ユースケースおよび/またはユーザーストーリー ／システムドキュメントまたはユーザードキュメント
⚫ 欠陥、および故障・・・システムのワークフローがビジネス要件またはユーザー要件を満たさない。
⚫ アプローチと責務・・・受け入れテストは、顧客、ビジネスユーザー、プロダクトオーナー、またはシステムの運用担当者の責任で行われる。他のステークホルダーも関与することがある。