非公式レビューの重要な特徴は、コストが低いことです。非公式レビューは、正式なプロセスに従わず、正式な文書も持たないタイプのレビューです。非公式レビューは通常、レビュー対象の製品についてある程度の知識や関心を持つ個人または同僚の小グループによって行われます。非公式レビューは、エラーの確認、疑問の解消、アイデアの共有など、いつでも、どんな目的でも行うことができます。非公式レビューは、実施に多くの時間、労力、リソースを必要としないため、コストが低くなります。その他のオプションは、非公式レビューの重要な特徴ではありません。キックオフミーティングは、検査やウォークスルーなどの正式なレビューの特徴です。キックオフミーティングは、レビュープロセスの開始前に開催される会議で、参加者の役割と責任が定義され、レビューの目的と範囲が合意され、レビューのロジスティクスとスケジュールが計画されます。個別の準備は、検査やウォークスルーなどの正式なレビューの特徴です。個別準備とは、レビュー担当者がレビュー会議の前に行う活動であり、レビュー対象製品を調べ、レビュー会議中に議論または解決する必要のある問題や質問を特定します。メトリクス分析は、検査やウォークスルーなどの正式なレビューの特徴です。メトリクス分析は、レビュープロセスが完了した後に行われる活動であり、レビューのデータと結果を収集して分析し、レビューの有効性と効率性を測定するとともに、今後のレビューのための改善策や教訓を特定します。 検証済み参考文献：ISTQB Foundation Level 2018 シラバス学習ガイド - Springer、9 ページ。

機能テストは、ブラックボックス動的テストの一例です。ブラックボックステスト（仕様ベーステストとも呼ばれる）は、テスト対象システムの内部構造や実装を考慮せず、外部動作や機能のみを対象とするテストです。動的テストは、テスト対象システムをさまざまな入力で実行し、その出力を観察するテストです。機能テストは、テスト対象システムが要件や仕様に従って意図した機能を実行することを検証するブラックボックス動的テストの一種です。機能テストは、テストの目的や基準に応じて、さまざまなレベルや範囲で実行できます。その他のオプションは、ブラックボックス動的テストの例ではありません。コード検査は、ホワイトボックス静的テストの一例です。ホワイトボックステスト（構造ベーステストとも呼ばれる）は、テスト対象システムの内部構造や実装を対象とするテストです。静的テストは、テスト対象システムを実行するのではなく、欠陥、エラー、または標準違反を分析するテストです。コードインスペクションは、ホワイトボックス静的テストの一種であり、テスト対象システムのソースコードの品質、可読性、保守性などを検査するものです。
プログラムを実行してメモリリークをチェックすることは、ホワイトボックス動的テストの一例です。メモリリークとは、プログラムが割り当てたものの、もはや必要のないメモリを解放できない場合に発生する欠陥です。
プログラムを実行してメモリリークをチェックするには、メモリ割り当てと解放のメカニズム、ポインタ、参照など、プログラムの内部構造や実装に関する知識とアクセスが必要です。カバレッジ分析は、ホワイトボックス静的テストの一例です。カバレッジ分析は、テスト対象システムのコードや構造のうち、テストスイートによってどの程度実行されたかを測定する手法です。
カバレッジ分析には、テスト対象システムの内部構造や実装（ステートメント、ブランチ、パス、条件など）に関する知識とアクセスが必要です。検証済み参考文献：ISTQB Foundation Level 2018 シラバス学習ガイド - Springer、7 ページ。

ユースケーステストは、トランザクションごとにシステム全体を最初から最後までテストするテストケースを特定するのに役立つ手法です。ユースケースとは、ユーザーが特定の目標を達成するためにシステムとどのようにやり取りするかを記述したものです。ユースケーステストはデータフローではなく、プロセスフローに焦点を当てています。ユースケーステストは、状況に応じて、プロのテスター、顧客、またはエンドユーザーが実行できます。ユースケーステストでは、テストケースの設計を顧客やエンドユーザーが行う必要はなく、ユースケース仕様にアクセスできる人であれば誰でも行うことができます。参照資料：ISTQB® Foundation Level 学習ガイド
2018年度シラバス - Springer、第4章、36ページ。

テストピラミッドの概念では、低レベルのテスト（単体テスト）を多くし、高レベルのテスト（エンドツーエンドテスト）を少なくすべきだと提唱している。
* ピラミッドの上層部に進むにつれて（例えば、単体テストから統合テスト、エンドツーエンドテストへ）、各テストはより多くの本番コードをカバーします。
* より高度なテスト（エンドツーエンドなど）は、複数のユニットとその相互作用を含む、アプリケーションのより大きな部分を検証します。
これは、より高度なテストはより広い範囲をカバーできるものの、テストの数は少なく、実施と維持にコストがかかるという原則に合致している。