マネージャー向けの単体テストに関するプレゼンテーションを準備しています。私のチームは何年も単体テストを書いてきましたが、会社の他の部門はそれを採用するのに苦労しているようです。開発者を興奮させることはできますが、経営陣の賛同がなければ、標準にはなりません。
これについて経営陣にアプローチする最善の方法について提案はありますか? 過去に試した中で効果があったものは何ですか? うまくいかなかったものは何ですか？
2191 次
12 に答える
11
技術系以外のマネージャーの場合、私は家を建てることに例えました。青写真なしで、積み上げられたレンガを積み上げて、漠然とした家の形のアイデアを念頭に置いて、それを構築しますか? そうでない場合、コーディングや設計レビューなどの前に適切なドキュメントを受け入れないのはなぜですか?
単体テストでは、さまざまな家の構成要素 (レンガ、セメント、ドア、窓、配管) を組み立てる前に個別に品質テストを行うことと比較してみることができます。
技術をまったく理解していない人のために、30% から 50% がエラー状態と回復 (ミッション クリティカルな組み込みシステム) を処理し、ユニット テストなしではテストできないことを述べます。EG、ブラックボックス統合テストのみの場合、モジュール A が特定の時点でメモリを割り当てられない場合、または応答メッセージを待っているときにタイムアウトがモジュール C の奥深くで期限切れになった場合に、制御された反復可能な方法でどのようにテストできますか?どこかから、または通常は成功するデータベースの読み取り。インターフェイス モジュールをダミーで作成することにより、モジュールの誤った動作を自由にシミュレートできることを説明します。
そしてもちろん、私はお気に入りのグラフを 1 つの軸に $ 記号、もう 1 つの軸に時計を描いています。私はあらゆる機会にこれを使って経営陣を打ち負かし、バグを発見するのが遅くなるほどコストが増加することを示しました (要件仕様の行を変更する – 5 分; 設計ドキュメントのいくつかのパラグラフを変更する – 時間; 数 100コード行数 (コード レビューまたは単体テスト段階) – 数日、干し草の山から針を見つけてシステム テストで修正する – 数週間)。
単なる単体テストではありません。経営陣と仲間の開発者に、文書化、レビュー、テストの「不必要なオーバーヘッド」... ソフトウェア プロセス全般 (および新しいツールの学習を含む) ... 実際にはプロジェクトに時間を追加するのではなく、時間を節約します。言い換えれば、それを間違えると、より長い時間がかかり、より多くの費用がかかります。二度測る、一度切る、など
単体テストについては、継続的インテグレーションについて教えてください。Jenkins を強くお勧めしますが、自分に合ったものを使用してください。毎晩またはチェックインごとに定期的なビルドを行うと、VCS からユニット テストを自動的に取得して実行し、電子メールを送信するか、既存のテストを壊した新しいコードが発生するとすぐにアラートを送信できることを説明します。
それでもうまくいかない場合は、新しい仕事を探してください (シンガポールにいる場合、またはなりたい場合は、私に相談してください ;-)
于 2010-08-04T23:45:57.547 に答える
3
テストですでに問題が発生し、その日を節約した例を示してください。
于 2010-08-05T07:24:28.290 に答える
2
@hvgotcodesの回答に基づいて構築するには、それがどのように改善するかを伝えるだけでなく、自分のチームからの統計をまとめてください。
- ターンアラウンドの減少
- $コストの削減
- 回帰の減少
- 等
特にコスト、企業はお金を節約するのが大好きです:)
于 2010-08-04T23:25:18.637 に答える
2
場合によっては、適切な機会を待つことが重要であることがわかりました。
たとえば、あるケースでは、顧客とのホットサイトができるまで待ちました。それは非常に苦痛でした（$$$を考えてください）。上級管理職からの避けられない質問の1つは、将来同じ問題を回避する方法でした。そして、それは私が経営陣にユニットテストを提示したときです...
ですから、状況にもよると思います。
于 2010-08-05T01:52:18.243 に答える
2
誤解しないでください。
コストの削減に言及する場合、QA と簡単なリファクタリングのコストが、テストの作成と保守のコストよりも大きいことを暗示しています。それを指摘し、あなたの主張を補強するためにいくつかの指標を導入しようとすることは良いことです.
問題は、選択しなかったパスに金額の価値を付けられないことです (「修正に 100 万ドルの費用がかかる 1,000 件の欠陥を回避しました!」)。
ただし、テストの作成にはコストがかかること、およびテストを維持する必要があることを率直に認識しておく必要があります。それらを作成してから荒廃させると、同じように悪いことになります。
新しい機能を追加しようとすると、あなたの主張が後押しされ、コードをきれいに保っているので簡単になります。
于 2010-08-04T23:36:38.007 に答える
2
1 - 彼らは知る必要がありますか、それとも承認する必要がありますか? あなたはエンジニアであり、機能するものを構築する方法を彼らよりよく知っているので、彼らが干渉するべきではありません。あなたが彼らのために作った新しい車のモデルだった場合、彼らはあなたがどのようなツールを使用し、どのような品質/安全性保証方法を使用したかを気にしますか? そうは思わないでしょう。
2 - 欠陥のコストが非常に高い。低品質、欠陥、および技術的負債は、ソフトウェア プロジェクトの投資全体を危険にさらす可能性がある非常に深刻なプロジェクト リスクです。欠陥防止は、欠陥検出よりも簡単に費用対効果が高くなります (調査によると、何倍にもなります)。単体テストのフィードバック ループは可能な限り最短であるため、体系的なプロジェクトの品質低下を回避し、プロジェクトのリスクを大幅に軽減できます。
3 - 非常に低い欠陥率がなければ、長期間にわたって迅速に進むことはできません。別名、投資は支出/投機に勝っています (これは彼らが得なければならないことです)。
于 2010-08-11T15:14:48.503 に答える
2
非技術系のマネージャーに関する限り、統計は最良の事例になると思います。コード コンプリート、第 2 版。には、単体テストで平均 30% の欠陥検出率が得られることを示すいくつかの研究の要約があります (表 20-2、p 470)。そこからそれを取り上げて、バグの減少がより多くのお金の節約につながると主張するのは簡単だと思います.
于 2010-08-05T00:32:59.440 に答える
1
ユニットテストは、うまく行われていれば、
- バグを早期にキャッチすることで、QAまたは本番環境で検出されるバグの量を減らし、バグ修正のコストも削減します。
- リファクタリングをサポートし、設計をクリーンで拡張可能な状態に保ちます。これにより、長期的にはメンテナンスが安価になります。
これらの主張を具体的に裏付けることができる、社内で収集された関連する統計はありますか？つまり、QA /ユーザーがさまざまな製品で見つけたバグの数、または平均的なバグ修正/機能の実装コスト、...
于 2010-08-04T23:27:52.393 に答える
1
可能であれば、テストなしでライブコードをサポートするときに、あなたの会社が過去に直面した困難の実例を提供しようと思います。次に、特定の例を使用して、テストが実施された場合の更新と修正のサポートコストの削減を強調します。
頑張って、どうやって乗るか教えてください。:)
于 2010-08-05T07:28:35.353 に答える
1
コードの保守性が向上し、長期的にはお金を節約できることを伝えてください。正しく行われれば、バグも減少します。
つまり、コストを削減し、ソフトウェアの信頼性を向上させます。
于 2010-08-04T23:20:04.070 に答える
1
単体テストとしてだけでなく、動作駆動開発またはテスト駆動開発として提示します。
BDD と TDD のどちらにも、技術者でなくても簡単に理解できる利点があります。実際、彼らの主な利点の 1 つは、非技術的なことに重点を置いていることです。
一方、単体テストは技術的な概念であり、プログラマー以外にとっては非常に抽象的です。コードをテストしますか? 開発中にやらないの？なぜ私たちはテストスタッフにお金を払っているのですか? 等々。
于 2010-08-06T10:39:22.160 に答える
0
メールクライアントやドキュメントエディタのスペルチェッカーなど、マネージャーがおそらく定期的に使用するものに例えます。
于 2010-08-11T16:04:51.400 に答える