ユニットテストに「投資」するよう経営陣にどのように説得しますか？
ユニットテストを許可するようにマネージャーにどのように説得しましたか？
「使用」とは、開発、ソース管理へのチェックイン、ユニットテストの長期にわたる維持などを許可されることを意味します。
一般的な管理の異論は次のとおりです。
- 顧客は単体テストの料金を支払わなかった
- プロジェクトでは、単体テストの時間を許可していません
- 技術的負債？どんな技術的負債？
他の異論を知っていますか？あなたの答えは何でしたか？
前もって感謝します！
私が最近この問題に遭遇したのは、顧客が私たちの方法論に参加していたときです。しかし、より高い経営陣は、開発者が開発ではなくテストに時間を費やしていて、これについて心配しているように感じました-結局のところ、テストを行うQAスタッフがいました！ここでそれをどのように処理したかについてブログに書きました：
http://practicalagility.com/show-them-the-numbers-its-results-that-matter/
要約すると、プロジェクトの推定時間と実際の時間を比較してから、不良率を他のチームの不良率と比較しました。私たちの場合、これらの数値は好意的に比較され、心配はありませんでした。
この経験に基づく私の結論は次のとおりです。
...何かを行うためのあなたのアプローチが実用的で実用的であることをだれにも納得させる最良の方法は、それを実行し、他のアプローチに対してそれを測定することです。人ドグマや、なぜ何かが最善の方法であると考えるのかを気にしないでください。人々に数を示し、アプローチの有効性を測定することによってのみ、あなたの実践が効果的であることを本当に示すことができます。
他のプロジェクトでは、ユニットテストを作成したりTDDを実行したりしなかったお客様の開発者と協力して、破壊されたテストを維持する必要がありました。ただし、顧客の開発者がコードのどこに問題があるかを知らないうちに伝えることができれば、TDDアプローチを顧客の開発者に販売するのは非常に簡単になります。
したがって、あなたのケースでは、必要に応じてステルスでそれを行います（おそらく、変更を頻繁にテストしたり、責任を負ったりするコードの小さな領域があるかもしれません）があなたの数を追跡します-あなたのテストを作成するための努力は何ですか？不良率とは何ですか？これは他のプロジェクト/チームメンバーとどのように比較しますか？
私の意見では、誰もが許可を求めたり、自分の仕事を適切に実行したいと思ったことを謝罪したりする必要はありません。うまくいけば、それはあなたの場合これら両方のことです。幸運を！
投資収益率（ROI）を示す
自動テストの作成には時間がかかります。一度。自動化されたテストの実行中は、実行中に他のことができるため、時間はかかりません。
例：機能Xの手動テストには30分かかります。自動テストの作成には1時間かかります。バグがない場合でも、依存するレイヤーとコンポーネントが変更されるため、プロジェクトの過程でフィーチャーXを10回テストする必要があります。したがって、機能Xのテストを自動化すると、プロジェクトの全期間にわたって4時間節約できます。
実際には、自動テストが実際に効果を発揮するのは、バグが発生したときです。まず、バグを早期かつ安価に見つけられるため、時間と恥ずかしさを節約できます。第2に、難しいバグがあり、それを理解するためにコード構築テストのサイクルを何回も繰り返すと、手動テストに比べて節約された時間は非常に速くなります。
企業は時間とお金の節約を理解しています。それがそれを売る方法です。
それらにすでに直面していて、彼らはそれで大丈夫ではないが、あなたがそれらなしでコードを書くことを快適に感じないなら...そしてもう一度尋ねないでください。それらを書いて、チェックインしないでください。
経営陣はコード行を数えませんが、すべてのチェックインのQA（または顧客）からの合格率が高いことがわかり、最終的に理由を尋ねられます...そうすれば、すべて "BAM！TDD ！」
あなたはプロジェクト、プロセス、またはソースをいじっていません...だから私は否定的な理由はないと思います。正直なところ、手動のrun + input + checkの結果テストをすべて実行するのと時間的に異なる理由はわかりません。
1）顧客は単体テストの料金を支払わなかった
顧客（彼らは思った）は実用的なソリューションの代金を支払いました。契約によっては、欠陥を修正することが実際にあなたの会社に利益をもたらすかもしれません。十分なロックがある場合。つまり、有効なソリューションの支払いに戻ります。 TDDはその目標を支援する必要があります。
2）プロジェクトはTDDの時間を許可していません
TDDは長くかかりません。無関係なコードや余分なコードの量を減らし、テストをパスするものにコードベースを集中させる必要があります。合格したすべてのテストは、テストの品質と適切さを条件として、コードが完了したことを意味します。
3）技術的負債？どのような技術的負債がありますか？
既存のコードにテストを遡及的に追加することについて議論しているのではないかという印象を受けます。これは最高の時に悪夢のような売りであり、あなたが期待する利点をもたらさない。ただし、バグを修正するときにテストを追加することは受け入れ可能であり、長期的には役立つはずです。
Snorfusが示唆しているように、私はとにかくテストを書くことを勧めません。理論的にはいいように聞こえますが、ユニットテストcanおよびdoは時間とともに変化します。要件が変わると、新しい機能が追加され、単体テストを更新する必要があります。チームの一部として作業している場合、他の人が機能や修正を追加すると、ユニットテストは古くなります。
新しい点を上げるのではなく、あなたが言及した特定の点に取り組んでいます。それは、進歩するか、なぜそれがコックブロックされているのかを理解する余裕があるからです。
生産の問題に直面しているすべての顧客にとって、
ユニットテストを作成し、シナリオをカバーするためにユニットテストを追加したことを示すメールをマネージャーに送信します。
また、ユニットテストは夜間に実行されるため、この問題は本番環境では再び発生しないことを伝え、コードが本番環境に移行する前に、このユニットテストの失敗を監視することで問題が発生することを知らせます。
コードが本番環境に移行する前にすでにこのユニットテストを実施している場合、この本番環境の問題は発生しなかったと彼に伝えてください。
これを一貫して永続的に行うと、すぐに彼は納得するでしょう。マネージャーは、生産の問題に直面している顧客を嫌い、ユニットテストのアイデアに賛同します。幸運を。