自動テスト：そのビジネス価値の説明

私はこれがあるとは思いません起動するには、繰り返しの他の質問にユニットテスト。私が助けを求めているのは、プログラマー、アナリスト、マネージャー、テスターのチームにその価値を明確にすることです。自動テストでは、ユニットテスト（JUnitなど）、BDD（JBehave、Fitness）、UI（Selenium、Watir）を区別する必要はないと思います。同意しない答えを書いてください:)）

以下は私が特定したリストです。拡張または改善に役立つ答えを探しています：

1. 時間/コストの節約：自動化されたテストの作成は、テストケースの作成よりも時間がかかる場合があります。ただし、テストが複数回実行されることを考慮すると、自動テストを実行するためのわずかな作業（コスト/時間）が数桁少なくなります。自動テストの実行が安価であることは、時間の経過に伴うシステムの変更を促進します。
2. ドキュメンテーション：システムがどのように機能するかを知るためのより正確な方法は、テストよりもありません。他のドキュメントは、通常、作成された時点では古くなっていますが、テスト（少なくとも合格したもの）により、実際の動作が明らかになります。これは、エンドユーザーおよびAPIドキュメントの両方に当てはまります。
3. コード品質：テスト作成により、次のことが強制されます。
   • テストはクライアントであるため、クライアントを考慮する
   • コードをテスト可能にすることは、多くの場合、他の大規模システムを必要としないコードを作成する方法を見つけ出すことを意味します。

私の考えのいくつか：

1. 正直なところ、自動テストの作成にはさらに時間がかかります。ユニットレベルのTDDを実行している場合（自動テストに投資する場合の出発点としてお勧めします）、機能のコーディングに約30％の余分な時間が必要になります。ここで重要なのは、この余分な30％（チームが適切なテストの作成方法を学習しているため、最初はおそらく30％を超える）が、時間をかけてコストを節約するために構築された投資であることを説明しています。少なくともユニットレベルのTDDでは、システムの設計は疎結合であり、凝集性が高いため、時間の経過に応じてシステムを適応させることができます。新しい要件と予期しないバグには、常にシステムの変更が必要です。
2. これらのテストの記述にかかる時間、テストの実行にかかる時間、および必要なメンテナンスの量を考えると、承認レベルとUIレベルのテストの価値については多くの議論があります。これについては、James Shoreによるこの記事を読むことをお勧めします。
3. 自動テストの世界には、それを行う良い方法と悪い方法があります。自動化されたテストを経営陣に提案している場合、優れたテストを作成するためのチームのトレーニングを計画する方法を提案します。Roy Osheroveによる単体テストの芸術、Michael Feathersによるレガシーコードの効果的な使用、James Shoreによるアジャイル開発の芸術はすべて、これらのトピックを直接的または間接的に扱っている素晴らしい本です。また、何らかのコーチまたは正式なトレーニングも検討する必要があります。それは大きな変化です。
4. ビジネスバリューについては、上記の2番目と3番目のポイントが実際に最初のポイントになります。したがって、1番目のポイントに戻って、2番目と3番目がその大きなポイントにどのように役立つかを説明します。ドキュメントはシステムをより理解しやすくし、チームの作業を高速化します。コード品質により、システムを変更に適応させ、チームの作業を高速化できます。ビジネスマンにとって、それはすべて、アイデアが提案されてからアイデアが実用的なソフトウェアとして提供されるまでの価値の流れを最大化することです。

明確な価値があることの1つは、自動化テストを継続的に実行できることです。1時間ごとなどの再構築など。これを行うと、プログラマーが問題のコードに取り組んでから数時間または数日以内に、バグやリグレッションが急速に公開され、コンテキストの切り替えがはるかに簡単になります。継続的なテストの2番目の利点は、テストを動作状態に保つことを強制することです。古くなったすべてのテストを修正するテストサイクルの最初の週を費やすことほど退屈ではありません。それらを自動化できる場合は、いつでも実行できます。定期的に実行することで、テストまたはコードのバグをすばやくキャッチできます。

試験費用

自動テストが作成されると、数ジュールのコストでコンピューターで実行できます。同等の手動テストでは、給与の人が指示のリストを作成する必要があります。

テストの信頼性

コンピュータは、毎回同じテスト手順を忠実に実行すると信頼できます。人間は間違いを犯して怠けがちです。

コンピューターのテスト失敗モードも非常に簡単にわかります-クラッシュ（テストレポートが表示されなくなる）、誤ったテスト結果を引き起こすビットエラーがありました（確定的なテストを再度実行すると、結果が異なります）。人間がステップを逃して「OK」をチェックオフした場合、どうすればわかりますか？

試験耐久性

自動テストは、実行するために具体的なアーティファクト（コードなど）である必要があり、他のソフトウェア開発アーティファクト（ソースリポジトリ）に当然含まれています。手動テストは、テスターに​​よってメモ用紙に作成され、正式化されることはありません。ビジネスは、それが起こらないことを保証するために、適切なプロセスを必要とする可能性が高くなります。

試験値

コンピューターは、テスト結果を一貫した簡単に分析できる形式で出力するようにプログラムできます。その人は、同じものを生成するためにデータ入力を行っているか、分析するためにアナリスト、開発者、または管理者を必要とする自由形式のメモを記録しています。

ほとんど（テストカバレッジに応じて）バグのないコード。最大の議論の1つは、マネージャーに、発見されたバグのテストを書くことができると言うときです。そのバグが戻ってきます:)

私の意見では、ユニット/統合テストが最も重要ですが、MVCのようなUIパターンを適用すれば、ほとんどのプロジェクトで十分です。通常、コントローラー/プレゼンターですべてのアクションをテストし、データバインディングをビューに任せます。

もちろん、自動化されたテストは、ユーザーが実行できる最もワイルドなことを見つけようとするアプリケーションの古き良きポイントアンドクリックアドベンチャーに代わるものではありません。

継続的インテグレーションのポイントもあります。

もう1つ-コードの品質が製品の品質、ビジネス価値、および保守性につながるように努力する必要があります-そうでなければ、それを行う意味はありません。

「低コスト」と「機能/ユニット時間の増加」/サイクル時間の短縮というマジックポイントでリードすべきだと思います。

ただし、ケースを作成する前に、あなたの状況を振り返ることをお勧めします。あなたの質問から、自動テストの潜在的な短所に関するブログ記事を書くことになりました。

ここでは、リファクタリングの容易さが大きな要因です。素晴らしく読みやすい（!!!）単体テストで十分にカバーされているので、既存の機能を損なうことを気にせずにシステムをリファクタリングできます。

コンセプトを売り込む必要があります。コードを改善することを伝えないようにする必要があります。コードに投資していて、すぐにアンチユー/自動テストが行​​われる場合。彼らが良ければ、彼らはGIGOも理解するので、あなたがそれが当てはまらないと思う理由を理解しません。

ドキュメンテーションの側面としても販売していません。Fitnesseのようなものはそれをうまくやることができますが、経験するまで視覚化するのは難しいかもしれません。

それを売る運があるかもしれないと思う地域

1. ユニットテストは、多くの開発者ハーネスの代わりに使用できます。すべてのログイン/メニューを経由せずに、デバッグ/テストする領域に到達するためだけにアプリケーションを作成します。

2. テストでは、テストデータのセットアップに多くの時間を費やすことなく、問題の状況をセットアップして簡単に繰り返すことができます（特にまともなモックシステムを使用）

3. BDDおよびUIテストのスイートを構築すると、テスターが次にそれを見るのを待つよりも、単純な中断がある場合にはるかに迅速な応答が得られます

4. BDDおよびUIテストでは、ボタンを繰り返し押すことで、変更の影響を受ける可能性のあるすべての側面を確認し、すべての領域を覚えておく必要がなくなります。

5. 自動ビルドは、誰かがコードをチェックインするのを忘れたことを強調することがよくあります

6. テストは、バグの再発を防ぐのに役立ちます。

7. 単体テストとまともなモッキングは、相互リンクされたコードが少なくなり、解決が容易になることを意味します

宗教に変えるのではなく、販売しようとしていることを忘れないでください。小さなステップを受け入れて、反抗的なものにならないようにしてください。また、彼らが調整して良いテストを書くことを学ぶには時間がかかります。

誰かが問題に対して提案された解決策を受け入れる前に、問題があると信じなければなりません。

自動テストはバグ修正のコストを節約できるため、同僚がバグ修正のコストがかなり大きいまたは過剰であると思わない場合、納得するのは困難です。それらのコストが高いか、または過剰であるが、人々がそうであると信じていない場合、最初にそれらのコストに関するいくつかの説得力のあるデータを取得する必要があります。

企業が愛しているのは、価値を高め、コストを削減することです。自動テストは追加のコストを追加するため、どのように価値を高めるかを説明する必要があります。

コードがモジュール式の場合、コードを再利用できます。つまり、テストを何度も記述する必要はなく、既存のコードの上で作業するだけで済みます。

レガシープロジェクトがある場合、自動テストによりリファクタリングがはるかに簡単になります。技術的な負債はある時点で返済されなければなりません。

あなたが提供するドキュメントの議論はあまり良くありません。テストを最新の状態に保つこととドキュメントを最新の状態にすることの違いは、習慣にすぎません。

「私が助けを求めているのは、プログラマー、アナリスト、マネージャー、テスターのチームにその価値を明確にすることです。自動テストでは、単体テスト（JUnitなど）、BDD（たとえば、JBehave、Fitness）とUI（Selenium、Watir）はすべて同じような価値を提供していると思うからです（ただし、反対の答えは自由に書いてください:)）」

OK、私はその挑戦を受けます;）

私は主にプログラマーとQAを使用し、ツールはルビー、レール、テストユニット、rspec、ジャスミン、セレンです。

rspecおよびtestunitのBDD / TDDツールはプログラミングの一部です。それらを解体して経営陣に個別に話したり、時間不足のために延期したりせず、すべての時間の見積もりに含めます。本当にプッシュされたら、コンピューターサイエンスとプログラミングについて説明するのにどれだけの時間があるのか​​尋ねられます。これらのテストはフロントエンドには使用しません

GUI / UI / Jasmine / Selenium。これらは異なります。これらは、プログラマーのバックグラウンドを持つQAの人々によって行われました。テストは、できるだけ堅牢で、レイアウトではなくコンテンツに基づいて作成されるようにします。この（おそらく新しい）コストは、シフトされたコストとして説明する必要があります。壊れたソフトウェア、失われた顧客、高価な修正プログラムを後で支払う代わりに、いくつかの簡単なプラクティスを行うことで、（比較的）はるかに少ない料金を支払うことができます。

重要なのは、「自動テスト」全体ではなく、作成するテストの特定のカテゴリについて話すことだと思います。後者は少し曖昧で心配になる可能性があり、時間の無駄になる場所の例を見つけるのはあまりにも簡単です。

テストを4つのグループに分割することを常にお勧めします（詳細はこちら）。ここで私に固執してください、私はこれがあなたがすぐに他の人にテストを売るのにどのように役立つかを得ます。

1. コア機能のテスト。つまり、Webサイト監視ツールの場合、これは監視しているWebサイトに対して起動するアラートのテストになります。これらのテストは、これらが壊れないことを確認します。
2. アプリケーション全体のテストを煙します。たとえば、Seleniumを使用してWebアプリ内のすべてのリンク/ボタンをナビゲートし、サーバーからのエラーがないことを確認します。これらのテストにより、明らかに壊れたビルドでテスターの時間を無駄にすることがなくなります。
3. 壊れやすいコードのテスト。つまり、誰も触りたくない古いモジュールや、常にバグがあると思われる複雑なコードです。
4. 開発者が作業をサポートするために記述したかったテスト。何かを書いているときにテストが役立つこともありますが、上記のカテゴリに該当しないためです。

テストをこれらのカテゴリに分割することで、異なる議論をすることができます。最初の3つのグループ（4番目は個人の裁量によるものです）を取り、それらのコードのテストが価値があると人々が考えているかどうかを尋ねますか？同意が得られない場合は、現時点ではこれらのテストを含めないでください。可能であれば、つまり、各コミットで実行されるコア機能に関するテストが有用であると人々が同意した場合、それらを追加し始めます。

有用な他のグループは手作業で行うのが難しいか時間がかかるテストです。ここでは、手動テストの時間を節約したり、時間がないためにテストがスキップされたりするという点で、非常に簡単に説明できるメリットがあるはずです。