自動テスト：そのビジネス価値の説明
開始するには、これは 繰り返し他の質問 の 単体テスト ではないと思います。私が助けを求めているのは、プログラマー、アナリスト、マネージャー、テスターのチームにその価値を明確にすることです。自動テストでは、ユニットテスト（JUnitなど）、BDD（JBehave、Fitnessなど）、UI（Selenium、Watirなど）を区別する必要はないと思います。これらはすべて同様の値を提供すると思います（ただし、お気軽に同意しない答えを書いてください:)）
以下は私が特定したリストです。拡張または改良に役立つ回答を探しています。
- 時間/コストの節約：自動テストの作成には、テストケースの作成よりも時間がかかる場合があります。ただし、テストが複数回実行されることを考慮すると、自動テストexecuteを実行するための限界作業（つまり、コスト/時間）は数桁少なくなります。自動化されたテストの実行が安価であることは、時間とともにシステムを変更することを容易にします。
- Documentation：システムがどのように機能するかを知るための真の方法は、そのテストよりもありません。他のドキュメントは通常、作成された時点で古くなっていますが、テスト（少なくとも合格したもの）により、実際の動作が明らかになります。これは、エンドユーザーとAPIドキュメントの両方に当てはまります。
- コード品質：テスト書き込みでは、次のことを強制されます：
- テストはクライアントであるため、クライアントを検討する
- 多くの場合、コードをテスト可能にすることは、他の大規模システムを利用可能にする必要がないコードを作成する方法を理解することを意味する依存関係を壊します
私の考えのいくつか：
- 自動テストの作成には時間がかかることを正直に言ってください。ユニットレベルのTDD（自動テストに投資する場合の出発点としてお勧めします）を実行している場合、機能のコーディングに必要な時間は約30％長くなると予想できます。ここで重要なのは、この追加の30％（チームが適切なテストの書き方を学ぶため、最初は30％より高いと思われます）は、時間をかけてコストを節約するために構築された投資であることを説明しています。少なくともユニットレベルのTDDの場合、システムの設計は疎結合で高度にまとまりがあり、システムが時間の経過に伴う変化に適応できるようになります。新しい要件と予期しないバグは常にシステムの変更を必要とするため、システムを簡単に（TDDから取得したNice設計から）変更せず、安全（システムを継続的に検証する一連の自動テスト）の状態に保つことは、これらの変更を行うための費用が少なくなります。
- これらのテストの作成にかかる時間、テストの実行にかかる時間、および必要なメンテナンスの量を考えると、受け入れレベルとUIレベルのテストの価値については多くの議論があります。これについては、James Shoreによる この記事 をお勧めします。
- 自動テストの世界には、それを行う良い方法と悪い方法があります。自動化されたテストを管理職に売り込む場合は、チームに優れたテストを作成するトレーニングをどのように計画するかを一緒に売り込みます。 Roy Osheroveによるユニットテストのアート、Michael Feathersによるレガシーコードの効果的な使用、James Shoreによるアートのアジャイル開発は、これらのトピックを直接または間接的に扱う優れた書籍です。また、ある種のコーチや正式なトレーニングも検討する必要があります。それは大きな変化です。
- ビジネスバリューの観点から、上記のポイントの＃2と＃3が実際に最初のポイントを提供するので、ポイント＃1で家にハンマーで打って、＃2と＃3がそのより大きなポイントを提供する方法について話します。ドキュメンテーションにより、システムがより理解しやすくなり、チームの作業が速くなります。コード品質により、システムを変更に適応させることができるため、チームの作業が速くなります。ビジネスマンにとって、それはアイデアが提案されてからアイデアが実用的なソフトウェアとして提供されるまでの価値の流れを最大化することです。
明確な価値の1つは、自動テストを継続的に実行できることです。再構築などの毎時など。これを行うと、バグやリグレッションがプログラマーが問題のコードに取り組んで数時間または数日以内に迅速にオープンになり、コンテキストの切り替えがはるかに容易になります。継続的なテストの2番目の利点は、テストを実行状態に保つことを強制することです。古くなったすべてのテストを修正するテストサイクルの最初の週を費やすことほど退屈なことはありません。それらを自動化できれば、いつでも実行でき、定期的に実行することで、テストやコードのバグをすばやくキャッチできます。
テスト費用
自動テストが作成されると、数ジュールのコストでコンピュータで実行できます。同等の手動テストでは、給与の担当者が指示のリストを作成する必要があります。
テストの信頼性
コンピュータは、毎回同じテスト手順を忠実に実行することを信頼できます。人間は間違いを犯し、怠惰になりがちです。
コンピューターのテストの失敗モードも、はるかにすぐにわかります-クラッシュし（テストレポートが表示されなくなります）、ビットエラーが発生して誤ったテスト結果が発生しました（確定的テストを再度実行すると、結果が異なります）。人間がステップを逃して「OK」をチェックした場合、どうすればわかりますか？
耐久性のテスト
自動化されたテストは、実行するために具体的なアーティファクト（たとえば、コードの一部）である必要があり、自然に他のソフトウェア開発アーティファクト（ソースリポジトリ）に含まれています。手動テストは、テスターによってメモ用紙に作成され、決して形式化されません。ビジネスでは、それが起こらないようにするための適切なプロセスが必要になる可能性が高くなります。
テスト値
コンピュータは、テスト結果を一貫した簡単に分析できる形式で出力するようにプログラムできます。その人は、データエントリを作成して同じものを生成するか、またはアナリスト、開発者、またはマネージャーがダイジェストする必要がある自由形式のメモを記録しています。
ほとんど（テストの範囲によって異なります）バグのないコードです。最大の引数の1つは、マネージャーに次のように言うときです。発見されたバグのテストを書くことができ、そのバグが戻ってきたら将来いつでも知ることができます:)
私の意見では、ユニット/統合テストが最も重要ですが、MVCのようなUIパターンを適用する場合、ほとんどのプロジェクトにはそれで十分です。私は通常、コントローラー/プレゼンターですべてのアクションをテストし、ビューへのデータバインディングを残します。
もちろん、自動化されたテストは、古き良き時代を代弁するものではなく、ユーザーができる最もワイルドなことを理解しようとする、アプリケーションの周りの冒険をクリックします。
継続的統合のポイントもあります。
もう1つ-コードの品質が製品の品質、ビジネス価値、および保守性につながるように努力する必要があります-そうでなければ、それを行う意味がありません。
「より低いコスト」と「より多くの機能/単位時間」/より短いサイクル時間の魔法のポイントでリードする必要があると思います。
ただし、訴訟を起こす前に、あなたの状況について反省することをお勧めします。あなたの質問により、自動テストの潜在的な短所について ブログ投稿 を書くようになりました。
ここでは、リファクタリングのしやすさが大きな要因です。 NiceとREADABLE（!!!）の単体テストで十分にカバーされているため、既存の機能を損なうことを心配することなく、システムをリファクタリングできます。
コンセプトを販売する必要があります。コードを改善することを伝えないようにする必要があります。彼らがすぐにあなたに反する/自動テストを置くコードへの投資がある場合。それらが良いものであれば、彼らはGIGOも理解するので、それが当てはまらないと思う理由が理解できません。
私はそれをドキュメンテーションの側面としても売りっぱなしにしておきます、Fitnesseのようなものはそれをうまく行うことができますが、彼らが経験するまでそれを視覚化するのは難しいかもしれません。
運が良かったと思うエリア
ユニットテストは、多くの開発者ハーネスの代わりになることができます。ここでは、すべてのログイン/メニューを経由することなく、デバッグ/テストする領域にアクセスするためのアプリケーションを作成します。
テストを使用すると、問題の状況をセットアップして簡単に繰り返すことができます。テストデータのセットアップに多くの時間を費やす必要はありません（特にまともなモックシステムを使用）。
BDDとUIテストのスイートを構築すると、次のテスターがそれを見るのを待つよりも単純な中断がある場合、応答がはるかに速くなります。
BDD＆UIテストでは、ボタンを繰り返し押して、変更によって影響を受けた可能性のあるすべての側面を確認し、すべての領域を覚えておく必要をなくすことができます。
自動ビルドは、誰かがコードをチェックインするのを忘れたときに強調表示することがよくあります
テストは、バグの再発を防ぐのに役立ちます。
ユニットテストとまともなモックは、相互リンクされたコードが少なくなり、解決しやすくなります
あなたがそれを宗教に改宗させるのではなく、それを売り込もうとしていることを忘れないでください–それで、小さなステップを受け入れて、それらをあなたに反することをしないようにしてください。彼らが調整し、良いテストを書くことを学ぶのにも時間がかかります。
誰かがその問題に対する提案された解決策を受け入れる前に、問題があると信じなければなりません。
自動化されたテストはバグ修正のコストを節約できるため、同僚がバグ修正のコストがかなり大きいか過度であることを認めない場合、納得させるのは困難です。これらのコストが高額または高額であるにもかかわらず、人々がそれを信じていない場合は、まずこれらのコストに関する説得力のあるデータを入手する必要があります。
重要なのは、全体として「自動テスト」ではなく、作成するテストの特定のカテゴリについて話すことだと思います。後者は少し曖昧で心配になる場合があり、時間の無駄になる場所の例を思い付くのは簡単すぎます。
テストを4つのグループに分割することを常にお勧めします（詳細 ここ ）。ここで私にこだわって、これがいかにして他の人にテストを販売するのに役立つかについて説明します。
- コア機能のテスト。つまり、Webサイト監視ツールの場合、これは監視しているWebサイトに対して起動するアラートのテストになります。これらのテストは、これが壊れないことを確認します。
- アプリケーション全体の煙のテスト。たとえば、Seleniumを使用してWebアプリ内のすべてのリンク/ボタンをナビゲートし、サーバーからのエラーがないことを確認します。これらのテストは、明らかに壊れたビルドでテスターの時間を浪費することを防ぎます。
- 脆弱なコードのテスト。つまり、その古いモジュールでは誰も触れたくない、または常にバグが含まれているように見える複雑なコードです。
- 開発者が自分の作業をサポートするために書きたかったテスト。何かを書いているときにテストが役立つことがありますが、上記のカテゴリに分類しないでください。
テストをこれらのカテゴリに分割することで、別のディスカッションを行うことができます。最初の3つのグループ（4つ目はとにかく個人の裁量による）を取り上げ、それらのコードのテストが価値があると人々が思うかどうか尋ねてください。同意が得られない場合は、現時点ではそれらのテストを含めないでください。可能であれば、つまり、各コミットで実行されるコア機能に関するテストが有用であると人々が同意した場合は、それらの追加を開始します。
便利なもう1つのグループは、テストを手動で行うのが困難または時間がかかるテストです。手動のテスト時間を節約すること、または時間がないためにテストがスキップされることに関して、ここで説明するメリットはかなり簡単です。
企業が愛するのは、価値の向上とコストの削減です。自動化されたテストは追加のコストを追加するため、どのように価値を高めるかを説明する必要があります。
コードがモジュール化されている場合は、再利用できます。これは、テストを最初からやり直す必要がなく、既存のコードの上で作業することができることを意味します。
レガシープロジェクトがある場合、自動テストによりリファクタリングがはるかに簡単になります。技術的負債はいつか返済しなければなりません。
あなたが提供するドキュメントの引数はあまり良くありません。テストを最新の状態に保つこととドキュメントを最新の状態に保つことの違いは、単なる習慣です。
「私が助けを求めているのは、その価値をプログラマー、アナリスト、マネージャー、テスターのチームに明確に説明することです。自動テストによって、私は区別する必要がないと思いますユニットテスト（JUnitなど）、BDD（JBehave、Fitnessなど）、UI（Selenium、Watir）はすべて同じような値を提供していると思います（ただし、反対の回答を書き込んでください:)） "
OK私はその挑戦をします;）
私は主にプログラマーやQAを担当しており、ツールはRuby、Rails、testunit、rspec、jasmine、Seleniumです。
RspecとtestunitのBDD/TDDツールはプログラミングの一部です。あなたはそれらを分解して管理者に個別に話し合うのではなく、時間の不足のためにそれらを延期するのではなく、すべての時間の見積もりにそれらを含めます。本当にプッシュされた場合、コンピュータサイエンスとプログラミングを説明するために人々がどれだけの時間を過ごすかが尋ねられました。これらのテストはフロントエンドには使用しません
GUI/UI/Jasmine/Selenium。これらは異なります。これらは、プログラマーのバックグラウンドを持つQA担当者が行っています。テストが可能な限り堅牢で、レイアウトではなくコンテンツに基づいて記述されていることを確認します。これの（おそらく新しい）コストはシフトされたコストとして説明されます。壊れたソフトウェア、失われた顧客、および高額な修正を後で支払う代わりに、いくつかの簡単な方法で今より（比較的）大幅に安く支払います。