開発はテストを書くべきです（？）

ねえ！誰がテストを書くべきかというトピックに関する古いホリバーがあります：開発者またはテスター。チームにテスターがいるとしたら、彼らがテストを書くのは理にかなっているようですね。一方、（開発自体に加えて）開発の担当者は、コードがどのように機能し、特定の状況でどのように動作するかを正確に知っています。少なくとも彼らは推測します。

免責事項：私の名前はEric Buryginです。私は長い間テスターとして働いており、「テストエンジニア」のコースで学生に教えている ので、テスターは作品を開発者に転送したいと思っているように見えるかもしれません。実際、説明されているアプローチには長所と短所の両方があるため、この記事はとりわけ議論の余地があります。コメントで開発者とテスターの両方の意見を見ていただければ幸いです。

開発がテストを作成する場合、次にいくつかの問題を一度に解決できます。

• リリースサイクルを目に見えてスピードアップします。
• テストをアンロードします。

ほとんどのコマンドでは、プロセスは次のようになります。

1. 開発者は新しい機能を作成し、既存の機能を完成させます。
2. テスターはこれらすべてをテストし、さまざまなテストケースを作成します。
3. ポジションのタイトルを正当化するオートマターは、条項2から書かれたテストケースに従ってすべてを自動化します。

すべてが単純なようです。



しかし、このパラダイムには弱点があります。



開発者が自分の機能を完了し、テストのために安全に合格したとしましょう。しかし、この機能はミディアムレアではなく、率直に言って生であることが判明しました。これにより、問題の再発見と追加の修正が行われ、この機能のサイズ、複雑さ、関連プロセスへの影響、および開発者自身の誠実性に応じて、1〜N回の反復が発生する可能性があります。また、開発内でプロセスが原則的にどのように配置されているか、プルリクエストがどのように注意深く見えるか、アプリケーションがテストに送信される前に起動されているかどうかについても説明します。



一般に、十分な変数があります。



タスクがテストされ、リリースの準備ができたら、テストケースの機能全体についてテストを作成する必要があります。その後、退行/煙を出し、最後に解放します。



書かれたテストケースを受け取った後、オートマトンは機能をテストでカバーします。タスクが既存のキューに入れられる可能性がかなり高いため、テストは遅れて書き込まれます。

-もっと開発者が必要です

残念ながら、万能薬ではありません。まったく逆です。このスキームに参加する開発者が多いほど、テストの負荷は大きくなります。その結果、リリースサイクルまたはテストチーム自体のいずれかが増加します。



そして、これは、ドミノの原則によれば、オートマトンの負荷を増大させます。オートマトンは、テストから落ちるテストケースをますます処理する必要があります。ミラーの状況が発生します。テストカバレッジ時間が長くなるか、自動化スタッフが増加します。



通常、8人の開発者ごとに2人のテスターと1人の自動化エンジニアがいます。同時に、自動化はリリースサイクルに直接関与するのではなく、近くにあります。そして、疑問が生じます。説明されているプロセスをより効果的にし、品質を失わないようにする方法は？



自動化段階を3位から1位、そして開発段階に移してみましょう。

何が起こるのですか

すぐに優れた利点が得られます。以下を参照してください。

• 開発者は、機能自体の作成と同時にテストを作成します。これにより、機能の品質が大幅に向上します。
• テストの負荷が減少します。テスターは、テスト結果を確認し、タスクがテストで十分にカバーされているかどうかを評価する必要があります。
• スキームの手動回帰は不要になりました。

テスターはどうですか？



テスターは、更新されたパラダイムであっても、テストの専門家であり続けます。特定の機能の自動テストカバレッジの品質と完全性の両方を確認し、複雑で異常な問題を分析するのはテスターです。しかし今では、負荷が軽減されたおかげで、テスターは時間の一部を解放し、プロセスを処理できるようになりました。



同時に、手動テストはまだどこにも行かないことを理解する必要があります-何らかの理由で自動化することが不可能であるか、意味をなさない何かが常にあります。



だから、新しいパラダイムに。涼しい？はい、少なくとも今すぐ実装してください。あなたが2つのことをすることができるならば。

1. このアイデアを開発に売ります。すべての開発者がすぐにテストを書きたいとは限らないので、それは退屈である可能性があるため、または単に望んでいないためです。実際、何のためにテスターがそこにいますか？
2. このアイデアをマネージャーに売ります。なぜなら、他の利点とともに、各機能の開発時間が長くなるからです。

ここでの不利な点は何ですか。

1. ほとんどの開発者は、テスターではなく開発者であるため、テスト方法を知りません。そしてそれは大丈夫です。ここでは、テストの方法を教えることができますが、これは最も簡単な作業ではありません。または、テストケースを作成するだけです。どの事実上、プロセス自体を壊します。
2. テストコードベース、インフラストラクチャ、および通常のアプローチがないため、最初は自動化に時間がかかります。タスクは新しいものです。
3. テストには明確なレポートが必要になります。ただし、最も理解しやすいレポートでさえ、すぐに正しく読み取れるとは限らないことに注意してください。
4. テストのすべての問題を簡単かつ迅速にカバーできるわけではありません。場合によっては、機能の実際の実装よりもテストに多くの時間を費やす必要があります。
5. テストと同時に大規模なタスクを実行することは難しく、時間がかかります。
6. これらの同じ大規模で複雑なタスクの場合、開発者が作成したテストの正確さをチェックする他の方法がないため、単にそれらを掘り下げるための時間を確保する必要があります。

何をすべきか？

基本的に、それぞれの問題には解決策があります。

1. 開発者はテスト方法を知りません。→
   
   早い段階で相談して理解を深めることができます。
2. , . →
   
   . .
3. . →
   
   , , .
4. . →
   
   : .
5. , . →
   
   , — . .
6. . →
   
   . .

すべての長所と短所を備えたアプローチには、生存権があります。また、プロセスを正しく設定すると、リリースサイクルをスピードアップし、状態を膨らませることはありません（：