ATDD は、Acceptance Test-Driven Development (受け入れテスト駆動開発) の略で、ソフトウェア開発とテストに対する共同アプローチであり、ユーザー ストーリーの受け入れ基準がソフトウェア システムの実装前に実行可能なテストとして定義され、自動化されます。ATDD テストは通常​​、Given-When-Then 形式で記述され、テスト シナリオの前提条件、アクション、および予想される結果が記述されます。ATDD テストは、ソフトウェア システムがユーザーと関係者の期待とニーズを満たしていることを検証すること、また開発者とテスターに​​フィードバックとガイダンスを提供することを目的としています。与えられた情報に基づいて、最初に作成される可能性が最も高い ATDD テストは、オプション B に対応するテストです。
ログインしているユーザーが [パスワードの変更] ページに表示されているとします。 ユーザーが正しい現在のパスワードを入力し、有効な新しいパスワード (過去 5 つのパスワードとは異なる) を入力して、[パスワードの変更] ボタンを押すと、ユーザーは、次のことを確認する電子メールを受け取ります。パスワードは正常に変更されました。 この ATDD テストは、主要な機能とユーザー ストーリーのハッピー パス、および最も重要な合格基準 [a] をカバーしているため、最初に作成される可能性が最も高くなります。また、受け入れ基準 [c] で指定されているように、パスワードの長さ、文字の種類、履歴に関する基準を満たす有効な新しいパスワードでユーザーがパスワードを変更できることも検証します。他のオプションは、間違った現在のパスワード [d] や無効な新しいパスワード [e] の入力など、重要度が低く、頻度も低いシナリオをカバーしているか、ユーザー ストーリーに関連していないため、最初に記述される可能性は高くありません。または、発注書の提出など、受け入れ基準をまったく満たさない場合もあります [d]。参照: ISTQB Certified Tester Foundation Level (CTFL) v4.0 のソースとドキュメント:
ISTQB® Certified Tester Foundation Level Syllabus v4.0、第 1.3.1 章、ソフトウェア開発ライフサイクルにおけるテスト 1 ISTQB® テスト用語集 v4.0、受け入れテスト駆動開発、ユーザー ストーリー、受け入れ基準、Given-When-Then2

静的テストは、テスト対象のソフトウェアまたはシステムの実行を含まないテスト形式です。これには、ドキュメント、コード、モデルのレビュー、検査、ウォークスルー、分析などのアクティビティが含まれます。静的テストでは、開発プロセスの早い段階で欠陥を発見でき、後の段階で欠陥が高価になり修正が困難になる前に見つけることができます。静的テストは、そもそも欠陥の発生を防ぐことで、ソフトウェアまたはシステムの品質を向上させることもできます。静的テストは、テスト対象のソフトウェアまたはシステムを実行し、予想される結果と比較して結果をチェックする動的テストを補完できます。動的テストでは、パフォーマンス、ユーザビリティ、統合の問題など、静的テストでは見逃される可能性のある欠陥を見つけることができます。ただし、動的テストだけでは、考えられるすべてのシナリオ、入力、パスをカバーしていない可能性があるため、品質を保証するには十分ではありません。したがって、静的テストをスキップすることを決定したテスト管理者は、静的テストの利点を無視し、欠陥を発見して防止するのに十分な効果や効率が得られない可能性がある動的テストだけに頼っているため、間違った決定をしていることになります。参照 = ISTQB Certified Tester Foundation Level Syllabus、バージョン 4.0、2018、セクション 2.1.1、14 ページ。ISTQB テスト用語集、バージョン 4.0、2018 年、36 ページ。ISTQB CTFL 4.0 - サンプル試験 - 解答、バージョン 1.1、2023、質問 3、9 ページ。

説明
機能テスターは、問題が発生したデバイスおよび実行したテストに関する詳細情報を提供する欠陥レポートを開く必要があります。欠陥レポートは、テスト中に検出された欠陥の発生、性質、ステータスを記録し、さらなる調査と解決のための情報を提供する文書です。
欠陥レポートには、欠陥の概要、欠陥の説明、欠陥の重大度、欠陥の優先順位、欠陥のステータス、欠陥の原因、欠陥のカテゴリ、欠陥の再現手順、欠陥のスクリーンショット、欠陥の添付ファイルなどの関連情報が含まれている必要があります。実行されたテストの種類やレベルに関係なく、ソフトウェア システムに欠陥を発見したテスターに​​とって、欠陥レポートを開くことは良い習慣です。他のオプションは次の理由から推奨されません。
この問題は機能ではなくパフォーマンス効率に関連していますが、すべての機能テストが合格したため、機能テスト担当者として欠陥レポートを開いてはいけないという意味ではありません。パフォーマンス効率は、応答時間、リソース使用率、スループットなど、指定された条件下でソフトウェア システムがその機能をどの程度適切に実行するかを測定する品質特性です。
パフォーマンス効率は、特にさまざまなデバイスやネットワーク上で実行される Web アプリケーションにとって、ユーザー エクスペリエンスの重要な側面です。機能テストに合格した場合、つまりソフトウェア システムが機能要件を満たしている場合でも、一部のデバイスで観察されたパフォーマンスの問題は、ソフトウェア システムのユーザー満足度、使いやすさ、信頼性、セキュリティに影響を与える可能性があります。
したがって、機能テスト担当者には、パフォーマンスの問題を欠陥として報告し、開発者またはパフォーマンス テスト担当者が問題を調査して解決できるようにできる限り多くの情報を提供する責任があります。

テスト駆動開発は、テストに必要な典型的な一般的なスキルの例ではなく、テストのコンテキストや目的に応じて、テストに関連する場合とそうでない場合がある特定の技術スキルまたは開発実践の例です。活動。テスト駆動開発はソフトウェア開発とテストへのアプローチであり、開発者はソース コードを記述する前に自動化された単体テストを作成し、テストが合格するまでコードをリファクタリングします。テスト駆動開発は、コードの品質、設計、保守性を向上させるだけでなく、開発者に迅速なフィードバックやガイダンスを提供するのにも役立ちます。ただし、テスト駆動開発は、テスター、特に単体テストに関与していないテスターやソース コードにアクセスできないテスターに​​とって、一般に期待または必要とされるスキルではありません。他のオプションは、テストに必要な典型的な一般的なスキルの例であり、使用される特定のテスト手法、ツール、方法に関係なく、あらゆるコンテキストや状況でのテストに適用可能で有益なスキルです。テストに必要な一般的なスキルには次のものがあります。
テスト管理ツールと欠陥追跡ツールを使用できるようにする: これらは、テスターがテスト活動とリソースを計画、整理、監視、制御し、テスト中に検出された欠陥を記録、追跡、分析、解決するのに役立つツールです。 。これらのツールは、テスト プロセスの効率、有効性、コミュニケーションを向上させることができるほか、テスト結果のトレーサビリティ、指標、レポートを提供します。
欠陥や障害をできるだけ客観的に開発者に伝えることができる: これは、関連する情報や証拠を使用して、明確、簡潔、正確、そして公平な方法で、テスト中に見つかった欠陥や障害を報告および説明する能力を含むスキルです。 、および用語を、仮定、判断、または非難をせずに使用します。このスキルは、テスターと開発者の間でのコラボレーション、理解、および欠陥や障害の解決を容易にし、衝突、誤解、責任のなすり合いを防ぐことができます。
効果的なチームワークをサポートするために必要なソーシャル スキルを備えています。これらのスキルには、テスト マネージャー、テスト チーム、プロジェクト マネージャー、テスト活動に関与する、または影響を受ける他の人々と対話し、協力し、調整する能力が含まれます。これらのスキルには、コミュニケーション、交渉、リーダーシップ、モチベーション、フィードバック、競合解決などが含まれます。これらのスキルは、テスト プロセスの品質、生産性、満足度を向上させるだけでなく、テスト プロセスの満足度も高めることができます。積極的で建設的なテスト文化を促進するために。参照: ISTQB Certified Tester Foundation Level (CTFL) v4.0 のソースとドキュメント:
ISTQB® Certified Tester Foundation Level シラバス v4.0、第 1.1.1 章、テストとソフトウェア開発ライフサイクル ISTQB® Certified Tester Foundation Level Syllabus v4.0、第 1.1.2 章、テストと品質 ISTQB® Certified Tester Foundation Level シラバス v4。 0、第 1.2.1 章、テスト原則 ISTQB® Certified Tester Foundation Level シラバス v4.0、第 1.2.2 章、テスト ポリシー、戦略、およびテスト アプローチ ISTQB® テスト用語集 v4.0、テスト駆動開発、テスト管理ツール、欠陥追跡ツール、欠陥レポート、失敗、ソーシャル スキル 2

以前のシステムと比較した新しいナビゲーション システムは、ユーザーとシステム間の高度な対話を必要とし、システムの期待される動作と結果はユーザーのニーズに基づいているため、ユースケース別のテストに最適なアプリケーションです。そして目標。ユース ケースは、目的地の入力、ルートの選択、道案内に従う、アラートの受信などの機能など、新しいナビゲーション システムの機能要件を指定するのに役立ちます。また、ユース ケースは、ナビゲーション システムの精度と使いやすさを比較するのにも役立ちます。成功と失敗のシナリオ、前提条件と事後条件、各ユースケースの代替フローを定義することで、新しいシステムと以前のシステムを統合します。ユース ケースは、各ユース ケースの主要なパスと例外的なパスをカバーするテスト ケースを設計および実行し、ユーザーの期待が満たされるかどうかを検証するのにも役立ちます。
他のオプションは、ユーザーとシステム間の高度な対話を伴わない、またはシステムの期待される動作と結果がユーザーのニーズや目標に基づいていないため、ユースケース別のテストには最適なアプリケーションではありません。 。多数の加入者パラメータに基づいて月額料金を計算するために使用される請求システムは、データ駆動型テストによるテストに適しています。データ駆動型テストは、大量の入力データとコンポーネントを使用してシステムまたはコンポーネントの機能とパフォーマンスをテストする手法です。出力データ。新しい脅威を検出して隔離するウイルス対策パッケージの機能は、探索的テストによるテストに適しています。探索的テストとは、テスターの経験に基づいた、非公式で柔軟なアプローチを使用してシステムまたはコンポーネントの機能とセキュリティをテストする手法です。そして直感。新しいオペレーティング システムに対するマルチメディア (オーディオ ビデオ ベース) システムの適合性とパフォーマンスは、互換性テストによるテストにより適しています。互換性テストとは、さまざまなハードウェア、ソフトウェア、またはコンポーネントを使用してシステムまたはコンポーネントの機能とパフォーマンスをテストする手法です。ネットワーク環境。参照 = CTFL 4.0 シラバス、セクション 3.1.1、28 ～ 29 ページ。セクション 4.1.1、44 ～ 45 ページ。セクション 4.2.1、47 ～ 48 ページ。