どのようにしてユニットマネージャーにあなたをマネージャーに納得させましたか？

「使用」とは、ソース管理への開発、チェックイン、および長期にわたる単体テストの維持などを許可することを意味します。

一般的な管理の反対意見は次のとおりです。

1. 顧客は単体テストの費用を支払わなかった
2. このプロジェクトでは、単体テストの時間が許可されていません
3. 技術的負債？どのような技術的負債ですか？

他の異議を知っていますか？あなたの答えは何でしたか？

前もって感謝します！

顧客が私たちの方法論を使用していたときにこの問題に最近遭遇しましたが、上級管理職は開発者が開発ではなくテストに時間を費やしており、これを心配しているという風になりました-結局、彼らはテストを行うQAの人々がいました！私はそれをここでどのように扱ったかについてブログに書いた：

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

要約すると、プロジェクトの推定時間と実際の時間を比較してから、欠陥率を他のチームの欠陥率と比較しました。私たちの場合、これらの数値は好意的に比較され、それ以上の懸念はありませんでした。

この経験に基づく私の結論は次のとおりです。

...何かをするあなたのアプローチが実用的で実用的であると誰にでも納得させる最良の方法は、それをして、他のアプローチと比較することです。人々はドグマを気にしない、またはなぜあなたは何かが最良の方法であるべきだと思うのか。人々に数字を見せ、アプローチの有効性を測定することによってのみ、あなたの実践が効果的であることを本当に示すことができます。

他のプロジェクトでは、単体テストを作成したりTDDを実行したりしていない顧客開発者と協力し、彼らが破ったテストを維持する必要がありました。ただし、それらの顧客の開発者にTDDアプローチを販売することは、彼らが知る前にコードのどこが壊れているかを伝えることができれば非常に簡単になります！

だからあなたの場合、必要に応じてステルスでそれを行います（おそらく、変更を頻繁にテストしたり、担当しているコードの小さな領域があります）が、数字を追跡します -あなたのテストを作成するための努力？不良率とは何ですか？これは他のプロジェクト/チームメンバーとどのように比較されますか？

私の意見では、誰も許可を求めたり、自分の仕事をきちんとやりたいと謝罪したりする必要はなく、プロの開発者は可能な限り実用的なところで自動テストでコードをテストしようとするべきです。うまくいけば、それはあなたの場合、これらの両方のことです。幸運を！

投資収益率（ROI）を表示する

自動テストの作成には時間がかかります。一度。自動化されたテストの実行には時間がかかりません。実行中に他のことを実行できるためです。

例：機能Xを手動でテストするには30分かかります。自動テストの作成には1時間かかります。バグがなくても、依存層とコンポーネントが変更されるため、プロジェクトの過程でフィーチャーXを10回テストする必要があります。したがって、機能Xのテストを自動化すると、プロジェクトの全期間にわたって4時間節約できます。

実際には、自動テストが本当に成果を上げるバグがある場合です。まず、バグを早期かつ安価に発見するため、時間と恥ずかしさが節約されます。第二に、難しいバグがあり、それを把握するためにコードビルドテストの多くのサイクルを経る場合、手動テストよりも節約される時間が非常に速くなります。

企業は時間とお金の節約を理解しています。それがそれを売る方法です。

既にそれらに直面していて、彼らはそれで大丈夫ではないが、あなたはそれらなしでコードを書くことを快適に感じていないなら...そして再び尋ねないでください。それらを書いて、チェックインしないでください。

経営陣はコードの行をカウントしませんが、すべてのチェックインがQA（または顧客）からの合格率が高いことを確認し、最終的にその理由を尋ねます... ！」

あなたはプロジェクト、プロセス、またはソースをいじっていません...だから私は否定的な理由は見ていません。正直なところ、すべての手動実行+入力+チェック結果テストを実行するよりも時間的に異なる理由はわかりません。

1）顧客は単体テストの費用を支払わなかった

顧客は（彼らが）実用的なソリューションの代価を支払ったと思った。契約に応じて、欠陥を修正することは実際にあなたの会社にとって利益があるかもしれません。十分にロックインされている場合は、作業ソリューションへの支払いに戻ります。TDDはその目標に役立つはずです。

2）プロジェクトはTDDの時間を許可しません

TDDには時間がかかりません。余分なコードや余分なコードの量を減らし、テストに合格するものにコードベースを集中させる必要があります。テストの品質と適切さを条件として、合格したすべてのテストは、コードが完了したことを意味します。

3）技術的負債？どのような技術的負債ですか？

既存のコードにテストを遡及的に追加することについて議論しているのではないかという印象を受けます。これは最高の状態で悪夢のような売りであり、あなたが期待するかもしれない利点をもたらしません。ただし、バグを修正するときにテストを追加することは受け入れられ、長期的には役立ちます。

とにかくSnorfusが示唆したように、テストを書くことはお勧めしません。これは、理論的には素敵に聞こえるが、ユニットテストをすることができますし、やる時間変化を。要件が変更されると、新しい機能が追加され、ユニットテストを更新する必要があります。チームの一員として作業している場合、他の人が機能/修正を追加すると、ユニットテストは古くなります。

新しい点を上げるのではなく、あなたが言及した特定の点に取り組んでいます。進歩を遂げたり、それがコックブロックされている理由を理解する余地があるからです。

生産上の問題に直面しているすべての顧客に対して、

1. ユニットテストを作成し、シナリオをカバーするユニットテストを追加したことを伝えるメールをマネージャーに送信します。

2. そして、ユニットテストは毎晩実行されるため、この問題は本番環境では二度と起こらないことを伝え、このユニットテストの失敗を見ることでコードが本番稼働する前に知るようになります。

3. コードを実稼働する前にこのユニットテストを既に実施していれば、この実稼働の問題は発生しなかったことを彼に伝えてください。

これを一貫して永続的に行うと、すぐに彼は確信します。マネージャーは、顧客が生産上の問題に直面することを好まないため、ユニットテストのアイデアに賛同します。幸運を。