システム自体の実装よりも機能テストの実装に多くの時間を費やしていますが、これは正常ですか？

基本的に、3つの主要なプロジェクトがあり、そのうちの2つはWebサービスで、もう1つはWebアプリケーションです。機能テストでWebサービスをできる限りカバーすることに満足していますが（3つのプロジェクトすべてに適切な単体テストがあります）、Webアプリケーションの機能テストの実装には多くの開発者時間がかかります。多くの場合、ユニットテストを含めてテスト対象の機能を実装するのにかかる時間は2回、場合によってはそれ以上になります。

マネージャーのポリシーは、ビジネスクリティカルではない場合（つまり、新しいCRUD）でも、追加するすべての機能をテストすることです。

すべてのWebサービス機能をテストすることに同意します。手動でテストするのは難しく、また、このテストは高速で実行され、実装するのにそれほど時間がかかりません。

それでは、システムコードの作成、単体テスト、QAチケットの修正よりも、機能テストの作成に多くの時間を費やすことの価値は何でしょうか。これは正常ですか？重要な機能についてのみ機能テストを作成し、重要な機能がない場合にQAに回帰テストを行わせてはいけませんか？

注：医療ソフトウェアやNASAソフトウェアを開発しているわけではありません。

機能テストは非常に重要です。はい、彼らは書くのに時間がかかりますが、あなたが正しい機能テストを書いているなら、彼らはそれ以上の価値があるでしょう。

アプリケーションで機能テストを自動化するのには、いくつかの正当な理由があります。

• Webサイトに新しい機能が追加されると、その新しい機能に加えられた変更がサイトの他の機能を損なうかどうかをすぐに知ることができます。
• アプリケーションがどのように実行され、連携してビジネス要件を達成するかについての文書化された知識。
• サードパーティライブラリを更新するときは、それを更新して機能テストスイートを実行し、何かが壊れていないかどうかを確認できます。すべてのページを自分で確認する代わりに、コンピューターに実行してもらい、壊れたすべてのテストのリストを提供することができます。
• 負荷テスト！何千もの同時ユーザーがすべて同時にサイトにアクセスすることをシミュレートでき、サイトがどこで遅くなり、プレッシャーの下で座屈するかを確認できます。サイトがクラッシュしたという深夜の電話を受ける前に、Webサイトの動作を確認できます。
• 機能テストを手動で行うには時間がかかります。はい、ケースを書くのに時間がかかりますが、製品を出荷する前に完了しなければならない500ページのテストを含むバインダーと一緒に座っていなければならなかった場合、自動テストが必要です！
• テスト文書はすぐに古くなってしまいます。新機能が追加されたら、必ずマスターテストドキュメントを更新する必要があります。誰かがいくつかのテストをスキップすると、突然「完了してテスト済み」のページにバグが忍び寄ることになります。私は現在そのような環境で仕事をしていますが、それは悪夢です。

最後に、はい、これらのケースを書くには時間がかかりますが、それらを書くことに誇りを持つべきです。あなたのコードが動作し、そこにある他のすべての機能で動作することは疑う余地がありません。QAが来てバグがあると言ったら、それを修正し、それをテストスイートに追加して修正されたことを示し、それが二度と起こらないようにします。

それはあなたの安全策です。誰かが入ってストアドプロシージャをハイジャックし、彼らのコードで動作するように小さな変更を加えると、プロセス内の他の3つの機能が壊れていることがわかります。締め切り前の夜ではなく、その夜にキャッチします！

システムの重要な機能のみの機能テストを作成する場合。それはあなたに全体像を与えないだろうし、それはバグがこっそり通過できるようになります。必要なのは、システムクリティカルではないが、システムクリティカルな機能と間接的に相互作用する小さな機能を1つ追加するだけで、バグが発生する可能性があります。

2回以上...私には少し多くのようです。この理由を分析したい場合があります。それらには以下が含まれます。

• テストの作成と保守に対するツールのサポートが悪い

• Webサービスの契約は、設計で十分に説明されていません。開発者はテスト中に契約を作成する必要がありますが、これは通常時間のかかる調整プロセスです。

開発者に相談してください。

あなたがスプリントで開発していると仮定し、スプリントの一部である場合、これらの機能テストを行います。これらのテストなしでは完了していません。持っていない場合、開発フェーズ後の統合テストの時間は2倍になる可能性があります。

システム自体の実装よりも機能テストの実装に多くの時間を費やしていますか？

絶対に。本当に良いテストを書くことは、多くの（良い）ショップで大部分の時間を要するでしょう。
したがって、2-1の比率で十分です。経験の浅い開発者自身は、多くの場合、テストにすべての時間を考慮しません。

収益の減少の法則があります。最もリスクの高いコードのテストを最初に作成すると、その後のテストで生成される値は時間とともに減少します。

単体テストはコードであるため、バグが含まれます（他のすべてのコードと同様）。これらのバグを修正するには時間がかかります。

私の経験では、単体テストにはテスト対象のシステムよりもはるかに多くのバグが含まれており、これらの修正は継続的な負担です。

これは品質に関するものです。

市場に参入する必要がある場合は、できるだけ早くアプリを開発します。自動テストをまったく行わないこともできます=）が、競合他社よりも前に聴覚にアプリを提供します。

しかし、あなたの聴覚が消えないことを知っているなら、あなたはそれらを失望させないためにあなたができることを何でもするでしょう。すべてのバグチケットはあなたの評判を落とします。1つのバグで評判の50％が削除され、次のバグでさらに25％が削除されると想像してください。テストが多すぎる可能性はありますか？

「それは普通ですか」でそれが一般的かどうかを尋ねる場合、いいえ、それは確かにそうではありません。多くの開発チームは、テストプラクティスが貧弱（私は1つに属します）であり、テストよりも機能のコーディングに大体の時間を費やすようにアドバイスを読んだ質の高い本ですらあります。通常は健全かどうかを尋ねる場合は依存しますが、必要なテストの2倍のテストがテストなしよりも優れています。

批判的である必要はありません。機能をテストするときは、エンドユーザーに役立つ何かをテストします。常に正しく動作していることを（推測ではなく）知るのはあなたの責任です。その目的のためにさらに2倍が必要な場合は、可能であればその方法で行う必要があります。

また、ポリシーが自動化されたテストに対して見た目が厳しすぎる可能性もありますが、目標とする品質、リソース、その他の割り当て先がわからないことを伝えるのは困難です。