オートテスト-ノーブルマン

開発者が自動テストを作成する必要があるのはなぜですか？ 同じ成功で、彼らはタイルを置くか、アカウントを維持することを強制することができます。 崇高なことではありません！ それとも、やっぱり、君主？











注：記事の自動テストの下では、単体テストではなく、可能な限り戦闘環境に近い環境で完全に展開された製品で実行される自動機能テストです。



ソフトウェア開発には多くの神​​話と愚かさがあります。 それらのうちの2つを検討してください。



そのため、業界のテスターは開発者よりも平均して低い収入を得ています。 これは明らかに、テスターの役割のために3ルーブルを雇って、どこに突くべきかを示すことができるという意見があり、それがサルテスターチームの準備ができているからです。 もちろんこれはナンセンスです。 優れたテスターは、本質的に知識が少なく経験豊富なハッカーであり、費用がかかるはずですが、何らかの理由で理解できる人はほとんどいません。



2番目の愚かさは、自動テストに対する態度です。 ユーザーと顧客は自動テストを気にしないので、製品が必要なので、自動テストの開発は、それを行うことに同意する人に任せることができ、また委ねるべきである愚かな退屈な作業であると考えられています。



これら2つのナンセンスを組み合わせると、テストチームに自動テストが行​​われる状況になります。その結果、自動テストの開発にも自動テストにも携わっているため、テストチームはありません。

1. 自動テストの開発には非常に費用がかかります。
2. 多数の誤検知。 まれに、自動テストの完全な実行が正常に完了すると、結果として、誰も壊れたアトテストを信じません。
3. 多数の誤検知と診断の難しさのために、自動テストの実行結果を分析する時間のかかるプロセス。
4. 非常に高い脆弱性。 製品に小さな変更を加えた後でも、テストは常に中断しています。 このため、彼らは常に「完成」する必要があります。
5. 最終的に、彼らは自動テストで詰まり、この恥を忘れようとします。

上記の問題の第1の理由は、満足のいく自動テストシステムがテスト対象製品自体よりも複雑であり、それ自体がソフトウェア製品であることです。 自動テストシステムの開発者は、ソフトウェア開発の分野で高い資格を必要とし、テストチームにはそのような人はあまりいません。 その結果、テストの維持と開発に非常に費用がかかります。



2番目の理由は、テストチームが製品コードを所有していないという事実に起因しています。 開発者がコードを所有し、修正できるのは彼らだけです。



単体テストを使用するという慣習から、テストコードの作成者が単体テストに従事している場合、その開発が最も効果的であることがわかります。 この場合、原則として、コードはテストにより適していることが判明し、その結果、テストはより簡単で信頼性が高くなります。



機能的な自動テストを開発するときにもまったく同じ状況が発生します。 製品コードが開発者によって作成され、このコードのテストがテスターである場合、そのようなテストの複雑さと品質（保守性、実行速度、脆弱性など）は、1つのチームが両方を開発した場合よりも劣ります。 これは、開発者がコードをわずかに修正できるため、このコードの自動テストを作成する方が便利であるためです。 理論的には、テストチームのエンジニアが製品開発チームにコードの変更を依頼する場合もあります。 しかし、実際には、これは常に起こるとは限りません。なぜなら、テスターは、現在重要なことで忙しい開発者のチームに、彼が何を実現するかを待つよりも、テストに松葉杖を残すほうが簡単だからです。必要に応じて、彼が尋ねたものではなく、円で取得します。 その結果、時間の経過とともに、テス​​トは松葉杖で生い茂り、サポートされなくなり、ハンドルのない非常にスーツケースに変わります。



したがって、最も信頼性が高く、簡単にサポートされるテストは、製品開発者のチームが行ったときに得られます。 しかし、このオプションにも欠点がないわけではありません。 これらの欠点はよく知られており、それらのおかげで、一般的にテスターが存在します。 すべては、テスターがエラーをよりよく見つけるという事実に帰着します。



したがって、開発者とテスターの両方が自動テストを作成する場合は、いくつかの中間オプションが最適です。 この組み合わせアプローチにより、両方の長所を組み合わせることができます。 開発者は、自動テストの有能なアーキテクチャを構築し、製品を適合させ、製品コードテストでカバレッジを提供します。 テスターは、開発者の自動テストをベースとしてテストケースを提供します。



自動テストの開発は、製品開発プロセス全体の不可欠な部分です。 各ユーザーストーリーの反復を計画するときは、そのための自動テストを準備する時間を常に確保します。 自動テストの複雑さは、通常、履歴の複雑さの10〜20％ですが、費やした時間は何度も報われます。



このアプローチを自動テストの開発に導入する場合、開発者の動機付けに問題があるかもしれませんが、これらの問題を克服することは難しくありません。 自動テスト（少なくともそれらの一部）の実行をプログラマチームの内部問題にする必要があります。 つまり、テスターは、自動テストが完全に合格したアセンブリのみをテストするために受け取ります。 同時に、テスターはこの恥について何も知らないため、セルフテストで検出された機能が壊れても、バグは発生しません。 プログラマが自動テストに違反するコードをチェックアウトすると、些細なことがあれば、すぐにチェックをロールバックするか、すぐに修復します。



この後、驚くべきことが起こります-プログラマーは、自動テストによって時間を大幅に節約できることに突然気付きます。

1. 製品コードに別の変更を加えるとき、開発者は何も壊していないことを確認する時間を無駄にしません。 開発者はコードをリポジトリに配置するだけで、自動化がチェックを行います。
2. コードの実行は、破損したコードよりも修正がはるかに簡単です。 自動テストは、プログラマが次のタスクを開始する前に製品のパフォーマンスを確認します。これにより、彼は足元にしっかりとした基盤を与えます。
3. エラーが早く検出されるほど、ローカライズと修正が容易になることが知られています。 多くの場合、自動テストはエラーを検出するのにかかる時間を最小限に抑えるのに役立ちます。そのため、エラーはホットトラッキングで修正されます。
4. プログラマーはリファクタリングの正確さを自動的にチェックする機会があるため、自動テストによりコードを効果的にリファクタリングできます。 これにより、リファクタリングは地雷原を歩くのをやめ、日常的な作業手順になります。

その後、再びソファに落ちて脂肪で泳がないように、自動テストで定期的なクラスを監視して維持するだけです。