エンドツーエンドおよび統合テストは、ミッションクリティカルではないものにとって価値がありますか？
エンドツーエンドのテストと統合テストはコストがかかることはよく知られています。もちろん、問題が発生した場合に人々が死ぬ可能性のあるアプリケーションを開発する場合、それは価値のある投資です。しかし、エラーが世界の終わりではないアプリケーションでは、E2Eテストと統合テストを完全にスキップして、何か問題が発生した場合に代わりにバックアップ計画を作成する方が安くないでしょうか。ユーザーストーリーの手動テスト+単体テスト+静的に型付けされた言語を十分に使用するようなものですか？
たとえば、Webストアが注文を失った場合、代わりに無料でアイテムを送って、謝罪として別のアイテムを送ることができます。エンドユーザーはその方法でさらに幸せになるかもしれませんし、会社は全体的にお金を節約します。
私の質問は、一般的に、統合テストとE2Eテストの費用はいくらで、どれだけの費用が節約できるのでしょうか。これについてリスク/コスト計算を行う方法はありますか？
E2Eと統合テストを実装するかどうかは関係ありませんいずれにしてもバックアップ計画が必要です。テストされたという理由だけで、システムにバグがないことを期待しないでください。
したがって、コストの見積もりでは、E2Eテストを実装するためのコストと、障害が発生した場合にバックアッププランが見積もるコストを比較しません。
- E2Eテストを手動で行うためのコスト（数回、新しいリリースごとに）
vs.
- 自動E2Eテストの構築（および維持）にかかるコスト
これらのE2Eテストを数回使用できる場合は、通常、コストが損益分岐点に達するテスト実行がいくつかあります。これは、手動で実行するE2Eテストと自動化するE2Eテストを事前に計画するときに適用するメトリックです。
簡単に実装できるE2Eテストの種類があり、ROIがすぐに明確になる場合がありますが、開発と保守が数年の期間にわたって手動で行うよりも費用がかかる可能性があるE2Eテストもあります。
おそらく直感的に反するかもしれませんが、自動化されたテストは、テストを行わない場合よりも実際に開発時間を短縮できます。ですから、それは勝利です。
アイデアは、テストがいくつかのレベルで貢献するということです
厳密な要件の収集と仕様を強制する
これは開発のスピードに大きな影響を与えます。詳細を尋ねたり、誤解したり、不要な機能を要求したりする必要はありません。
開発者は機能がいつ完了するかを知っています
ほとんどのテストは、テスターが完成品をチェックするのではなく、コードの作成中に開発者によって行われます。このテストを自動化すると、このワークロードが減少します
すぐに検出される新機能によって導入されたバグ。
これらは簡単にスプリントの費用がかかり、検出されない場合は機能全体を書き換える必要があります。
より速いリリースサイクル
これは、実行中のコードが少ないこと、つまりマージが少ないこと、つまり開発者の作業が少なくて済み、複雑さが少ないことを意味します
特に、テストフレームワークの設定がある場合、これらのテストを書くのにかかる時間を節約するよりも時間がかかりません。
さらに、手動のテスト時間を節約でき、さらに最終的にはより優れた製品を入手できます。
私の答え？ たぶん、おそらくそうではありません。
EOEテストは、非常に単純な場合に適しています。基本的なシナリオをカバーすることを計画している場合は、EOEテストでいくつかの利点を得ることができます。しかし、本当に複雑で大きなアプリケーション（ミッションクリティカルかどうかに関係なく）がある場合、このEOEテストは維持にコストがかかり、価値があるかどうかを評価するためのシナリオを知る必要があります。
数年前 Google Testing Blogがこの問題について議論しています。著者に同意することしかできません。 fast、reliable、障害を特定する、EOEテストでは提供できない機能。
私は、多くのシナリオをカバーするエンドツーエンドテストが12時間以上あるアプリケーションで作業しました。最終的には、このテストをさまざまなマシンに分散して、テストの開始、実行、終了を制御し、結果を収集してマージしました。テストされたアプリケーションはモノリスアプリケーション（テストを実行する方が簡単です）であり、テストを維持するのは悪夢でした。
ほとんどの場合、結果からバグを検出するのではなく、テストを維持していました。エンドツーエンドのテストでバグの原因を発見するには、かなりの時間がかかります。また、多くの「false-negative」テストを処理し、問題を理解して修正するための時間を少しだけ取りました：Javaアプレットの読み込みの問題、ページに予期された要素がありません（および自動化速度に関する他の問題）。 （元のクエリはデータベース固有のコードを使用しているため）データベースメモリテストで使用されるクエリコードを維持します。
これらすべてには、稼働を維持するための人々が必要です。最後に、一部のEOEテストを削除し、多くの単体/統合テストに置き換えます。
したがって、私の保守的なアドバイスは、Googleのテストピラミッドを使用することです。
最初の推測として、70/20/10の分割を提案することがよくあります。70％の単体テスト、20％の統合テスト、10％のエンドツーエンドテストです。正確な組み合わせはチームごとに異なりますが、通常はピラミッドの形状を維持する必要があります。
統合テストのコストを、バグが単一の注文にのみ影響する最良の場合シナリオのコストと実際に比較することはできません。論理的なバグも、多数の注文に影響を与える可能性があります。バグとは、支払いが捕捉されないことを意味します。これは、ビジネスに壊滅的な影響を与える可能性があります。
最悪の場合バグとは何かを尋ねる必要があります。これは、E2Eテストが行われていないために実際には本番環境で発生する可能性があるバグです。そしてマーフィーの法則を思い出してください。
この質問はエンタープライズWebアプリケーションに関するものだと思います。
中程度のクリティカルなものに対する私の推奨：
- バックエンドAPIの自動テストを実行し、バックエンドが期待どおりに機能することを確認します。これらのテストは、APIの実装中に開発者が作成する必要があります。
- 自動UIテスト、つまりフロントエンドテストを手動で実行する必要はありません。
ほとんどのテストはAPIレベルまたはコンポーネントレベルで行う必要があると思います。一部の内部関数のみを実行している単体テストは気にしません。
私の経験では、アプリの重要度に関係なく、E2Eテストは常に賢明です。私は常に最悪のシナリオについて考えます。もしもナシの形になったら、経営陣の前に立ち、あなたのアプローチを正当化できますか？そうでない場合は、アプローチを変更する必要があります。多くの組織はテストの重要性とリソースの割り当てを最小限に抑えていますが、問題が発生した場合、誰もが責任のある人物を探しているので安心してください。ライン。
ソフトウェア開発は、組織の政治に目を向ける必要があります。
"エンドツーエンドおよび統合テストはコストがかかることはよく知られています。"
私はこの主張に同意しないと思います。
第一に、E2Eテストはエンドユーザーにとって重要なことであり、複雑なシステムをテストするための最も時間効率が高く、コストが最も低いオプションとなります。たとえば、誰かが車を購入するとき、ほとんどの人はそれをバラバラにして、炭水化物、ギアボックス、ホイールを単独でテストし始めません。代わりに、彼らはそれをテストドライブに持っていきます。
第二に、ツールに関しては、E2Eは製品の内部進化を遅くする傾向がなく、より長く持続します。考えてみれば、ほとんどの製品の実際の機能面はそれほど大きく変化することはほとんどありませんが、内部的にはあらゆる種類の開発の影響を受ける可能性があります。その結果、テストツールが稼働すると、通常は非常に良好に持続します。例として、車の例に戻ります。同じ「ドライブに持っていく」テストケースは、テスラと同様にフォードモデルTでもほとんど機能します。なだらかな道路、風洞、リークテストのセットアップなどへの投資と同様に、内部コンポーネントのテストのうち、ライフスパン全体でこのような優れたROIが得られたのはいくつでしょうか。
E2Eテストがより高価/不適切である傾向があるのは、初期設定であり、それを使用してすべてをテストする場合です。実用的には、このトラップを回避する最善の方法は、次のようなもののテストを自動化する優先順位を付けることだと思います。
- 自動化が簡単で、実行を続けるために多くのメンテナンスが必要になることはほとんどありません。
- 一貫性のある適切な手動テストプロセスを適用するのに最も時間がかかります。
- 製品が壊れた状態でリリースされた場合、あなたまたはあなたの上司を馬鹿のように見せるリスク。
E2Eを含め、適切と思われるあらゆる形式のテストを使用します。それらに焦点を当てます。