how test software requirements specification
あなたはそれを知っていますか 'ほとんど バグ ソフトウェアの機能要件が不完全または不正確なためですか？」 どんなにうまく書かれていても、ソフトウェアコードは重要ではなく、要件にあいまいさがあれば何もできません。
ソフトウェア要件仕様（SRS）に関するこの記事では、要件は明確で、具体的で、測定可能で、矛盾することなく完全でなければならないと述べています。
要件のあいまいさを見つけて、開発ライフサイクルの初期段階で修正することをお勧めします。
開発または製品リリースの完了後にバグを修正するコストが高すぎます。したがって、SDLCの設計仕様とプロジェクトの実装フェーズの前に、要件分析を行い、これらの誤った要件を把握することが重要です。
学習内容：
機能的なSRSドキュメントを測定する方法は？
さて、要件を測定するためにいくつかの標準テストを定義する必要があります。各要件がこれらのテストに合格すると、機能要件を評価して凍結できます。
取りましょう 例、 あなたはウェブベースのアプリケーションに取り組んでいます。要件は次のとおりです。「Webアプリケーションは、ユーザーのクエリをできるだけ早く提供できる必要があります」
この場合、要件をどのように凍結しますか？
要件満足度の基準は何ですか？答えを得るには、利害関係者に次の質問をします。どのくらいの応答時間が問題ありませんか。彼らが言うなら、それが2秒以内であれば、私たちは応答を受け入れます、そしてこれはあなたの要件の尺度です。この要件を凍結し、次の要件についても同じ手順を実行します。
要件を測定し、設計、実装、テストの各フェーズで要件を凍結する方法を学びました。
次に、別の例を見てみましょう。 私はWebベースのプロジェクトに取り組んでいました。クライアント（利害関係者）は、プロジェクト開発の初期段階でプロジェクト要件を指定しました。私のマネージャーは、レビューのためにチーム内のすべての要件を回覧しました。これらの要件について話し合いを始めたとき、私たちはただショックを受けました！
誰もが要件について独自の概念を持っていました。要件ドキュメントで指定されている「用語」に多くのあいまいさが見つかりました。これらの用語は、後でレビュー/説明のためにクライアントに送信されました。
クライアントは、多くの異なる意味を持つ多くのあいまいな用語を使用していたため、正確な意味を分析することは困難でした。クライアントからの要件ドキュメントの次のバージョンは、設計段階でフリーズするのに十分明確でした。
この例から、「要件は明確で一貫している必要がある」ことがわかりました。
要件仕様をテストするための次の基準は「不足している要件を発見する」です。それを見てみましょう。
ネットワーク上のデフォルトゲートウェイを置き換えました
不足している要件を発見する
多くの場合、プロジェクト設計者は特定の各モジュールについて明確なアイデアを得ることができず、設計段階でいくつかの要件を想定しているだけです。要件は、仮定に基づくべきではありません。要件は完全であり、開発中のシステムのあらゆる側面をカバーしている必要があります。
仕様には、両方のタイプの要件、つまり、システムが実行すべきことと実行すべきでないことの両方を記載する必要があります。
一般的に、私は独自の方法を使用して、不特定の要件を明らかにします。私が読んだとき ソフトウェア要件仕様書（SRS） 、指定されている要件に加えて、SRSドキュメントがカバーすることになっている他の要件についての私自身の理解を書き留めます。
これは、不特定の要件について質問するのに役立ち、それによってそれがより明確になります。
要件の完全性を確認するには、要件を「実装する必要がある」要件、指定されていないが「想定」されている要件の3つのセクションに分割し、3番目のタイプは「想像」タイプの要件です。ソフトウェア設計フェーズの前に、すべてのタイプの要件に対応しているかどうかを確認してください。
要件がプロジェクトの目標に関連しているかどうかを確認します
利害関係者が独自の専門知識を持っている場合があり、それは開発中のシステムに組み込まれることを期待しています。彼らは、その要件が手元のプロジェクトに関連するかどうかさえ考えていません。そのような要件を必ず特定してください。プロジェクト開発サイクルの最初のフェーズでは、無関係な要件をすべて回避するようにしてください。
不可能な場合は、なぜこの特定の要件を実装したいのかなど、利害関係者に質問してください。これにより、特定の要件が詳細に説明されるため、将来の範囲を考慮したシステムの設計が容易になります。
しかし、要件が適切かどうかを判断するにはどうすればよいでしょうか。
簡単な答え：プロジェクトの目標を設定し、この質問をします。この要件を実装しないと、指定された目標を達成するのに問題が発生しますか？そうでない場合、これは無関係な要件です。これらのタイプの要件を本当に実装したいかどうか、利害関係者に尋ねてください。
つまり、要件仕様（SRS）のドキュメントでは、次のことに対処する必要があります。
- プロジェクトの機能（何をすべきか、何をすべきでないか）。
- ソフトウェア、ハードウェアインターフェイス、およびユーザーインターフェイス。
- システムの正確性、セキュリティ、およびパフォーマンスの基準。
- 実装の問題（リスク）がある場合。
結論
要件測定のほぼすべての側面をカバーしました。要件について具体的に説明するために、要件テストを1つの文に要約します。
「要件は不確実性のない明確で具体的である必要があり、要件は特定の値に関して測定可能である必要があり、要件は各要件のいくつかの評価基準を使用してテスト可能である必要があり、要件は矛盾することなく完全である必要があります。」
要件に関連するさらなるバグを回避するために、テストは要件フェーズから開始する必要があります。 コミュニケーションする プロジェクトの設計と実装を開始する前に、すべての要件を明確にするために、利害関係者とますます協力してください。
ソフトウェア要件のテストの経験はありますか？
以下のコメントでお気軽に共有してください。
推奨読書
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- ソフトウェアテストQAアシスタントジョブ
- 破壊検査と非破壊検査のチュートリアル
- ソフトウェアテストにおけるマインドマッピング-テストをより楽しくする方法！
- 要件なしでアプリケーションをテストする方法は？
- ソフトウェアテストコース：どのソフトウェアテスト機関に参加する必要がありますか？
- キャリアとしてのソフトウェアテストの選択
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事