自動化が必要ですか？ 反対から議論を始めます。
なぜテストを書かないのですか？
1.高価です
プログラマーはプロジェクトで最も高価な参加者の一人であり、彼の仕事は予算に大きく影響します。 一般的に、テストを書くことは大したことではありません。 これらのテストとテストプログラムの作成を学生に提供するために、1ペンスで学生を雇うことができます。 ディスプレイに突っ込んで、キーを押してください-すべてがうまくいきます。
2.これは面倒です
自動テストの開発は非常に退屈な仕事です。 誰にでも委託することができます。 プログラミングを大学で5年間、大学院でさらに2年間勉強しました。 クールなアーキテクチャを設計し、クールなパターンを適用し、火星にロケットを打ち上げたいです。 そして、テストは私のレベルのタスクではありません。
3.役に立たない
コードが機能するのに、なぜテストを書くのですか？ 彼の各ラインは私の内なる天才を通り抜けました。 どうすればアプリケーションに問題を作成できますか？ これは問題外です、私はすべてのバイトを通して見る。
4.これらは「私の問題ではない」
今日、あるチームで機能を作成しました。明日、新しい機能を実行するために別のチームに行きます。 何か間違いがあったとしても、次に何が起こるかは私なしで整理されます。
リスト全体が正しくないのはなぜですか？
今、私たちはすべてのポイントを通過し、それぞれに反論します。 同時に、Microsoft（Laurie Williams、Gunnar Kudrjavets、Nachiappan NagappanによるMicrosoftの単体テスト自動化の有効性）のような有名企業、および南米のあまり知られていない企業による研究からの興味深い事実がいくつかあります。
1.プロジェクトの規模は安価です
Steve McConnellのPerfect Codeに目を向けてください。 時間とともに人件費がどのように変化するかを評価すると、開発者が実行するテストの割合が徐々に25％から8-10％に減少することがわかります。 より多くのリソースが他のアクティビティを盗み始めます。
Microsoftがさまざまな規模の約30の内部チーム（それぞれ28〜35人の開発者と14〜20人のテスター）を調査した別の調査があります。
この調査では、ほぼ同じ数値が示されています。 自動テスト手法の導入により、開発時間は平均26％増加しました。 しかし、開発はすべてのプロジェクト活動ではなく、設計、統合、実装などがまだあります。 したがって、特に手動テストのコストの低下を考慮すると、多くのプロセスのうちの1つだけが4分の1増加しても、予算のわずかな損失になります。
2.これは生産上の問題よりもはるかに楽しいです。
おそらくテストの作成は少し退屈です-テストコードは簡単で、興味深いタスクを伴うことはめったにありません。 しかし、クライアントは間違いなく永遠の火を必要としません。それを消して、実装またはベータテスト中に欠陥を見つけます。
3.誰にとっても良いことです。
コードの標準を信じるほど、チームにとっても製品にとっても優れています。 そしてまずは自分自身のために-あなたの過ちから学び、同時に不快な結果なしに。
4.それが問題になります。
コードを書き、そのサポートを放棄すると、1、2か月でリリースを簡単に飛ぶことができます。 製品の一般的なテストの一環として、多くの欠陥が発見されます。その結果、あなたの機能と同僚の他のいくつかの機能は生産に到達しません。
チームの役割に関するテスト
私たちは攻撃に行きます。 開発プロセスのすべての参加者（クライアント、製品所有者、テスター、開発者）の目を通してテストを見てみましょう。
お客様
テストが書かれていない場合はどうなりますか？ たとえば、26億ルーブルの保険に加入している衛星を失ったとします。
11月28日、ロスコスモスは、ソユーズ2.1bロケットを使用して、Meteor-M衛星No. 2-1を打ち上げました。 彼は飛ばなかった-コースから少し外れて、海に落ちた。 ルートの調整を担当したソフトウェア開発者は、関連データを提供することを忘れていました。 衛星はバイコヌール宇宙基地から軌道に打ち上げられることが計画され、打ち上げはボスコニー宇宙基地から数万キロ離れた場所で行われました。 入力データを検証するための1つの小さなテスト-および26億ルーブルが保存されます。
インターネットでは、ソフトウェアの1つの小さな間違いが何十億ドルもの費用につながる可能性があることについて多くの話を見つけることができます。 ほとんどは医療と宇宙に関連しており、銀行業界には多くの例があります。 たとえば、2012年に、1つの大規模な西部銀行のネットワークで、すべてのサーバーで同じ更新プログラムを展開しました。 その後、必要なロックがプロアクティブなフロントで消えたため、古いコードを持つサーバーは追加レポートを生成し始めました。 その結果、440百万ドルのステートメントは無駄に無駄になりました。
一方、テストによって製品コードが完全に閉じられた場合はどうなりますか？ 彼を使えば、あなたの前に誰もしなかったことを安全に行うことができます。 とてもクールです。
プロダクトオーナー
将来の製品の重要な特徴は、その拡張と長期的なサポートの可能性です。 英語では、これは美しい単語Maintainabilityと呼ばれます。
これは、数年（または数十年）にわたって開発されてきた製品が常に一定の最低レベルの品質を提供し、その欠陥の数が特定の最大値を超えないことを意味します。 ユーザーエクスペリエンスを悪化させるべきではありません。 機能の品質を大幅に低下させないでください。 これは、手動、自動のテストを通じて保証できます。
別のマイクロソフトの調査では、別の興味深い数字を覗くことができます。 32人の開発者のチームの一部として、開発チームがテストの自動化を使用し、製品の2番目のバージョンで単体テストを記述した後、ユーザーに到達した欠陥の数は20.9％減少しました。 同時に、2番目のバージョンは追加の機能を取得し、コードボリュームが約20％増加し、さらに20％書き換えられました。 そして、テスター自身がソフトウェアの品質が高くなったことに気づき始めました-仕事が面白くなってきました。
IBMも同様の調査を実施し、最終的に、リリース後に検出されたバグの修正コストは、設計または実装中に検出されたバグの4〜5倍であることを発見しました。 自動テストは、定期的に実行される場合、問題があることを時間内に知らせるのに役立ちます。 予算内でこれらの余分な骨を削減するのに役立ちます。 その結果、ソフトウェアサポートのコストが低くなり、ユーザーエクスペリエンスの品質が向上します。
テスター
ここで、質問はすでに少し異なります。テストの自動化が必要なのはなぜですか？ マイクロソフトの調査が再び助けになります。 彼によると、自動化をテストした後、テスターがバグを探すことははるかに難しくなりました。 しかし、同じ時間コストで、以前は本番環境にリークする可能性がはるかに高かったはるかに複雑なバグを見つけました。 同時に、テスターの前でも削除されるため、些細なエラーははるかに少なくなります。
これは、Microsoftの内部プロジェクトの1つに関するバグレポートです。
最初のバージョン-自動テストの導入前、2番目-後。 エラーは4つのカテゴリに分類されます。 カテゴリが高いほど、エラーは難しくなります。 合計で、2番目のバージョンでは、バグの数が21％減少しました。 単純なカテゴリ（3および4）のバグの数は大幅に減少しました。 より複雑なバグの割合は同じままであるか、バグの総数が減少したという事実によりわずかに増加しています。
テスターは、ユーザーエクスペリエンスにできるだけ近い、より複雑なテストケースを作成できるようになりました。 プログラマーは、コードを体系的にテストコードで補足する場合、最も単純なエラーを自分で削除する可能性が高くなります。
テスターがバグを少なくしたのはなぜですか？ さまざまなタイプのテストをレイヤーに分割するピラミッドが多く知られています。 このピラミッドは、ソフトウェアのごく一部にしか影響を与えない最も原始的な単体テストがプロジェクトで最も多くあるべきだと言っています。 複雑なエンドツーエンドテストまたは手動テストは最小数である必要がありますが、同時に最も複雑なバグを探す必要があります。これらはいわゆる点滅、フローティング、またはグレーのテストです。 このピラミッドをひっくり返すと、いわゆるテストファンネルが表示され、そこにあらゆる種類のバグが注がれます。
ソース： https : //twitter.com/noahsussman
この目標到達プロセスの各レベルで、バグは除外されます。 バグが複雑で興味深いほど、この漏斗で低下します。 多数の単体テストにより、手動テストの段階の前にほとんどのバグが解消されます。 したがって、手動テスト自体の時間は短縮され、特定の機能に関連するバグのみがユーザーに侵入できます。 90-95％は彼らの人生で決して出会うことはありません。
開発者
開発者にとって、テストが彼に与える5つの利点を特定しました。
- 要件を理解する
テストを書くとき、開発者は非技術専門家とのコミュニケーションのおかげで、要件をよりよく理解し始めます。 ある種の入力フィールドを実装する必要があるとしましょう。 コードのテストを作成するとき、質問をし始めます。ここで空の値を代入するとどうなりますか？ しかし、10文字ではなく150文字を入力するとどうなりますか？ これらのポイントを明確にすることで、コードをより安定させ、最も単純なエラーからコードを保存します。
- リファクタリングの安定性
テストにより、特に大胆なリファクタリングで、リファクタリング中のアプリケーションの安定性を保証できます。 古いモジュールがあるとします-多くの人が触れるのを恐れている巨大なレガシーコード、そこで何が起こっているのか明確ではないからです。 このことをテストで閉じると、メインケースが機能することを定性的に検証します。 内部に入り込んですべてリファクタリングし、新しい実装の一部に変更することはそれほど怖くないでしょう。 アプリケーションに現れた変更が何も破壊しなかったことを確認するだけです。
- ドキュメンテーション
テストは、コードの優れたドキュメントです。 このコードを利用する人がいると、他の人のコードを理解するのがはるかに簡単になります。 そして、最初の消費者はテストです。 Jiraにアクセスしたり、Confluenceで膨大なコメントを調べたりしないでください-テストクラス、コードのテストメソッドのセットを開いて、テストメソッドの名前を読み、そこに転送されるデータを理解するだけで、このコードの機能を理解できます。
- APIの改善
TDDなどのテストを記述する反復練習を使用する場合、またはプログラムで特定のエンティティをテストでカバーする方法を事前に計画する場合、これによりインターフェイスが改善されます。 このエンティティにどのデータをプッシュし、どのデータを返すかを考え始めます。 これにより、常に新しいコンテキストとパラメーターを追加する代わりに、高品質のインターフェイスをすぐに作成できます。
- エラー削減
テストによってコード内のエラーの数が減ることは明らかです。 ミスの減少-より多くの自由時間。 開発者自身がMicrosoftの調査でテスト（この場合は単体テスト）を書くことについて次のように述べています。
まとめると
テストの作成は、経営陣によってサポートされる必要があります。 あなたがテストを書くと決めた場合、残りは書いていませんが、イニシアチブはおそらく数ヶ月後に消滅します。 経営陣はテストの作成をサポートし、プロジェクトにテストが表示される理由を理解する必要があります。
もちろん、テストを行うと、開発期間が長くなります-平均26％。 プログラミング言語の複雑さ、機能、およびプログラマーの経験に応じて、この割合は8％に減少するか、時間の40-50％に跳ね上がる可能性があります。 市場参入の時間があなたにとって最も重要な場合-テストの作成を延期し、MVPをリリースして、後でテストに戻ります。
私の意見では、開発者だけでなくテスターもチーム内でテストを作成する必要があります。 すべてのチームメンバーはコードにアクセスできる必要があり、全員がコードの変更に影響を与えることができる必要があります。 テスターは、平均的な開発者よりも多くの例外と多様なエッジケースを提供できます。 したがって、テストの品質とカバレッジが向上します。
上記のすべての議論が、チーム内での説明に役立つと同時に、テストを必要とする理由、テストを毎日書かなければならない理由、コードを改善する方法に役立つことを願っています。