システム自体の実装よりも機能テストの実装により多くの時間を費やしていますが、これは正常ですか？
基本的に、3つの主要なプロジェクトがあり、そのうちの2つはWebサービスで、もう1つはWebアプリケーションです。機能テストで3つのWebサービスをできる限りカバーすることに満足していますが（3つのプロジェクトすべてに適切な単体テストがあります）、Webアプリケーションの機能テストは実装に多くの開発時間を費やしています。多くの場合、ユニットテストを含めてテストされる機能を実装するのにかかる時間の2倍、場合によってはそれ以上の時間を意味します。
マネージャーのポリシーは、ビジネスに重要でない場合（つまり、新しいC.R.U.D）であっても、追加するすべての機能をテストすることです。
Webサービスのすべての機能をテストすることに同意します。手動でテストするのは困難です。また、このテストは高速に実行され、実装にあまり時間をかけません。
では、システムコード、ユニットテスト、QAチケットの修正よりも、機能テストの作成に多くの時間を費やすことの価値は何でしょうか。これは正常ですか？重要な機能に対してのみ機能テストを記述し、重要な機能がない場合にQAが回帰テストを実行できるようにしないでください。
注：私たちは医療用ソフトウェアやNASAソフトウェアを開発しているわけではありません。
機能テストは非常に重要です。はい、それらは書くのに時間がかかりますが、適切な機能テストを書いている場合、それらはそれだけの価値があります。
アプリケーションで自動機能テストを行うには、いくつかの理由があります。
- 新しい機能がWebサイトに追加されると、その新しい機能に加えられた変更がサイトの他の機能に影響を与えるかどうかがすぐにわかります。
- これは、ビジネス要件を達成するためにアプリケーションがどのように実行および機能するかについての文書化された知識です。
- サードパーティライブラリを更新するときは、ライブラリを更新して機能テストスイートを実行し、破損していないかどうかを確認できます。自分ですべてのページを通過する必要はなく、コンピュータに実行させて、失敗したすべてのテストのリストを提供できます。
- 負荷テスト！一度に何千人ものユーザーが同時にサイトにアクセスするのをシミュレートでき、プレッシャーのもとでサイトの速度が低下して座屈する場所を確認できます。 Webサイトがクラッシュしたという深夜の電話を受ける前に、Webサイトの動作を確認できます。
- 機能テストは手動で行うには時間がかかります。はい、ケースを書くのに長い時間がかかりますが、500ページのテストを備えたバインダーに座って、製品を出荷する前に完了する必要があった場合は、自動テストが必要です。
- テストドキュメントはすぐに古くなります。新しい機能が追加されたら、必ずマスターテストドキュメントを更新する必要があります。誰かがいくつかのテストをスキップすると、突然、「完了してテスト済み」のページにバグが忍び寄ります。私は現在そのような環境で働いており、間違いなく悪夢です。
結局のところ、そうしたケースを書くのには時間がかかりますが、誇りを持って書く必要があります。これは、コードが機能し、そこにある他のすべての機能で機能することを疑う余地のない、証明の方法です。 QAが来てバグがあると言ったら、それを修正し、それをテストスイートに追加して修正されたことを示し、それが二度と起こらないことを確認します。
それはあなたの安全策です。誰かが入ってストアドプロシージャをハイジャックし、コードで動作するように小さな変更を加えると、プロセス内の他の3つの機能が壊れていることに気付くでしょう。締め切り前の夜ではなく、その夜に捕まります！
システムの重要な機能のみの機能テストを書くことに関して。これで全体像がわかるわけではなく、バグが潜入する可能性があります。必要なのは、システムクリティカルではないが、システムクリティカルな機能と間接的に相互作用する1つの小さな機能を追加することだけであり、バグが発生する可能性があります。
2回以上...私には少し多く思われます。これの理由を分析する必要があるかもしれません、それらは含めることができます：
テストの作成とメンテナンスのための悪いツールのサポート
webサービスの契約は、設計で十分に説明されていません。開発者はテスト中に契約を作成する必要があります。これは通常、時間のかかる調整プロセスです。
開発者に相談してください。
あなたがスプリントで開発していると仮定して、スプリントの一部である場合にこれらの機能テストを行います。これらのテストなしではそれはできません。それがない場合、開発フェーズ後の統合テストの時間が2倍になる可能性があります。
システム自体の実装よりも機能テストの実装により多くの時間を費やしていますか？
もちろんです。本当に良いテストを書くことは、多くの（良い）ショップでほとんどの時間を費やす可能性があります。
したがって、2-1の比率で問題ありません。経験の浅い開発者自身は、多くの場合、テストに時間を費やしていません。
利益を減少させる法則があります。最もリスクの高いコードのテストを最初に作成すると、その後のテストで生成される値は時間とともに減少します。
単体テストはコードであるため、（他のすべてのコードと同様に）バグが含まれます。これらのバグの修正には時間がかかります。
私の経験では、単体テストにはテスト対象のシステムよりもはるかに多くのバグが含まれており、これらの修正は継続的な負担です。
これは品質についてです。
市場を獲得する必要がある場合は、できるだけ早くアプリを開発します。自動テストをまったく行わないこともできます=）が、競合他社より先にアプリを聴覚に渡します。
しかし、あなたの聴覚が消えないことを知っているなら、あなたはそれらを失望させないためにあなたができることは何でもします。すべてのバグチケットはあなたの評判を落とします。 1つのバグがあなたの評判の50％を削除し、次のバグがさらに25％になると想像してみてください。では、テストが多すぎるのでしょうか？
「それは正常ですか」によって、それが一般的であるかどうかを尋ねる場合、いいえ、それは確かではありません。多くの開発チームは、テストプラクティスが不十分です（私は1つに属しています）。品質の高い本でも、テストよりも機能のコーディングにほぼ同じ時間を費やすようにアドバイスを読んでいます。正常であるかどうかを問う場合、それは状況によって異なりますが、必要なテストの2倍多いテストは、テストがないよりも優れています。
criticalである必要はありません。機能をテストするときは、エンドユーザーに対して便利をテストします。常に正しく機能していることを（推測ではなく）把握するのはユーザーの責任です。その目的のために2倍以上必要な場合は、その方法で実行する必要があります（可能な場合）。
また、自動化されたテストについてポリシーが厳しすぎる可能性もありますが、彼らが目指している品質、そのリソース、および他に何を配置できるかを知らなければ、判断するのは困難です。