会社はテストを外部委託しました。プログラマーにテスターに過度に依存するのをやめるように促すにはどうすればよいでしょうか。
私の友人が200人の従業員を抱える会社で働いています。会社のビジネスはITとは何の関係もありませんが、顧客が使用するWebサイトで作業するIT部門があります。
Webサイトは、プログラマーが自動テストを使用してアプリケーション自体をテストする必要があるという中心的なアイデアから始まりました。ただし、プログラマーは Selenium （および後で Cypress.io ）を使用して機能テストを記述し、複雑な相互作用のいずれかを処理しようとしたため、時間がかかりすぎて問題が生じ始めました。ドラッグアンドドロップやファイルのアップロードなど、テストがランダムに失敗する理由を理解しようとしています。しばらくの間、25％以上の時間がこれらのテストに費やされました。さらに、ほとんどのプログラマーは、テストがランダムに失敗する理由を理解しようとせず、実際の価値を生み出したいと考えていたため、これらのテストに腹を立てていました。
2年前、ブルガリアの企業に支払いをして、機能レベルのインターフェースレベルのテストを手動で行うことが決定されました。そのようなテストはかなり安価だったので、物事はうまくいきました。全体として、プログラマーはより少ない機能でより速く機能を提供し、誰もが満足していました。
しかし、時間の経過とともに、プログラマーは自信過剰になり始めました。統合テストやユニットテストの記述が少なくなり、ブラウザーで機能するかどうかを実際にチェックすることなく機能を完了としてマークすることがあります。テスターは間違いを見つけてしまうので、なぜわざわざ？これは2つの問題を引き起こします：（1）問題が数日前にテスターによって発見されたとき（プログラマー自身が数分以内に発見されたときと比較して）、（2）外部委託されたテスターの全体的なコスト常に成長します。
最近、チームリーダーは次の方法でこの動作を変更しようとしています。
1人あたり、テスターによって再開されたチケットの数を測定します（結果をチーム全体に共有します）。
最高の成績を収めた人、つまり再オープンされたチケットの数が最も少ない人を祝福します。
最悪のパフォーマンスを示した人たちとペアプログラミングを行い、なぜコードをテストするのがとても難しいのかを理解し、それほど難しくないことを示します。
機能がテストされるまで数日待つよりも、今すぐ問題を解決する方がはるかに速いことを説明する。
テスターはシステムテストのみを行うこと、および単体テストがないため、問題の正確な場所を正確に特定することが困難であることを説明します。
ただし、機能しません。
メトリックは常に関連しているわけではありません。 Edgeケースのために、テスターによって数回再オープンされる不明瞭または複雑なチケットで作業する場合があり、同僚がその間非常に単純なチケットで作業する場合があるため、回帰を導入する機会は絶対にありません。
プログラマーはコードのテストに消極的です。なぜなら、（1）退屈なだけである、（2）コードをテストしないと、コードは彼らはより速く機能を提供します。
彼らはまた、機能を開発してから数日後に問題を修正することがなぜ問題になるのかを見ていません。彼らは理論を理解しているが、実際にはそれを感じていない。また、少し時間がかかる場合でも、プログラマーのテストに時間を費やすよりも、外部委託のテスターに安価に支払う方が安くなると彼らは信じています。これが事実ではないことを繰り返し伝えても効果はありません。
システムとユニットのテストについては、プログラマーはテスターから報告された問題の正確な場所を見つけるのにそれほど多くの時間を費やしていないと返信します（実際にはそうであるようです）。
プログラマーにテスターに過度に依存するのをやめるように促すには、他に何ができますか？
ここでは、ポリシーに矛盾があるようです。
一方で、同社はプログラマーの時間を過度に消費し、他の人がより安く行うことができるため、テストを外部委託しました。
現在、彼らはプログラマーがテスターに依存していること、そして彼ら自身がより多くのテストを前もって行うべきだと不平を言っています。
管理の観点からは、満足のいくメディアであると認識されていることは理解できますが、実際には、プログラマーは、ケースバイケースで、自分自身で行うテストの量と方法について、詳細な分析を行っていません多くは彼らが外部委託しています。
そうすることを試みることは、あまりにも多くの時間と知的努力を消費し、そしておそらく正確な結果を生み出さないでしょう。プログラマーは、特定のコードに含まれるバグの数を推定し、テスターにバグを検索させるのではなく、自分で時間を費やすことの経済的メリットを比較検討するにはどうすればよいでしょうか。それは不条理です。
代わりに、プログラマは経験則に従っています。以前のルールは、広範囲にわたるテストでした。ここでのルールは、貴重なプログラマーの時間を節約し、より多くのコードを入手し、テストをテスター（10ペニーと思われる）に任せることです。
幸せな媒体を探すことは答えではありません。実際に何が起こるかは、肛門保持者が彼らの時間テストの25％を費やすことに戻り、カウボーイがドアから低品質のコードを投げ続け、性格特性が良心と細部への注意（またはその欠如）が判決よりも優先されます。経営陣が両方のタイプに嫌がらせをして、経済的に理想的であると考えられている平均により近づけるようにしようとすると、おそらくどちらも嫌がらせを受けるだけです。
ついでに言っておきますが、最初にテストに費やした25％の時間は、私に過度な印象を与えません。
結論：これは文化的な問題です。
私は、有能なプログラマーが少なくともコードのより複雑な部分の単体テストを作成するという見方から来ています。問題は、誰もが私の見解を共有しているわけではないことです。私が生きているよりも長くコードを開発している人々を知っていて、彼らも彼らのコードをテストしました-必ずしも自動テストでではありません。ソフトウェア開発には、テストが単純すぎるためにそれらのテストが実際の価値を持たないものが数多くあります。
とはいえ、発生する可能性のあるランダムな失敗の割合が異なるテストのレベルはさまざまです。管理の観点からは、どこで価値を得るかを理解する必要があります。
- ユニットテスト：実装ロジックとエラー処理を可能な限りロジックに近い場所で確認します。
- 統合テスト：システム仕様が正しく機能していることを確認します
- ユーザーインターフェイステスト：アプリケーションが要件に従って動作することを確認します
当然のことながら、個々のコードユニットから離れれば離れるほど、テストは脆弱になります。一緒に機能する必要のある部品が多いほど、何かが断続的に失敗する可能性が高くなります。つまり、単体テストに近いほど問題をキャッチできるほど、それらのテストの信頼性と価値が高まります。
Cost of Automation
自動化には時間がかかります。時間はお金がかかります。機能を手動でテストするよりも、自動テストを作成する方が時間がかかります。ただし、自動テストが実行されるたびに、手動テストの数分の1の時間で実行されます。管理の観点から、あなたはあなたの投資に良いリターンがあることを確認したいです。リスクが最も高いコード（アプリケーションが機能しない場合は役に立たない）に自動テストを実行して、リグレッション（壊れたコード）が発生したらすぐにキャッチできるようにすることを強くお勧めします。単体テストに合格しない場合、開発者はコードをプッシュできません。
一般に、いくつかのガイドラインがあることは役立ち、リスクの高いコードを確実にカバーする方法がカバーされます。
- ユニットテストは少なくとも25％のカバー率を持つべきです。 （私は個人的にはより高い方を好みますが、単体テストのないチームにとって、これは開始するのに適した場所です）
- ユニットテストと統合テストは、まず高リスクコードを優先する必要があります。
- 完了の定義には、1つまたは両方の要件が必要です。
- コードピアレビュー（プルリクエストはこれらを整理するための優れた方法です）
- 単体テストのカバレッジは最小基準を満たしています
手動テストのコスト
手動テストには時間がかかります。時間はお金がかかります。機能を手動で1回テストする方が高速ですが、機能を毎回テストするのと同じ時間がかかります。リグレッションから保護するために、完成した機能をテストし続けたいと考えています。回帰とは、以前は機能しなくなった、アプリケーションの機能です。
手動テストの隠れたコストは、テスターが人間であり、時には偶然にテストをスキップすることです。自動テストを作成するのが面倒だと思った場合は、同じ機能をすべてのボタンクリックで何度もテストしてみてください。
投資の最適化
ここで、管理と開発の両方を同じページにする必要があります。品質が会社にとって重要である場合、会社は品質に投資する用意がある必要があります。品質が重要でない場合は、テストを廃止してください。ユーザーは不平を言うでしょう、そしてあなたは彼らが不平を言う問題に当惑するかもしれませんし、そうでないかもしれません。つまり、アプリケーションがミッションクリティカルである場合、品質が重要です。
- 高リスクコードのテストを自動化する
- ソリューションが複雑であるため、リスクが高くなる可能性があります
- 機能の必要性により、リスクが高くなる可能性があります
- コードへの依存度が高いため、リスクが高くなる可能性があります
- 失敗するには簡単すぎるコード（ゲッターやセッターなど）のテストを記述しないでください。
- 複雑すぎて自動的にテストできないもの（ドラッグ/ドロップなど）を手動でテストする
- シンプルさへの投資
- 要件自体は単純な場合もありますが、他の要件と競合する場合があります。
- アプリケーションが現在のニーズに対応できるように、機能を削除する準備をしてください。
- 「完了」を明確にして明確にする
- 実行する必要がある作業が不明確な場合、開発者とテスターは何が正しいかについて異なる意見を持っています。
- 完了の定義が異なるため、3人とのミーティングでさらに数分作業することで、作業と作業をやり直すことができます。
概要
会社の文化は現在、勝てない状況にあります。経営陣が賛同すると、文化の変化が容易になります。また、チームがより効果的になるための規律を導入すると、より簡単になります。そのために、テストの実行方法に関係することを優先する前に、定義済みを優先します。
指標を収集しているのは素晴らしいことです。これらのメトリックが現在どのように使用されているかはよくありません。より良い方法は、チームがソフトウェアを開発する方法にさらに多くの構造を導入しながら、メトリックの傾向を確認することです。たとえば、完了までの時間が改善され、何を実行する必要があるかを定義するためにより多くの時間を費やすためにテストの失敗の数が減少した場合、それは勝利です。自動テストのカバレッジを50％に増やしても、テストの失敗数に改善が見られない場合は、おそらく25％で十分です。
ソフトウェア開発はチーム活動です。チームとして協力すればするほど、みんなの態度は良くなります。チームの成功に向けて準備が整っているほど、チームは成功を収めることができます。
さて、私たちは皆、開発者を保護および防御するという共通の目標を共有していますが、あなたの質問には、私を幾分不快にするいくつかのことがあります...
彼らはまた、機能を開発してから数日後に問題を修正することがなぜ問題になるのかを見ていません。彼らは理論を理解していますが、実際にはそれを感じていません。
ニュースを失って申し訳ありませんが、経験豊富なプログラマ実際にバグを早期に発見することの価値を感じてください。
システムとユニットのテストについては、プログラマーはテスターから報告された問題の正確な場所を見つけるのにそれほど多くの時間を費やしていないと返信します（実際にはそうであるようです）。
これは教科書防御的な話（やや受動的で攻撃的なにおいがする）です。そしてもちろん、それは真実です...あなたがそれを見通しに置くまで。プログラマーに尋ねることができます...彼らはブラウザでブックマークを使用していますか？彼らは検索エンジンのホームページを作成していますか？アプリケーション/ウィンドウを切り替えるためにalt + tabを使用していますか？これらすべては、生産性の向上についての哀れな言い訳です...つまり、あなたがそれらを行う場合[〜＃〜] once [〜＃〜]です。あなたがそれをするとき常時、それらの数秒は容易に無数の工数の生産性を合計しました。テスターから報告された問題の原因を見つけるのに、プログラマは何を1分かかりますか？それは彼らがフェルトである時です。実際の時間には、テスターの時間、レポートを準備する時間、チケットを提出する時間、詳細を伝えるために費やされる可能性のある時間andチケットを閉じる時間/解決されたと報告する時間が含まれます。時は金なりですよね？
これは、食べ物を買いに行くときに牛乳を買うのを忘れるようなものだと考えてください。店内にいる間、徒歩1分です。あなたが家にいるとき、それは指数関数的にもっとです。さて、見方を変えると、これは、1分間のフェルト時間が、関係者全員の実際のトラブルの約30分間に相当する方法です（ただし、実際にははるかに多くなります）。現在の状況を踏まえると、適切なテストによって会社が時々費やす時間を約30倍節約できることを経営陣が知っていたら、どう感じますか？
さらに...
しばらくの間、25％以上の時間がこれらのテストに費やされました。さらに、ほとんどのプログラマーは、テストがランダムに失敗する理由を理解しようとせずに、実際の値を生成したかったため、これらのテストに腹を立てていました。
繰り返しになりますが、ニュースをお詫び申し上げますが、経験豊富なプログラマーはテストに実際の値があるプラス25％の時間は実際にはそれほど悪いことではないことを理解しています。優れたテストは、ゴールドでの期間に見合う価値があります。また、-テストがランダムに失敗することはありません、少なくともこの大胆な発言が思うほど頻繁ではありません。 goodテストではないので、テストの品質も真剣に検討する必要があります。たとえば、 CEマーク について考えてみましょう。これはすべてテストに関するものです。プログラマーは、製品に実際の価値を追加することに反対していますか？
しかし、この最後に引用されたOPステートメントの実際の問題は、管理が実際にプログラマーからアドバイスを受けたテストを外部委託している、または少なくともプログラマーのテストへの嫌悪の影響を受けていることを示唆しているようです、他の回答とは異なり、経営陣はこれをすべて単独で台無しにしたと示唆しているのとは異なります。
プログラマーはコードのテストに消極的です。理由は、（1）退屈なだけである、（2）コードをテストしないと、機能がより速く提供されるように見えるためです。
ええと、経営陣は時々台無しにしていますね？機能をすばやく提供することへの圧力が高まっているようで、これは文化に少し浸透しています。残念ながら、過剰なプレッシャーがかかると、コーナーの切り取りと落下のテストが連携します。
経験豊富なプログラマは、テストがどのように時間に見合う価値であるかについて、長い時間をかけて、時間を浪費し、価値を提供できないと不平を言うのではなく、私は、プログラマーが比較的経験の浅いという簡単な説明をしなければならないという悪魔の支持者の立場にありますが、彼らがジャグリングしているシステム全体はそれほど複雑ではないので、まだそれほど問題はなく、実際に適切な自動テストの価値。
ここで提案できるのは1つだけです。これは、開発者をstrive開発者にテストの実際の価値を感じさせるとにかく犠牲を払うことです。また、その間、外部テスターandは可能な限り適切な自動テストを作成してください。出力がtoo複雑、安全性重視などでない場合、会社は外部テスターなしでおそらく実行できますが、それは常に詳細。
統合テストへの依存が過剰だと思っているだけではありません。あなたは間違った事を要求しています。実際の結果と比較して、測定可能な結果に人々を駆り立てるように非常に注意してください。
1人あたり、テスターによって再開されたチケットの数を測定します（結果をチーム全体に共有します）。
すみませんが、これはばかげています。プログラマーの仕事は、コードがテスターの手に渡っていれば完了しません。プログラマーに対してコードがコード間を行き来する回数を数えることは、逆効果です。プログラマーにテスターと関わってもらいたい。それを行うために彼らを罰しないでください。優れたプログラマーはテスターを応援します。彼らは彼らから隠れません。
最高の成績を収めた人、つまり再オープンされたチケットの数が最も少ない人を祝福します。
これは最良の良い測定ではありません。あなたはバグを隠すことができる人ではなく、バグを隠すことができる人に報酬を与えます。
最悪のパフォーマンスを示した人たちとペアプログラミングを行い、なぜコードをテストするのがとても難しいのかを理解し、それほど難しくないことを示します。
コードを実行するすべての人がコードをテストしています。人々が彼らがどのように判断されているか理解していないとき、賢い人は推測しようとさえしません。彼らはすぐに判決を下し、その結果から何か有用なことを学びたいと思っています。この振る舞いについては、奇抜な用語があります。アジャイルと呼ばれています。
さて、私がペアプログラミングが好きではないという意味ではそれをとらないでください。大好きです。私は、本やブログから、仲間のコーダーが問題にぶつかって座っていることを学びました。この居心地の良いものが消えるのを待つことができないので、私はそれをやり直すことができます。
しかし、あなたがしていることが説教であるならば、それはペアプログラミングではありません。これを行う場合は、黙ってパートナーに耳を傾けてください。あなたは何かを学び、あなたの問題があなたが思っているものではないことに気付くかもしれません。
機能がテストされるまで数日待つよりも、今すぐ問題を解決する方がはるかに速いことを説明する。
さてここにあなたの問題があります。機能のテストに数日かかることはありません。セメントのようなコードを考えてください。長く座っていると、移動が難しくなります。テスターのフィードバックをもっと早く入手してください。できれば、他の機能について考える前に。
バグの検出に時間がかかるほど、修正に費用がかかります。
テスターはシステムテストのみを行うこと、および単体テストがないため、問題の正確な場所を正確に特定することが困難であることを説明します。
説明をやめてピアユニットテストを実行します。それは彼らがあなたが望むものを示しています。プログラマーはコードと最もよくコミュニケーションします。これにより、彼らはそれを行うことができます。
このように機能します：単体テストを作成します。単体テストに合格する製品コードを作成します。あなたはコードをピアレビューし、何かが変わっていることに気づき、あなたはそのちらつきを証明する単体テストを書きます。あなたはユニットテストを私に送ってください、私はそれを見て、合格させるか、または実際の要件がどうあるべきかについて話します。ピアユニットテストを行うと、弱いユニットテスターがより強いものから学びます。不思議なことに、強い人は弱い人からも学ぶでしょう。
ああ、あなたはプログラムをペアリングするときにこれを行うことができます。すべてを高速化します。
要件について言えば、このコーディングが始まる前に、統合テスターが要件に関するディスカッションに参加しておらず、どの要件がテスト可能であるかがわからない場合は、頭がおかしくなります。彼らは、どの要件が統合テスト可能であるかを要求します。設計者は、設計を始める前に、これがどのように発生したかを知っている必要があります。
ピアレビューとピアテストを行った後、統合テスターにコードを送信します。現在、2人のコーダーがこれを早い段階で選択しており、テスターが残りのバグを見つけるために、両方とも応援しているはずです。彼らはそれらを隠そうとするべきではありません。彼らは、統合テスターがそれらを見つけるのを助けるかもしれない何かを公然と報告するべきです。
プログラマ対テスターではありません。バグに対する私たち全員です。
したがって、テスト不可能なコードを作成したことに対して人々に報酬を与えるのはやめてください。
私は100％自動カバレッジキャンプにしっかりと入っています。私はそれが実際に私が長期的に速く進むのを助けると思います、そして私はhateテスターから私に物事がリベートされることを持っています。
そうは言っても、自動テストを嫌う人は、テストを書く必要がないようにインセンティブを与える必要があります。自動テストがなくても品質を維持できると考えている場合は、それを証明してもらいます。テスターからバグに追い戻されたバグについては自動テストを必要とし、それ以外の場合はオプションにします。言い換えると、報告されたバグが存在する場合に失敗するテストを記述し、テスターが再テストするための前提条件として、修正がパスすることを示す必要があります。
私が望むことは、ずさんなプログラマーがほとんどのテストを作成しなければならないことです。破るのが最も簡単なコードは、最高のカバレッジになります。人々は、手動でテストするのが難しいもののテストを先制的に書き始め、自動化がより困難なテストに対してより徹底的な手動テストを行うでしょう。うまくいけば、テストをより簡単に記述して実行できるようにするための投資も行われるでしょう。すでに注意を払っているプログラマーにとって、ほとんど変化はありません。
他の回答では私が実際には見られないいくつかのポイント。
開発とテストのスキルセットは重複する場合がありますbut優れたテスターを作る人もいれば、優れた開発者を作る人とは異なる人もいます。開発者として、優れたQA部門は、金の重さに見合う価値があります。特にallを自分でテストすることを強制する、特に誰か他の人のコードWebページの動作を変更する可能性があります。テストしたときと、変更の組み合わせが有効になるときは...逆です。したがって、変更のストリームが一定している場合は、マージした後の最終結果をテストすることがかなり重要です。
開発者は、何がテストが必要か、何がうまくいかないかなどを教えてくれるでしょう。あの人達の話を聞いて。
OPで見たもう1つのポイントは、開発者が1つのテストフレームワークを使用することに慣れた後、統合テストの量を減らすというWebサイトで誇る別のフレームワークに切り替える決定があったことです。など。
あなたはしなかったこの決定がなされた理由、およびこの変更のためにトレーニングまたは学習時間が確保されたかどうかについて言及します。彼らはこの新しいフレームワークをに加えて、機能開発やバグ修正などの期待されるペースで作業を継続することを学ぶことを期待されていましたか？
これをProject Managementスレッドで取り上げることを検討してください。
ただし、–自動テストが伴わない限り、彼らの仕事は受け入れられないことを彼らに単に伝えてください。 「はい、これはあなたの仕事の一部です。」外部テスターはあなたを正直に保つためだけにあります。
私自身、生涯にわたるソフトウェア開発者として（およびコンサルティングプロジェクトマネージャーとして）、「私のa * sは保存されました。私が作成したテストでは、他の誰も作業を行わない自分自身のコードでも、それを作成していたためです。私が頻繁に「正しく取得できませんでした。」そして、以前のテストが突然失敗し始めたとき、私は時々驚かされました。見つけて直した「おっちゃ！」次から次へ...チャンスが来る前に。そして、このようにして、コードのレイヤーを重ねて構築しましたそれが正しいことを知っています。
「それがテストされるまで受け入れられない、そして私たちはあなたのテストを拒否する権利を留保する」というあなたの背後にある管理サポートを得てください。
そのような環境では、レビューがうまく機能する場合があります。
開発者として私は同じように感じています。テストの作成は退屈です（特にユニットテスト）。そして、それらは常に有効であるとは限りません（特に単体テスト）。それはあなたが書くロジックのタイプとあなたが得る入力の種類に依存します。 100％指定された要件は私の経験ではそれほど一般的ではないので、実際にテストで何が証明されますか？やる気を起こさせる可能性があるからといって、人々に単体テストを書くことを要求する。したがって、「バグ」を最も多く生み出している人々を恥ずかしくすることができます（彼らは、最も価値のあるものと同じものである可能性があります）。
同僚からのプレッシャーがより効果的です。あなたはお互いに慣れる必要があり、これは少し傷つくかもしれませんが、結局あなたはチームを持つことになります。従わなければならない人々によってサポートされていない外部ルールを課すことによってチームを獲得することはできません。
オフショアのテスト担当者全員を辞任することもお勧めします。つまり、とにかくそうすることが信頼されておらず、とにかく自分の作業を検証する別のレイヤーがある場合に、完璧な動作を実現しようとするのはなぜですか？どうやらこれが私たちの仕事のやり方ですよね？彼らがそこにいる間、彼らが私の人生を少し楽にして、私が修正するための緩い目的を見つけさせてください。それで、私はそれにあまり力を入れる必要はありません。
そのセーフティネットがなかったら...私はもっと慎重になるでしょう。私は尊敬され責任があると感じます。 「あなたはがらくたを出して、あなたが生産したものすべてを精査するつもりです」のような態度で、私は一生懸命頑張ろうとは思わないでしょう。
私たちの組織は、開発者が自分たちの変更を実際にテストしないという問題をプロセスの一部にすることで解決しました。
- テストに変更を加えるには、変更のドキュメントを提供する必要があります。
- ドキュメントは、標準化されたテンプレートを使用して作成する必要があります。
- このテンプレートには、次の必須セクションが含まれています。
- 変更の理由は何ですか？
- 何が変更されましたか？
- 開発者が変更の基本的なテストを行う「機能テスト」。その実行と結果をスクリーンショットで文書化し、変更の目標が達成されたことを示します。このテストは、実際のQAチームが実行するテストほど完全ではありません。これは、開発者に関する限り、現在は機能しているように見えることを示すためだけのものです。
このようにして、すべての開発者は変更されたコードを少なくとも1回実行する必要があります。
「完了の定義」が必要です
一般的に受け入れられている「完了の定義」には、機能するコードだけでなく、機能する単体テストやドキュメントも含まれます。それらが完了するまで、タスクは実行されません。コードは実行できず、は実行できませんテスト部門または禁じられた神に解放され、生きる。
アジャイル/スクラムの傘の下に概念が見つかることがよくありますが、このアイデアを実装するためにその作業フレームワークは必要ありません。
https://www.scruminc.com/definition-of-done/
https://www.agilealliance.org/glossary/definition-of-done/
テスターは、あなたが考えていなかったこと、奇妙なユースケース、または正直に見落としたことをキャッチするためにそこにいます。
開発者は、実際に達成しようとしている結果（おそらく、開発コストと特定の品質レベルで展開されている企業から得られる価値とのバランスをとる機能）に集中することで、テスターに「過度に依存」しないように奨励できます。開発者に、この目標を達成するためにテスターにどれだけ依存するかを決定させる。つまり、開発チームの一員でない限り、開発チームが管理すべき何かを管理しようとしていることになります。
「完了」の修正
最初に行う必要があるのは、「完了」の定義を修正することです。開発者は、
...ブラウザで機能する場合、実際には[チェック]しなくても機能に完了のマークを付けることがあります。テスターは間違いを見つけてしまうので、なぜわざわざ？
まず、「完了」を「変更は実際の顧客が使用できるように本番環境に移行する準備ができている」と再定義します。次に、各開発者に、「完了」ステージに特定の変更を加えるプロセスの管理を担当させます。これには、自動テストを作成して実行すること、コードとテストの指示を人間のテスターに送信して結果を確認することなど、開発者が必要と考えるあらゆるテストを確実に完了させることが含まれます。
開発者がそれを「完了」と宣言した後で、何らかの変更が欠陥であることが判明した場合は、開発者と一緒に座ってレビューを行うときです。このレビューは、開発者と開発チームの1人以上の上級メンバーの間で行う必要があります。 （これには、製品所有者側の誰かが含まれる場合と含まれない場合があります。以下を参照してください。）このレビューは対立的であってはならず、何かが間違って行われたと想定することから始めるべきではありませんが、リリースされた（またはリリースされ、時間内にそれを見つけた場合）欠陥を見つけ、それを回避するためにどのような費用効果の高い対策を講じることができるか、つまり、開発者（および開発チーム）が物事を改善するために何を変更すべきかを検討します。 （答えは、「何もない。このようなすべてまたはほとんどのものを防ぐためのコストは、それらと一緒に暮らすコストよりも高い」かもしれません。）
そのような会議の製品オーナーは、存在する場合、技術的または手順上の変更をチームに要求するのではなく、他に次の2つのことを行います。欠陥が時間内に捕捉された）、および2.この種の問題を防止するために製品所有者が追加費用を支払うことを望んでいるかどうかを評価する。 （たとえば、開発者は、「この種の発生率を50％減らすことはできますが、開発を5％遅くすることができます」と言います。製品の所有者は、リリース時の品質の向上が遅い速度に見合うかどうかを判断できます。機能がロールアウトされました。）
開発者がテストを管理する
変更を人間のテスターに送信することは、高レベルでは、自動テストを作成することと大差ありません。テスターまたはテストシステムが従うべきスクリプトの種類があり（「このURLにアクセスして、あなたの考えを教えて」のように単純であっても）、開発者は結果を評価して、彼女が完了したか、または実行する必要があるかを判断しますより多くの作業（コードの変更またはより多くのテストの実行）。
このスクリプトは、上記のミーティングで（またはその準備として）他の開発者がレビューできる場所に保管する必要があります。また、変更履歴も保持する必要があります。開発者がそこから何かを削除した場合（おそらく、問題のあるものをカバーするために自動テストを追加したか、人間のテスターが実行するのに時間がかかりすぎたため）、レビューはその決定を調べることができます。 （個人的に、私は通常、この情報をソースコードリポジトリ自体、テキストファイルまたはマークダウンファイルに保存しますが、開発者は彼らとテストチームにとって適切に機能するものは何でもすべきです。）
最初のスクリプトには、おそらく製品所有者からの話、そのコードのテストに必要なものをセットアップする方法の説明、および開発者が投入するのに役立つと思われるその他のメモが含まれます。
何でもそうですが、これを経験していない開発者は、おそらく開発チームの他の人からのサポートが必要になります。ユニットテストの経験がほとんどない開発者でも、すぐに優れたユニットテストを作成できるとは限らず、何をテストする必要があるかを理解することさえできません。手動テストの管理についても同様です。
ただし、開発者はここでの目標に注意を払う必要があります。製品所有者が行うすべての受け入れテストに合格するか、製品所有者が行うと見なすという意味で、何かを「完了」として宣言できるようにする必要があります。彼が開発者をそれほど信用していなかった場合、および製品所有者が開発者に話を聞いてコーディングを開始した後に製品所有者が考える可能性のあるテストでさえも。
受け入れ
上記でやや省略したことがあります。それは、別々のチームの管理下にある2つの「完了」ステージが実際にあるということです。 1つ目は、開発チームの "完了"ステージです。これは、前述のように、 "すべての受け入れテストに合格することを期待しています"ことを意味します。 2つ目は、製品の所有者の「この変更を受け入れます。リリースしましょう」です。この側で製品の所有者が行う作業の量は、開発チームがどの程度優れているかによって異なります。開発チームが要件の解釈と要件を満たすコードの記述に非常に信頼できることがわかっている場合、製品の所有者は最小限のテストを行うことができます。開発チームがこのような素晴らしい仕事をしていない場合、製品の所有者はさらに検証する必要があります。
現在このスペクトルに立っている場合、それほど重要ではありません。重要なことは、受け入れテストが失敗した場合、開発チームがそれがどのように失敗したか（つまり、そうでないと誤って「完了した」と感じた理由）をレビューし、開発することです。受け入れテストで将来の同様の失敗を防ぐためのシステム。特定のインスタンスでこれを改善することは、開発チームが対処する純粋に内部の技術的な問題である可能性があります。または、一部の障害は、製品の所有者と開発チーム間の通信の問題が原因である可能性があります。それを修正する方法。
概要
自動テストの作成とテストチームへのコードの送信は、変更をリリースするのに十分な品質であることを確認するという目標を達成するための2つの異なる方法です。それらはほぼ常に一緒に使用され、使用するそれぞれの量についての決定は、変更を行う開発者に委ねる必要があります。これは、コードの記述方法の選択に密接に影響されるためです。したがって、彼女はそれを管理する必要があり、それをうまく管理するために必要なサポートが必要です。
政策は極端なものから別の極端へと進んだようです。 100％のテストカバレッジで実際に作業するのを見たことがありません。関数のテストを作成するために必要な時間と詳細の間のトレードオフとテスト自体の利点は、通常、非常に変動します。トレードオフを考慮せずに100％のテストカバレッジを率直に要求すると、開発者は一部のテストを作成するのに必要な時間よりも多くの時間を費やすことになります。
柔軟なアプローチが良いでしょう。最小限のテストカバレッジを要求し、関数のテストを記述するのがどれほど難しいかを試して判断するよう開発者に伝えます。ただし、開発者ではない別の人がレビューを行い、頻繁に変更される関数や、簡単に壊れる可能性のある複雑な要件があるかどうかを確認し、それらの関数にテストが必要な関数としてフラグを立てる必要があります。
役立つもう1つのことは、テストツールに最も熟練した開発者を見つけ、最も難しい部分のテンプレートを開発するように依頼することです。多くの場合、特定の関数を中心にモックを構築する方法を見つけるには、本当に長い時間がかかります。一連のパターン/ソリューションがすぐ近くにあると、多くの時間を節約できます。
非常にシンプルな解決策があります。
開発者との会議を呼び出します。その会議で、「現在、プロセスに問題があります。現時点では、送信されたコードが適切に機能しないことがよくあります。そのため、QAはバグレポートの作成に多くの時間を費やしています。その後、これらのバグを修正するための開発時間を要します。以前は、開発の品質が非常に高いという問題がありましたが、莫大なコストがかかりました。 QAに渡される問題が多すぎないため、全体としてより効率的に作業できます。」.
いくつかの回答は難易度に焦点を合わせすぎて、最良のポイントを見つけることができません。必須ではありません。非効率的である一方の極端にポイントがありましたが、非効率的であるもう一方の極端にポイントがあります。中間にさらに進むと改善になります。最適点が見つからないからといって、改善を無視しないでください。
2つのトピックが公開されたとき、あなたは質問に答えました：「プログラマーはコードをテストするのをためらっています。なぜなら、（1）彼らはコードを退屈に感じるだけであり、（2）コードをテストしないと、彼らは機能をより速く提供します。」どういう意味ですか？計画されているテストがない場合の配信方法。 MavenまたはGradle、またはビルドに沿ってすべてのテストを実行した後にのみ、任意のプロジェクト/モジュールを配信（GITに置くことも可能）できます。ユニット開発のインプットとは？アナリストまたはアーキテクトは、コンポーネントのテストの対象となるケースのリストを提供する必要があります。最悪の場合、テストエンジニア（テストの責任者）は最初にテストをリポジトリに入れ、開発者はプルリクエストでそれらを取得します。 Maven/gradleが作業を行います。配信に加えて、テストに最初の注意を払ってコードレビューに合格する必要があります。そして、そのとき初めて、変更は、産業用ビルドに使用したブランチとマージできます。テストなし-配達なし、作業は行われません！それで全部です。
「最悪のパフォーマンスをした人とペアプログラミングをして、なぜコードをテストするのがとても嫌いなのかを理解し、それほど難しくないことを彼らに示します。」実際、ペアプログラミングとしてのXPの要素は、一部の作業を行うことに消極的である開発者にABCを表示するためだけのものではありません。テスト-テストだけでなく、それは彼らの仕事の一部（重要）であり、ポジションの定義になければなりません。あなたが言及したアプローチは、テスターだけでなく他の開発者にも時間を費やしているということです-それが新参者（初心者！）吸着の最初の段階にある場合を除きます。 DevOpsを含むお客様の環境は、原則に従って構築する必要があります。すべてのPREDEFINEDテストに合格したコンポーネントのみが実行されます。それ以外の場合は、配信されません。