ソフトウェア開発ライフサイクル（SDLC）モデルの選択は、主に開発対象となる製品の種類によって左右されます。製品やプロジェクトの要件が異なると、特定の課題やニーズに効率的に対応するために、異なるSDLCモデルが必要になる場合があります。例えば、複雑で安全性が極めて重要な製品には、構造化された性質とフェーズ間の依存関係から、ウォーターフォールモデルが最適な場合があります。一方、頻繁なフィードバックと変更が必要なプロジェクトには、より反復的で漸進的なモデルが適している可能性があります。
参照：
ISTQB 認定テスター基礎レベル シラバス v4.0、セクション 2.1「ソフトウェア開発ライフサイクル」。

テストのレベルとその目的は次のように対応できます。
* システムの機能的および非機能的動作が設計および仕様どおりであるかどうかを検証します (A3: システム テスト)。
* インターフェースの機能的および非機能的動作が設計どおりであるかどうかを検証する（B2：
統合テスト)。
* コンポーネントの機能的および非機能的動作が設計および仕様どおりであるかどうかを検証します (C1: コンポーネント テスト)。
* システム全体の品質に対する信頼を確立する (D4: 受け入れテスト)。

包括的かつ詳細な解説：テストとデバッグは別個の活動ですが、関連性があります。テストはソフトウェアを実行し、欠陥（A）に起因する障害を特定します。デバッグは開発者の責任であり、障害（欠陥）の原因を特定し、分析し、修正することが含まれます。ISTQBシラバスでは、これらの活動を明確に区別しています。テストはソフトウェアを変更しませんが、デバッグは変更します。

回帰テストは、以前にテストされたソフトウェアが変更後も正しく動作することを確認するテストの一種です。回帰テストは、以前に修正された欠陥が新たな障害や副作用を引き起こさないことを確認することで、その欠陥の再発を防ぐのに役立ちます。企業への最初の推奨事項は、既存の回帰テストスイートが適切であることを検証し、必要に応じて拡張して、以前に修正された欠陥が以降の各ビルドで再テストされるようにすることです。これにより、回帰テストのカバレッジと有効性が向上し、回帰欠陥を可能な限り早期に検出できるようになります。既存のテストスイートを自動化することで、回帰テストに必要な時間と労力を削減できる可能性がありますが、自動化がすべてのテストケースで実現可能または費用対効果が高いとは限らないため、これは最初の推奨事項ではありません。欠陥が最も多く含まれる製品モジュールを分析し、それらを徹底的にテストして欠陥を一度限りの作業として修正することも、欠陥密度を低減し、モジュールの品質を向上させるのに役立つ可能性がありますが、これは以前に修正された欠陥の再発の根本原因に対処しないため、最初の推奨事項ではありません。最も多くの欠陥を含むモジュールの開発とテストを担当するチームをトレーニングするか、交代させることも、スキルやパフォーマンスの向上に役立ちますが、すべてのチームにとって必要または適切ではない可能性があるため、これは最初の推奨事項ではありません。
検証済みの参考文献: [ISTQB Foundation Level 2018 シラバスの学習ガイド - Springer]、第 2 章、19 ページ、第 4 章、45 ページ。

包括的かつ詳細な解説：チェックリストベースのテストでは、特定のテスト条件（B）を用いて、テスターが重要な側面を確実に検証できるようにします。チェックリスト項目は、過去の不具合、要件、または規制基準から抽出できます。
* (A) は、一般的なガイドラインに具体性が欠けているため、誤りです。
* (C) は不正解です。チェックリストは手動テストと自動テストの両方に使用できるためです。
* (D) は不正解です。チェックリストは機能テストと非機能テスト（セキュリティ、パフォーマンスなど）の両方に役立つためです。
チェックリストは、厳密にスクリプト化された実行を強制することなく、完全性を保証するのに役立ちます。