testing - 要件またはテスト?

Question

ソフトウェア プロジェクトでどちらかを使わないといけないとしたら、どちらを選びますか? クライアントや PM が、どちらかがなくてもやり遂げられると考えていたプロジェクトがたくさんありました。私たちは常に代償を払いました。

Answer 1

これをひっくり返して、「テストは要件です」と繰り返します。:-)

Answer 2

「正式な要件」を意味する場合は、それらなしで簡単に行うことができます。私は、厳格で時代遅れの文書よりも、自分が何を望んでいるのかを私に伝えることができる、生き生きとした顧客を望んでいます. TDD に切り替えたので、「テストなし」の環境に戻りたくありません。私は非公式の要件 (ストーリー、オンサイトの顧客、および顧客が作成した受け入れテスト) を、正式な要件やテストのないものよりも選びます。

Answer 3

要件ではなく、テストなしで行くことができると思います。要件がない場合、開発しているものをどのように知ることができますか?

プログラマーが十分に優れていれば、テストで見つかる重大なエラーのほとんどをキャッチできるはずです。

Answer 4

要件に対してテストする必要があるため、要件がなければテストを行うことはできません。したがって、1 つを選択する必要がある場合は、要件のみを選択できます。

しかし、テストを行わないことは失敗への道です。保証します。

Answer 5

要件とテストのどちらかを選択するように求められたら、履歴書に磨きをかけることを選択します。基本的なプロジェクトのライフサイクルは次のとおりであるため、どのプロジェクトでもどちらもなしにすることはできません。

1. ニーズ/目標を定義する (AKA 要件)
2. 要件に合わせた設計と構築
3. 仕様 (要件) に従ってビルドしたことを確認します。

検証可能な (そして検証可能な) 成功基準と目標がない場合、どうすれば成功することを保証できますか? 成功するチャンスがないのに、なぜプロジェクトを始める必要があるのでしょうか?

Answer 6

どちらかを選ばなければならない場合、それは要件になります。
形式的で、20 の署名を含む非常に詳細な文書である必要はありませんが、顧客が何を望んでいるか、さらに重要なことに、顧客が何を必要としているのかを正確に把握する必要があります。

要件は、開発チームへの最初のコミュニケーションでもあります。あなたが明確に尋ねていない場合、彼らはあなたが尋ねていることをどのように知ることができますか? せいぜい、間違ったものを正しく構築するという重大なリスクがあります。私はむしろ正しいものを少し間違って構築したいと思っています。

Answer 7

テスト（機能と統合）は要件よりも重要です。テストを指定できる場合は、少なくとも暗黙的に要件も指定しています。

コメントは開発者向けのドキュメントでもあり、単体テストはハウツーの「クイックスタート」の例です;-)

Answer 8

ソフトウェアを開発しているときに、クライアントからの「機能クリープ」のレベルが常にあるように見えるため、要件と言えます。テストは、SDLC の重要な要素の 1 つです。

Answer 9

要件とテストはほとんどのプロジェクトにとって重要ですが、本当に選択する必要がある場合は、要件を使用する必要があります。テストよりも要件を選択する利点の 1 つは、開発者が何を構築する必要があるかを知っているため、開発時間を節約できる可能性があることです。開発に余分な時間がかかっている場合は、その時間をテストに割り当てることができます:)

Answer 10

要件がアーティファクトまたはプロセスと呼ばれているかどうかは不明です。特に小規模なチームの場合、アーティファクトとして要件をスキップして製品を提供することは可能ですが、プロセスとして要件をスキップすることは論外です。アーティファクトとしての要件により、全体を構築するよりも低コストでシステムをモデル化し、実現可能性と見積もりを行い、より大規模でより分散したチームがコミュニケーションのオーバーヘッドを削減し、足元に共通の基盤を持つことができます。要件を無視すると、お粗末な見積もりが得られます (前もって多くの計画を立てるか、短いスプリントを実行するかに関係なく)。実現可能性についての考えが乏しく、おそらく非常に非効率的なコミュニケーションと多くの誤解が生じます。

一方、プロセスとしての要件は、正式に承認されているかどうかに関係なく存在します。本当に除外することはできません。要件プロセスが存在しないふりをしたり、設計、コーディング、テストに統合したり、パイロットやメンテナンスまでの段階に統合したりすることができます。このようにプロセスを扱うことは明らかに、十分な量の注目とリソースを得られないことを意味します. 結果は通常、最終的に役に立たないものを提供することから、開発サイクルの後半で製品の明らかな欠点を修正する必要があること、または製品が現場で失敗したときに実際の要件を発見することまで、開発コストの増加、締め切りの不履行にまで及びます。 、チームの名声を台無しにする、ユーザーの信頼を損なうなど。

テストは通常​​、検証と検証に要約されますが、最近のテスト テクノロジの改善により、自動テストがデバッグの効率を高め、回帰テストに必要な時間を短縮するための確実なツールとして使用できるようになりました。検証とは、チームが適切な製品を構築したことを確認することです。つまり、範囲指定された要件が正しく、矛盾がなく、ギャップがないことを確認します。一方、検証とは、製品が正しく構築されていることを確認することです。技術的な欠陥や偶発的なエラーなどはありません。

ご覧のとおり、要件が無視されたシナリオでは、テストがセーフティ ネットを提供します。通常、チームがテストを開始すると、要件の理解を深め、その結果としてソフトウェアを変更する必要があります。要件アーティファクトとソフトウェア自体の両方が、実際の問題のソリューションをモデル化する際のさまざまなレベルの忠実度を表しているだけであり、モデルとしてのソフトウェアは桁違いに正確であるため、アプリケーションのテストでは要件も評価されます (暗黙的であるか明示的であるかに関係なく)。 、正式に分析された、または非公式に伝達された）。

通常、テストに代わる方法は、ユーザーが大幅に大量の欠陥や欠点を報告し、メンテナンスの一環として (製品ライフサイクルの後半を意味する) 修正を試みることであり、修正ごとのコストが増加します。

では、要件とテストの違いは? マネージャーを解雇します。テスト フェーズ中にプロジェクトのスケジュール スリップが必要な場合は要件をスキップして、ユーザーが必要としているものではないビルドの混乱に陥る必要があります。ユーザーに完全に無礼を示す必要がある場合は、テストをスキップしてください。

Answer 11

要件がなければ、最終的には仕様どおりになるため、テストは必要ありません

Answer 12

要件がなければ、テスト計画を立てることができますか？したがって、要件の代わりにテストを選択した場合でも、テストを行うことはできません。

したがって、アジャイルテスト環境を検討する場合でも、要件を優先する必要があります。

Answer 13

少なくとも電子メールの長さのあいまいに表現されたアイデア以上のもので、要件なしで完全にうまく開発できるソフトウェアのカテゴリがあります。

問題は、特定のクライアントとプロジェクト マネージャーがいる場合、ソフトウェアがその中に含まれている可能性は低いということです。「ジャグリングする猿の楽しいゲームを作って」などと言って、誰かがあなたに特にお金を払っているとは考えにくいでしょう。

テストせずに開発できるソフトウェアの唯一のカテゴリは、フェイルウェアです。あなたの会社は、ソフトウェアが機能するかどうかに関係なく、一部の顧客にお金を払わせることに成功しました (または、本当に馬鹿な顧客がいる場合は、機能しない場合はより多くの料金を支払います。サポートとメンテナンス中)。

おそらくその可能性の方が高いでしょう。失敗よりも成功の​​方が収益性が低くなるように構築された契約は、依然としてかなり一般的です。そうだと思い、動くソフトウェアを開発したいのであれば、自分の利益と上司の対立が少ない仕事に転職することを検討してください。