エンドツーエンドおよび統合テストは、ミッションクリティカルではないものに価値がありますか？

エンドツーエンドのテストと統合テストはコストがかかることはよく知られています。もちろん、問題が発生した場合に人々が死ぬ可能性のあるアプリケーションを開発する場合、それは価値のある投資です。しかし、エラーが世界の終わりではないアプリケーションでは、E2Eテストと統合テストを完全にスキップして、何か問題が発生した場合に代わりにバックアップ計画を作成する方が安くないでしょうか。ユーザーストーリーの手動テスト+単体テスト+静的に型付けされた言語を十分に使用するようなものですか？

たとえば、ウェブストアが注文を失った場合、代わりに無料でアイテムを送って+謝罪として別のアイテムを送ることができます。エンドユーザーはその方法でさらに幸せになる可能性があり、会社全体でコストを節約できます。

私の質問は、一般的に、統合テストとE2Eテストの費用と、それによって節約できる費用はどれくらいかと思います。これについてリスク/コスト計算を行う方法はありますか？

E2Eと統合テストを実装するかどうかは問題ではなく、いずれかの方法でバックアップ計画が必要です。テストされたという理由だけでシステムにバグがないことを期待してはいけません。

したがって、コストの見積もりでは、E2Eテストを実装するためのコストと、障害が発生した場合にバックアッププランが見積もるコストを比較しません。

• E2Eテストを手動で行うためのコスト（数回、新しいリリースごとに）

対

• 自動E2Eテストの構築（および維持）にかかるコスト

これらのE2Eテストを数回使用できる場合は、通常、コストが損益分岐点に達するテスト実行がいくつかあります。これは、手動で実行するE2Eテストと自動化するE2Eテストを事前に計画するときに適用するメトリックです。

簡単に実装できるE2Eテストの種類があり、ROIがすぐに明確になる場合がありますが、開発と保守に数年の期間にわたって手動で行うよりも費用がかかる可能性があるE2Eテストもあります。

おそらく直感的に反するかもしれませんが、自動化されたテストは実際にはテストを行わない場合よりも開発時間を短縮できます。つまり、それは勝利です。

アイデアは、テストがいくつかのレベルで貢献するということです

1. 厳密な要件の収集と仕様を強制する

   これは開発のスピードに大きな影響を与えます。詳細を尋ねたり、誤解したり、不要な機能を要求したりする必要はありません。

2. 開発者は機能がいつ完了するかを知っています

   ほとんどのテストは、テスターが完成品をチェックするのではなく、コードの作成中に開発者によって行われます。このテストを自動化すると、このワークロードが減少します

3. すぐに検出される新機能によって導入されたバグ。

   これらは簡単にスプリントの費用がかかり、検出されない場合は機能全体を書き換える必要があります。

4. より速いリリースサイクル

   これは、実行中のコードが少なくなること、つまりマージが少なくなること、つまり開発者の作業が少なくなり、複雑さが少なくなることを意味します

特に、テストフレームワークの設定がある場合、これらのテストを書くのにかかる時間を節約するよりも時間がかかりません。

さらに、手動でのテスト時間を節約でき、さらに最終的にはより優れた製品を入手できます。

私の答え？おそらく、そうではないでしょう。

EOEテストは、非常に単純な場合に適しています。基本的なシナリオをカバーすることを計画している場合は、EOEテストでいくつかの利点を得ることができます。しかし、本当に複雑で大きなアプリケーション（ミッションクリティカルかどうかにかかわらず）がある場合、このEOEテストは維持にコストがかかり、価値があるかどうかを評価するためのシナリオを知る必要があります。

数年前、Google Testing Blogがこの問題について議論しています。私は作者にのみ同意することができます。優れたテストは、迅速で信頼性が高く、障害を分離する必要があります。これは、EOEテストでは提供できない機能です。

私は、多くのシナリオをカバーする12時間を超えるエンドツーエンドのテストを備えたアプリケーションに取り組みました。最終的には、このテストをさまざまなマシンに分散し、テストの開始、実行、終了を制御し、結果を収集してマージしました。テストされたアプリケーションはモノリスアプリケーション（テストを実行する方が簡単です）であり、テストを維持するのは悪夢でした。

ほとんどの場合、結果からバグを見つけるのではなく、テストを維持していました。エンドツーエンドのテストでバグの原因を発見するには多くの時間がかかります。多くの「偽陰性」テストと、問題を理解して修正するための数時間も処理しました。Javaアプレットの読み込みの問題、ページに予期された要素が見つからない（および自動化速度に関するその他の問題）、クエリコードを維持する（元のクエリはデータベース固有のコードを使用するため）データベースメモリテストでのみ使用されます。

これらすべてには、稼働を維持するための人々が必要です。最後に、一部のEOEテストを削除し、それらを多くの単体/統合テストに置き換えます。

したがって、私の保守的なアドバイスは、Googleのテストピラミッドを使用することです。

最初の推測として、Googleは70/20/10の分割を提案することがよくあります。70％の単体テスト、20％の統合テスト、10％のエンドツーエンドテストです。正確な組み合わせはチームごとに異なりますが、通常はピラミッドの形状を維持する必要があります。

私の経験では、アプリの重要度に関係なく、E2Eテストは常に賢明です。私は常に最悪のシナリオの観点から考えます。もし物事が洋ナシ形になった場合、あなたは経営陣の前に立ち、あなたのアプローチを正当化するのに快適ですか？そうでない場合は、アプローチを変更する必要があります。多くの組織は、テストの重要性とテストに割り当てられるリソースを最小限に抑えていますが、問題が発生した場合、誰もが責任のある人物を探しているので、テストを制限することを決定したり、そのアドバイスをしたりすると、あなたは発砲します。ライン。

ソフトウェア開発では、組織の政治に目を配る必要が出てきます。

「エンドツーエンドのテストと統合テストはコストがかかることはよく知られています。」

私はこの主張に同意しないと思います。

まず、E2Eテストはエンドユーザーにとって重要なものであり、複雑なシステムをテストするための最も時間効率が高く、コストが最も低いオプションとなります。たとえば、誰かが車を買うとき、ほとんどの人はそれをバラバラに引っ張って、分離して炭水化物、ギアボックス、ホイールをテストし始めません。代わりに、彼らはそれを試乗に持って行きます。

第二に、ツールに関しては、E2Eは製品の内部進化を遅くする傾向がなく、より長く持続します。考えてみれば、ほとんどの製品の実際の機能面はそれほど大きく変化することはほとんどありませんが、内部的にはあらゆる種類の開発の影響を受ける可能性があります。その結果、テストツールが稼働すると、通常は非常に良好に持続します。例として、車の例に戻ります。同じ「ドライブに持っていく」テストケースは、テスラと同じようにフォードモデルTでもほとんど機能します。なだらかな道路、風洞、リークテストのセットアップなどへの投資と同様に、内部コンポーネントテストのうち、その寿命全体でこのような優れたROIが得られたのはいくつでしょうか。

E2Eテストがより高価/不適切である傾向があるのは、初期設定であり、すべてのテストに使用する場合です。実用的には、このトラップを回避する最善の方法は、次のことのテストを自動化する優先順位を付けることだと思います。

1. 自動化が容易で、実行を続けるために多くのメンテナンスが必要になることはほとんどありません。
2. 一貫性のある適切な手動テストプロセスを適用するのに最も時間がかかります。
3. 製品が壊れた状態でリリースされた場合、あなたまたはあなたの上司を馬鹿のように見せるリスク。

E2Eを含め、適切と思われるあらゆる形式のテストを使用します。それらに焦点を当てます。

統合テストのコストと、バグが単一の注文のみに影響するベストケースシナリオのコストを実際に比較することはできません。論理的なバグも、多数の注文に影響を与える可能性があります。バグとは、支払いが捕捉されないことを意味します-これは、あらゆるビジネスに悲惨な影響を与える可能性があります。

E2Eテストが行​​われていないために実際に本番環境で発生する可能性がある最悪のバグは何かを尋ねる必要があります。そしてマーフィーの法則を思い出してください。

この質問はエンタープライズWebアプリケーションに関するものだと思います。

中程度のクリティカルなものに対する私の推奨：

• バックエンドAPIの自動テストを実行し、バックエンドが期待どおりに機能することを確認します。これらのテストは、APIの実装中に開発者が作成する必要があります。
• 自動UIテストについては気にしないでください。つまり、フロントエンドテストを手動で行います。

ほとんどのテストはAPIレベルまたはコンポーネントレベルで行う必要があると思います。一部の内部関数のみを実行している単体テストは気にしません。