ソフトウェア要件で自動テストを指定する必要がありますか？
ソフトウェア要件を定義する場合、自動テスト（単体および統合）を指定する必要がありますか？これに関するガイダンスは見たことがなく、「テスト」はソフトウェアの機能要件ではありません。しかし、CI/CDの観点からは、これはほぼ「必須」です。
見解/意見をいただければ幸いですが、記事やガイドへの方向性をいただければ幸いです。
明確化/詳細
1-要件（高レベル）は、入札/提案プロセスをサポートするために作成されています。
2-CI/CDを組み込んで、より短い配信/展開サイクルを促進したいという希望/意図があります。
3-＃2を達成することは、ユニットレベルでも統合でも、自動テストなしでは不可能に近いものです。
4-意図は、特定の要件に対して実行される特定のテストを識別することではなく、自動テストの開発が落札者のソフトウェア開発プロセスの一部として含まれるという要件を確立することです。
5-これは、理想的には、他のドキュメント/プロセスにあるはずです。しかし、それらは開発/配信される傾向があります（受賞後;エルゴ、質問。
そして、最後に重要なことですが、自動テストの開発を要求するだけでは、テストが開発されたソフトウェアを適切にテストするという意味ではありません。したがって、そのような要件が落札者に課せられた場合、何が許容可能なテストを構成するかを定義するいくつかの客観的な測定も必要になります。これらは存在しますが、これはすべてワームホールになる可能性があるため、長所と短所のバランスをとろうとしています。
ほとんどの場合、自動テストの要件はソフトウェア要件とは見なされないことをお勧めします。
私がコメントで取り上げた である私の最初の考えは、このプロセスの一部が逆に思われるということです。要件は、提案プロセスをサポートするためにベンダーによって書かれていません。要件または目的は顧客によって表現され、ベンダーはそれらがそれらの要件または目的をどのように満たすか、およびそれらを行うスケジュールと予算を提案します。ベンダーは提案を提示する際に、特定のプロセス方法論（リーンアジャイルアプローチやDevOpsアプローチなど、自動テストフレームワークCI/CDパイプラインを利用できる）がリスク、スケジュール、および予算にどのように影響するかを提案します。そしてそのために、ベンダーは、適切なテストハーネスとCI/CDパイプラインを作成するための時間と費用の割り当ての詳細に入ることができます。
お客様が自動テストに関する要件を表明するケースがいくつかあります。 1つの例は、直接または継続的なメンテナンスとサポートを含む、提供されたソフトウェアの所有権を直接、またはメンテナンスとサポートを別のベンダーに委託することがある追加契約として引き継ぐことによって、最終的にお客様が所有権を取得する場合です。ただし、私はこれをソフトウェア要件ではなく、契約上の義務と見なします。ソフトウェア要件は、これらの属性がどのように満たされるかを指定せずに、機能属性と品質属性の定義であると考えます。
顧客がベンダーに要件を提示するときは、提案プロセスで指定される「方法」の範囲を最小限に抑える必要がありますが、提供される製品とサービスが何をする必要があるか、具体的には何をする必要があるかに焦点を当てます。ベンダーは、それらのニーズを満たすさまざまな方法を指定し、全体的なコスト、スケジュール、およびリスクに関して入札を正当化できるようにする必要があります。
まず、実際のプロジェクトで作業するチームはプロの開発者のチームであるという一般的な前提があります。つまり、コードのテスト、定期的なリファクタリングなど、専門的に仕事をすることになります。多くのチームがテストを行わないという事実は、あまり詳細ではない要件の問題を示しているのではなく、チームが非専門的な方法で作業できるようにするプロセスとアプローチの問題を示しています。
第2に、大規模なプロジェクトでは、通常、テストの実行方法、必要なテストの種類、さまざまな種類のテストを担当する担当者、テストチームと開発者間の競合がどのようになるかを正確に説明する個別のドキュメントがあります。処理され、そして他の多くのこと。そのため、このドキュメントの一部を要件ドキュメントに複製する必要はありません（有害ですらあります）。それらは流され、要件は通常非常に早く古くなります。あなたはあなたのプロジェクトにそれを望まない。
要件ドキュメントに詳細なテスト情報を含めたことはありません。これについては、テスト計画のドキュメントで説明します。
SRSドキュメントには、特定のタイプのテストまたはいくつかのコーナーケースへの参照が含まれている可能性がありますが、具体的なものはありません。
一方、テスト計画、または検証と検証のドキュメントには、手動または自動のいずれでも、関連するテストケースとシナリオとともに、必要なすべてのテストを含める必要があります。
なんらかの検討を経て、「書類」を扱っている人々との議論の後...
自動化されたテストの要件が「最もよく表現されている」場所は、成果物（契約）の中にあります。ここでは、配信されるアイテムが識別されます。したがって、ソース、ユーザーガイド、SDKなど。、そして...自動化されたテストコード/スクリプト。
もちろん、これは、要件が契約対象の機能のパフォーマンス要件に集中できることを意味します。
これは（私にとって）理にかなっており、物事を「本来あるべき場所」に保ちます。
要件が真の要件であるためには、何らかの方法で、要件が満たされているかどうかを客観的に判断するメトリックまたはテストを指定する必要があります。これにより、「まだ完了していません」と言うことで、顧客が要件を必要とする問題を回避できます。メトリックが満たされると、要件は完了したと宣言されます。
実際の要件：
認証済みユーザーとして、請求書に住所を入力することができます。
実際の要件ではありません：
アプリケーションには、ユーザーフレンドリーなインターフェースが必要です。
要件のあいまいさを排除するために自動テストが必要な場合は、必ず、それらのテストの内容を正確に指定してください。ただし、通常、単体テストのようなものは、ユーザーストーリーの観点からのシステムの動作ではなく、実装の詳細をテストすることを目的としています。このようなテストは重要ですが、要件自体に直接通知しない限り、要件で呼び出す必要はありません。
いいえ、ソフトウェア要件は、ソフトウェアのテストの詳細に対処すべきではありません。
ソフトウェア要件は、特定のシステムが実行する必要のあるタスク、入力と出力、アルゴリズムとデータ構造、容量と応答性を記述する必要があります。
ソフトウェアのテストは必須ですか？私はそう思いますが、それでも機能的または非機能的要件の領域外です。実際、より多くの要件が結果に焦点を当てており、そこに到達する方法ではなく、より簡単に満たす（およびテストする）ことができます。
自動車整備士に、車に乗るときに試乗するように言っていますか。シェフにキッチンを掃除するように言いますか？セキュリティトレーニングを受けるソフトウェアエンジニアですか？いいえ、これらのことを成し遂げるためのプロセスがあり、意図されたレベルの品質を生み出します。
入札/提案の設計の一環として、選択肢があります。いくつかのソフトウェア要件を定義し、指定された要件を満たしたソフトウェアを提供するように企業に要求することができます。通常、これらには、ソフトウェアを使用するためのユースケースおよびビジネス/ユーザーの目的に関連する機能アイテムが含まれます。非機能要件を含めることも賢明でしょう。非機能要件には、特定のタスクを実行するためのタイムスケールが含まれる可能性があります。または、Webサイトなどの容量の制約は、2,000の同時ユーザーセッションを処理できなければならず、1％がいつでもページをアクティブに取得できる必要があります。
ただし、入札/提案を異なる方法で定義することができます。ソフトウェアを提供するプロジェクトを実装するための入札として入札提案を定義できます。
ここでの違いは、プロジェクト要件と初期ソフトウェア要件を定義することにより、次のことが可能になることです。
ソフトウェアの開発で実装されるプロセスと品質管理にある程度の影響を与えます。仕事に入札する企業は、最小限の努力で十分な品質を提供することを求めています。エンジニアリング品質管理に従ってプロジェクト要件を定義することにより、プロジェクトの主要な品質管理の管理を維持できます。
入札をプロジェクトとして定義することで、最初の仕様にそれほど緊密に結びつくことはなく、プロジェクトとその実装の詳細がよりよく理解されるように、仕様の明確化を管理する方法について考える可能性が高くなります。
これにより、ソフトウェアの自動テスト可能性に関する要件を設定できるようになります。また、必要なテスト容易性のレベルと、自動テストプロセスを行わずに、製品の複雑さによって迅速な導入サイクルをどのように実現できるかについても慎重に検討します。完了するまでの時間。
最後に、メモとして-ソフトウェアコンサルタントのWebサイトを見ると、彼らのセールスピッチは、開発者への支払いの安さではなく、常に職人の技と優れた開発プロセスについてです-営業チームは、彼らのプロジェクトプロセスは、プロジェクトの概要を満たす優れた顧客体験を提供します
これが、組織の「完了の定義」の目的です。
簡単に言えば、ある時点で、組織（開発者、製品所有者、管理者）は、何かが「完了」と言ったときに何を意味するかを決定する必要があり、それがその定義を満たさない場合、まだ完了していません。
したがって、完了の定義の側面の1つは、十分なレベルの自動テストが実装されていることです。
もちろん、これはすべてテスト可能な要件に依存しています（Robert Harveyの回答を参照）。