テストは次のようなさまざまな理由で必要です。
ソフトウェア製品またはシステムの品質、パフォーマンス、信頼性、またはセキュリティに影響を与える可能性のある欠陥や障害を検出するため ソフトウェア製品またはシステムが指定された要件、期待、基準を満たしていることを検証するため ソフトウェア製品またはシステムが意図された目的を満たしていることを検証するためソフトウェア製品またはシステムのステータスとリスクに関する情報とフィードバックを提供するため 特定の種類のソフトウェア製品またはシステムのテストを義務付ける規制または契約上の義務を遵守するため 以下の記述は、テストが必要な理由のいくつかを説明しています。 :
A) 顧客は 100% の支店カバレッジを達成することを決定しました。これが、テストが必要な理由です。これは、コード カバレッジの一定レベルを測定して達成するためにテストを必要とする契約上の義務または品質基準を反映しているためです。
C) 航空電子工学および製薬システムの場合、ソフトウェア テストは規格によって義務付けられています。これが、安全性やセキュリティ上のリスクが高い特定の種類のソフトウェア製品またはシステムのテストを義務付ける規制またはコンプライアンス要件を反映しているため、テストが必要な理由です。
D) システムの提供に伴うリスクは、テストのコストよりもはるかに高くなります。これが、潜在的な障害や欠陥の可能性と影響を軽減するための投資としてテストを考慮するリスクベースのアプローチを反映するため、テストが必要な理由です。次の記述では、テストが必要な理由が説明されていません。
B) テスト自動化ツールの取得は、すべてのプロジェクトで使用することを前提としていました。これは、テストの必要性や目的を正当化しないビジネス上の決定やリソースの割り当てを反映しているため、テストが必要な理由にはなりません。テスト自動化ツールは、すべてのプロジェクトに必ずしも適しているわけではなく、有益であるとは限りません。テストは、テスト自動化ツールの有無にかかわらず実行できます。検証済み参考文献: [ISTQB Foundation Level 2018 Syllabus - Springer]、第 1 章、5-6 ページ。

サポート チームの一員になるということは、テスターが顧客の視点に近づくことを意味します。これは、ユーザーのニーズと期待をより深く理解し、より現実的なシナリオとリスクを特定できるため、テストにとって利点となります。ただし、サポート チームの一員であるということは、顧客の好みや要求に影響される可能性があるため、何をどのようにテストするかを決定する際の独立性が低くなり、テストの客観性と有効性が損なわれる可能性があることを意味します。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、6 ページ。

テストは次のようなさまざまな理由で必要です。
* ソフトウェア製品またはシステムの品質、パフォーマンス、信頼性、またはセキュリティに影響を与える可能性のある欠陥や障害を検出するため
* ソフトウェア製品またはシステムが指定された要件、期待、基準を満たしていることを検証するため
* ソフトウェア製品またはシステムが意図された目的を果たし、利害関係者のニーズを満たしていることを検証するため
* ソフトウェア製品またはシステムのステータスとリスクに関する情報とフィードバックを提供するため
* 特定の種類のソフトウェア製品またはシステムのテストを義務付ける規制または契約上の義務を遵守するため 以下の記述は、テストが必要な理由のいくつかを説明しています。
* A) 顧客は支店カバレッジ 100% を達成することを決定しました。これが、テストが必要な理由です。これは、コード カバレッジの一定レベルを測定して達成するためにテストを必要とする契約上の義務または品質基準を反映しているためです。
* C) 航空電子工学および製薬システムの場合、ソフトウェア テストは規格によって義務付けられています。これが、安全性やセキュリティ上のリスクが高い特定の種類のソフトウェア製品またはシステムのテストを義務付ける規制またはコンプライアンス要件を反映しているため、テストが必要な理由です。
* D) システムの提供に伴うリスクは、テストのコストよりもはるかに高くなります。これが、潜在的な障害や欠陥の可能性と影響を軽減するための投資としてテストを考慮するリスクベースのアプローチを反映するため、テストが必要な理由です。次の記述では、テストが必要な理由が説明されていません。
* B) テスト自動化ツールの取得は、すべてのプロジェクトで使用することを前提としています。これは、テストの必要性や目的を正当化しないビジネス上の決定やリソースの割り当てを反映しているため、テストが必要な理由にはなりません。テスト自動化ツールは、すべてのプロジェクトに必ずしも適しているわけではなく、有益であるとは限りません。テストは、テスト自動化ツールの有無にかかわらず実行できます。
検証済みの参考文献: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer]、第 1 章、5-6 ページ。

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

※欠陥・失敗・間違いに関する記述のうち、正しいものを採点する問題です。ISTQB 用語集によると、これらの用語の定義は次のとおりです1。
* 欠陥: コンポーネントまたはシステムが必要な機能を実行できない原因となるコンポーネントまたはシステムの欠陥 (たとえば、不適切なステートメントやデータ定義)。実行中に欠陥が発生すると、コンポーネントまたはシステムの障害が発生する可能性があります。
* 障害: コンポーネントまたはシステムが指定された制限内で必要な機能を実行しないイベント。
* 間違い: 誤った結果をもたらす人間の行為。
* したがって、与えられた 5 つのステートメントのうち、正しいのは 2 つだけです。
* 人為的なミスは欠陥を引き起こす可能性があります。間違いは欠陥の原因または原因であるため、これは真実です。たとえば、プログラマがコード ステートメントの記述時にミスを犯し、その結果ソフトウェア コンポーネントに欠陥が生じる可能性があります。
* システムに欠陥が存在すると、障害が発生する可能性があります。欠陥は障害の潜在的または実際の原因であるため、これは当てはまります。たとえば、ソフトウェア コンポーネントの欠陥により、システムが必要な機能を実行できなくなる可能性があります。実行中に欠陥が発生した場合。
* 他の 3 つのステートメントは正しくありません。つまり、次のとおりです。
* 欠陥は環境条件の結果であり、「故障」とも呼ばれます。これは誤りです。欠陥は環境条件の結果ではなく、間違いやその他の要因によるものであり、欠陥は故障と同じではなく、むしろ故障です。失敗の原因。
* システムに障害が存在すると、システムは完全に正常に動作しなくなります。これは誤りです。システムは、障害が発生したときに必ずしも完全に障害が発生したり、動作を停止したりするわけではありませんが、機能やパフォーマンスが低下したり、誤った状態で動作し続ける可能性があるためです。結果。
* 欠陥はテクノロジーの変更の結果としてのみ発生する: これは誤りで、テクノロジーの変更だけでなく、人的ミス、設計上の欠陥、要件の変更、ハードウェアの障害など、さまざまな理由によって欠陥が発生する可能性があります。
参考文献:
* 1: ISTQB テスト用語集 4.0、2023、ISTQB) および ASTQB) で入手可能。