若手プログラマーにテストを書かせるにはどうすればよいでしょうか?[閉まっている]

https://stackoverflow.com/questions/7252

08-06-2019
|

質問

十分なテストを書けない若手プログラマーがいます。
私は 2 時間おきに彼に「テストを書いたことがありますか?」と小言を言わなければなりません。
私たちは次のことを試しました:

デザインがよりシンプルになることを示しています
表示することで不具合を防止します
悪いプログラマだけがそうしないとエゴにしてしまう
今週末、チームメンバー 2 人がコードに NULL 参照があり、テストしなかったため、出勤しなければなりませんでした。

私の仕事には最高品質の安定したコードが必要ですが、通常は誰もが「理解」しており、テストを進める必要はありません。彼にテストを書かせることができることはわかっていますが、役に立つテストとは、夢中になっているときに書かれたものであることは誰もが知っています。

さらに多くの動機を知っていますか？

解決

これはそのうちの 1 つです 最も難しいこと すること。従業員に それを得る.

場合によっては、ジュニアレベルのプログラマーが「理解」し、上級者から適切なテクニックを学ぶのに最適な方法の 1 つは、ペアプログラミングを少し行うことです。

これを試して：今後のプロジェクトでは、後輩を自分または他の上級プログラマーとペアにします。彼らは交代で「運転」（キーボードを打つ人）と「コーチング」（ドライバーの肩越しに見て、運転中に提案や間違いなどを指摘する）をしながら協力しなければなりません。リソースの無駄のように思えるかもしれませんが、次のことがわかります。

これらの人たちが協力すると、非常に高速かつ高品質のコードを生成できるようになります。
あなたの後輩の男性が、先輩の男性から正しい道に沿って指示を受けて「理解する」のに十分な学習をした場合（例：「わかりました。続行する前に、この関数のテスト時に書きましょう。」) これにリソースを投入する価値は十分にあります。

グループの誰かに単体テスト 101 Kate Rhodes によるプレゼンテーションは、うまく伝えられれば、人々をテストに興奮させる素晴らしい方法だと思います。

もう一つできることは、ジュニアを持っていることです。開発者が実践するのは、ボウリングゲームの型これはテスト駆動開発を学ぶのに役立ちます。Java で書かれていますが、どの言語にも簡単に適応できます。

他のヒント

すべてのコミットの前にコードレビューを実施し (「この変数名を変更しました」という 1 分間であっても)、コードレビューの一環として単体テストをレビューします。

テストが完了するまでは、コミットをサインオフしないでください。

(また、もし彼の作品がテストされていなかったとしたら、そもそもなぜそれが実稼働ビルドに含まれていたのでしょうか?テストされていない場合は、入れないでください。そうすれば、週末に働く必要がなくなります）

私自身としては、見つけて修正するすべてのバグをテストとして表現することを主張し始めました。

「うーん、それは違います…」
考えられる問題を見つける
テストを作成し、コードが失敗することを示します
問題を解決します
新しいコードが合格することを示す
元の問題が解決しない場合はループします

作業を進めながらもこれを実行しようとしていますが、すでに部分的なテストスイートが用意されているだけで、ほぼ同じ時間で完了します。

(私は商用プログラミング環境に住んでいないため、多くの場合、特定のプロジェクトに携わる唯一のプログラマーです。)

私が模擬プログラマーで、名前は...マルコ。私が学校を卒業してそれほど時間が経っていないのに、実際にテストを書く必要がなかったと想像してください。私がこれを強制したり要求したりしない会社で働いていると想像してみてください。わかりました？良い！ここで、会社がテストの使用に切り替えており、私をこれに従わせようとしていると想像してください。ここまで述べた事項については、まるで調べていないかのようなやや嫌味な反応をします。

作成者と一緒に始めましょう:

デザインがよりシンプルになることを示しています。

もっと書くことで、物事がよりシンプルになるのはなぜでしょうか。これからは、より多くの症例を取得できるかどうかなどを監視する必要があります。私に言わせれば、これはさらに複雑になります。しっかりとした詳細を教えてください。

表示することで不具合を防ぎます。

私はそれを知っています。これが、それらがテストと呼ばれる理由です。私のコードは良好で、問題がないかチェックしましたが、それらのテストがどこに役立つのかわかりません。

それをしないのは悪いプログラマだけだと言って、それをエゴにしてしまう。

ああ、私が中古テストをあまりしないという理由だけで、私が悪いプログラマーだと思っているのですね。私はあなたを侮辱しており、積極的にイライラしています。私は言葉よりも支援やサポートが欲しいです。

@ジャスティン・スタンダード:新しいプロジェクトを開始するときは、後輩を自分または別の上級プログラマーとペアにします。

ああ、これは非常に重要なので、物事がどのように行われるかを確認し、物事がどのように行われるかを支援してもらうためにリソースが費やされます。これは便利なので、もっとやり始めてもいいかもしれません。

@ジャスティン・スタンダード:読む単体テスト 101 ケイト・ローズによるプレゼンテーション。

ああ、テストについて考えさせられる興味深いプレゼンテーションでした。それは私が考慮すべきいくつかの点を打ち出しました、そしてそれは私の見解を少し揺るがしたかもしれません。

もっと説得力のある記事や、これが物事を行う正しい方法であるという考えに沿って進むのに役立つその他のツールを見てみたいと思っています。

@ドミニク・クーニー:時間をかけてテストテクニックを共有してください。

ああ、これはテクニックに関して自分に何が期待されているかを理解するのに役立ちますし、知識の袋にさらに多くの項目が追加され、再び使用できるようになります。

@ドミニク・クーニー:質問、例、本に答えます。

質問に答えてくれる担当者がいると助かるし、挑戦する可能性も高まるかもしれません。良い例は素晴らしいもので、目標や参考になるものを与えてくれます。これに直接関連する書籍は非常に参考になります。

@アダム・ヘイル:驚きのレビュー。

何というか、あなたは私がまったく準備ができていないものを生み出しました。不安な気持ちもありますが、頑張ります。私は今、このことがまた起こるのではないかと怖くなって少し不安になります、ありがとう。ただし、この脅し戦略は効果があったかもしれませんが、代償は伴います。ただし、他に何も機能しない場合は、これが必要なプッシュになる可能性があります。

@リトミス:項目は、テストケースがある場合にのみ完了したとみなされます。

ああ、興味深いですね。これは本当に今やらなければいけないことがわかりました。そうしないと何も完了しません。意味あり。

@ジモリス:取り除く/犠牲にする。

ギラギラ、ギラギラ、ギラギラ - 私には学ぶチャンスがあり、サポートと支援があれば、チームの非常に重要で機能的な一員になれるでしょう。これは今の私のハンディキャップの 1 つですが、長くは続かないでしょう。ただ、どうしても腑に落ちない場合は、行くことになるのは理解しています。もらえると思います。

結局のところ、私のチームのサポートがこれらすべてに大きな役割を果たしています。時間をかけて手伝ってくれる人がいて、私に良い習慣を身につけさせてくれるのはいつでも大歓迎です。そして、その後のサポートネットが充実していれば最高です。その後、誰かに何度か来てもらい、コードを調べてもらい、すべてがどのように流れているかを確認してもらうと、レビューそのものではなく、フレンドリーな訪問として常に歓迎されます。

推論、準備、指導、フォローアップ、サポート。

多くのプログラマーが合理的なレベルでテストの価値を認識していることに気づきました。「はい、これをテストする必要があることはわかっていますが、本当に早く終わらせる必要があります。」のようなことを聞いたことがあるなら、私が何を言いたいのかわかるでしょう。ただし、感情的なレベルでは、実際のコードを書いているときにのみ何かを達成できると感じています。

したがって、目標は、テストが実際にはのみ何かが「完了」したことを測定する方法であり、テストを書くという内発的動機を与えます。

しかし、それは本来よりもはるかに難しいことだと思います。「本当に急いでいるから、後でこれを書き直したりリファクタリングしてからテストを追加する」といった言い訳をよく聞くでしょう。そしてもちろん、その後のフォローアップは決して行われません。ですよ 来週も同じように忙しい.

私ならこうします:

初めての外出…「私たちはこのプロジェクトを共同で行うつもりです。私がテストを書き、あなたはコードを書きます。私のテストの書き方に注目してください、それが私たちがここで物事を行う方法であり、それが私があなたに期待していることだからです。」
以下のこと...「終わったんですか？素晴らしい！まず、開発を推進するテストを見てみましょう。ああ、テストはありませんか？それが完了したらお知らせください。コードを確認する予定を変更します。テストを作成するのに助けが必要な場合は、私に知らせてください。お手伝いします。」

私はジュニアプログラマーとして、テストを書く習慣を身に付けようと努めています。新しい習慣を身につけるのは明らかに簡単ではありませんが、これが自分にとってうまくいくことを考えると、コードレビューとコーチング/ペアプログラミングに関するコメントに +1 を付ける必要があります。

テストの長期的な目的を強調することも価値があるかもしれません。昨日機能したものが今日、来週、来月も機能していることを確認します。私がそう言ったのは、回答をざっと読んだときにそのような言及が見られなかったからです。

コードレビューを行うときは（そうすることに決めた場合）、若い開発者に、これは自分を貶めることではなく、重要なことであることを理解してもらうようにしてください。 コードを改善します。 そうすることで彼の自信が傷つく可能性が低くなるからです。そしてそれは重要です。その一方で、自分がどれだけ知っているかを知っていることも同様です。

もちろん、実際には何も知りません。しかし、この言葉がお役に立てば幸いです。

編集：[ジャスティン・スタンダード]

自分を卑下しないでください。あなたの言っていることはほぼ正しいです。

コードレビューについてのあなたの指摘:その過程で若手開発者が学ぶだけでなく、レビュー担当者も学ぶことがわかります。コードレビューを共同プロセスにすると、コードレビューに参加する全員が学習します。

率直に言って、入れなければならない場合は、それ彼に何かをやらせるために多大な努力を払ったとしても、彼はチームに合わないかもしれない、辞めなければならないかもしれないという考えを受け入れなければならないかもしれない。これは必ずしも彼を解雇することを意味するわけではありません...それは、彼のスキルがより適している社内の別の場所を見つけることを意味するかもしれません。しかし、他に場所がない場合は...どうすればよいかわかります。

彼もかなりの新入社員（1年未満）で、おそらく最近学校を卒業したばかりだと思います...その場合、彼は企業環境で物事がどのように機能するかに慣れていない可能性があります。このようなことは、ほとんどの人が大学で済ますことができます。

この場合、私が見つけたことの1つは、ある種の「サプライズニューレンタルレビュー」を持っていることです。あなたが前にそれをやったことがないかどうかは関係ありません...彼はそれを知りません。彼を座らせて、彼のパフォーマンスを調べて実際の数字を見せるつもりだと伝えてください...通常のレビューシートを用意して（正式なレビュープロセスがありますよね？）、必要に応じて見出しを変更して、見た目がよいようにします役人を立てて彼に自分の立場を示してください。単にそれについて「小言」を言うのではなく、非常にフォーマルな場で、テストを行わないことが彼の業績評価に悪影響を及ぼしていることを彼に示せば、おそらく彼はその点を理解してくれるでしょう。給与面であろうとなかろうと、彼の行動が実際に彼に影響を与えることを彼に示さなければなりません。

もちろん、これは公式ではないので避けた方がよいかもしれません...しかし、そうするのは当然のことだと思いますし、おそらく彼を解雇して新しい人を雇うよりもずっと安く済むでしょう。

彼はすでにこれを行っています。本当に。彼はそれを書き留めないだけです。納得できませんか？彼が標準的な開発サイクルを経る様子を見てください。

コードを書く
コンパイルしてください
実行して何をするか確認してください
次のコードを書きます

ステップ #3 はテストです。彼はすでにテストを行っており、手動でテストを行っているだけです。彼に次の質問をしてください。「今日のコードがまだ機能していることを明日どうやって知っていますか？」彼は答えます：「コードの量はとても少ないです！」

聞く：「来週はどうですか？」

彼が答えを持っていないときは、次のように尋ねてください。「昨日まで機能していたものが変更によって壊れたとき、プログラムにどのように通知したいですか?」

それが自動単体テストの目的です。

私自身もジュニアプログラマーとして、あなたのジュニア開発者と同じような状況に陥ったとき、それがどのようなものであったかを明らかにしたいと思いました。

私が大学を出たばかりのとき、大学のせいで現実の世界に対処する能力が著しく欠けていることに気づきました。はい、JAVA の基本と哲学はいくつか知っていましたが (聞かないでください)、それだけでした。初めて仕事に就いたときは、控えめに言っても少し大変でした。言っておきますが、私はおそらく周りで最も大きなカウボーイの一人で、コメント/テスト/ドキュメントなしで小さなバグ修正/アルゴリズムをハックして、それを出荷していました。

私は幸運なことに、ある種の監督の下に置くことができ、 とても 患者のシニアプログラマー。私にとって幸運なことに、彼は私と一緒に座って、1〜2週間かけて私の非常にハッキングされたコードを徹底的に検討することに決めました。彼は私のどこが間違っていたのか、c とポインタの細かい点を説明してくれました (それは私を混乱させました!)。私たちは約 1 週間でかなりまともなクラス/モジュールを書くことができました。私に言えるのは、もし先輩開発者が私を正しい道に沿って支援するために時間を投資してくれなかったら、私はおそらく長くは続かなかっただろうということだけです。

幸いなことに、2 年後には、同僚の何人かが私を平均的なプログラマーだとさえ思ってくれることを願っています。

ポイントを持ち帰る

ほとんどの大学は学生を現実世界に向けて準備させることが非常に苦手です
ペアプログラミングは本当に役に立ちました。それがすべての人を助けるというわけではありませんが、私にとってはうまくいきました。

それが心配な場合は、「最高品質の安定したコード」を必要としないプロジェクトにそれらを割り当て、ジュニアに任せてください。開発者の失敗。彼らにバグを修正するために「週末に来て」もらいます。ランチをたくさんとり、ソフトウェア開発の実践について話します (講義ではなくディスカッションです)。やがて、彼らは割り当てられたタスクを実行するためのベストプラクティスを習得し、発展させるでしょう。

あなたのチームが現在使用しているテクニックよりも優れたものを思いつくかもしれません。

若手プログラマーであろうと誰であろうと、テストに価値を感じていない場合、彼らにテストをさせるのは難しいでしょう...期間。

私だったら、若手プログラマーに週末を犠牲にしてバグを修正させていたでしょう。彼の行動（または行動の欠如）は彼に直接影響を与えません。また、テストのスキルを向上させなければ、昇進や昇給は見込めないことを明確にしてください。

結局のところ、あなたがあらゆる援助、励まし、指導を行ったとしても、その人はあなたのチームに適さないかもしれないので、彼を解放して、理解できる人を探しましょう。

すべてのコミットのコードレビューについての RodeoClown のコメントを二番目に引用します。何度かやると、何かをテストする習慣が身につくでしょう。

ただし、そのようなコミットをブロックする必要があるかどうかはわかりません。私の職場では、誰もがすべてに対して無料でコミットでき、すべての SVN コミットメッセージ (差分付き) がチームに電子メールで送信されます。

注記：あなた 本当に が欲しいサンダーバードの色差分アドオンこれを行う予定がある場合。

私の上司か私 (2 人の「上級」プログラマー) が最終的にコミットを読むことになり、「単体テストを追加するのを忘れた」などの内容があれば、メールをフリックするか、その人にチャットで理由を説明するだけです。単体テストなどが必要でした。何が起こっているかを確認するのに最適な方法なので、他の人にもコミットを読むことをお勧めしますが、若手開発者はあまりコメントしません。

定期的に次のようなことを言うと、人々にこの習慣を身につけるよう促すことができます。「ねえ、ボブ、今朝私がやったコミットを見ましたか、私は、なんとか何でもできるこの巧妙なトリックを見つけました、コミットを読んで確認してください」使い方！"

注意:私たちには 2 人の「上級」開発者と 3 人の「ジュニア」開発者がいます。これは拡張できない可能性があります。あるいは、開発者を増やしてプロセスを少し調整する必要があるかもしれません。

コードカバレッジをレビューの一部にします。
「バグを明らかにするテストを書く」ことをバグ修正の前提条件にします。
コードをチェックインするには、事前に一定レベルのカバレッジが必要です。
テスト駆動開発に関する優れた本を見つけて、それを使用して、テストファーストがどのように開発をスピードアップできるかを示します。

心理学や役立つ「メンタリング」テクニックはたくさんありますが、正直に言うと、これは要するに「仕事を続けたいなら、明日もテストを書こう」ということになります。

適切だと思うどんな言葉でも、厳しい言葉でも柔らかい言葉でも、それは問題ではありません。しかし実際には、プログラマーは単にコードをまとめてチェックインするだけで給料をもらっているわけではありません。彼らは慎重にコードをまとめ、次にテストをまとめ、コードをテストして、全体をチェックインすることで給料をもらっています。（少なくともあなたの説明からはそう聞こえます。）

したがって、もし誰かが自分の仕事を拒否するつもりなら、明日は家にいてもいい、そうすればその仕事をしてくれる人を雇うでしょう、と説明してください。

繰り返しになりますが、必要だと思われる場合は、これらすべてを優しく行うことができますが、多くの人は、単に強く強く平手打ちする必要があります。 現実世界の生活, 、そしてそれを彼らに与えることで、あなたは彼らに好意を持っていることになります。

幸運を。

しばらくの間、彼の仕事内容をテストの作成とテストの保守のみに変更します。新人未経験者に対して入社当初はしばらくこのようなことを行う企業が多いと聞きます。

さらに、彼がその役割を担っている間にチャレンジを発行します。a) 現在のコードで失敗する、a) ソフトウェアの要件を満たすテストを作成します。これにより、彼がしっかりとした徹底的なテストを作成し (プロジェクトを改善し)、コア開発に再統合するときのテストを書くのが上手になることを願っています。

edit> ソフトウェアの要件を満たしているということは、コードがそのテストケースを考慮することを意図していない、または考慮する必要がないときに、意図的にコードを壊すためのテストを書いているだけではないことを意味します。

同僚にテスト作成の経験が不足している場合は、単純な状況を超えたテストを行うのが難しく、それが不適切なテストとして現れている可能性があります。私が試してみることは次のとおりです。

時間をかけて、依存関係の注入、エッジケースの検索などのテストテクニックを同僚と共有してください。
テストに関する質問に答えると申し出ます。
しばらくテストのコードレビューを行います。同僚に、良いテストの例となるあなたの変更をレビューしてもらいます。彼らのコメントを見て、彼らが本当にテストコードを読んで理解しているかどうかを確認してください。
チームのテスト哲学に特によく適合する本がある場合は、その人に一冊渡してください。コードレビューのフィードバックやディスカッションがこの本を参照していると、その人が取り上げてフォローできるスレッドが得られるので役立つかもしれません。

私は特に恥や罪悪感の要素を強調するつもりはありません。テストは広く採用されている良い習慣であり、チームメイトが週末を仕事に費やす必要がないように、良いテストを作成して維持するのは職業上の礼儀であることは指摘する価値がありますが、私はそれらの点を詳しく説明しません。

本当に「厳しくする」必要がある場合は、公平なシステムを確立してください。自分が特別に扱われていると感じたくない人はいません。たとえば、チームは、一定レベルのテストカバレッジ (ゲーム化は可能だが、少なくとも自動化は可能) を維持するコードを必要とする場合があります。新しいコードにはテストが必要です。コードレビューを行う際、レビュー担当者にテストの品質を考慮するよう要求する。等々。そのシステムの導入はチームのコンセンサスから得られるべきです。ディスカッションを慎重に進行させれば、同僚のテストが期待どおりではない他の根本的な理由が明らかになる可能性があります。

彼/彼女を教えるのはメンターの責任です。あなたは彼/彼女にテストの方法をどの程度うまく教えていますか。彼とペアプログラミングをしていますか？ジュニアはおそらく、xyz の適切なテストを設定する方法を知りません。

学校を卒業したばかりのジュニアとして、彼は多くの概念を知っています。あるテクニック。いくつかの経験。しかし最終的には、ジュニアは誰でも可能性を秘めています。彼らが取り組んでいるほぼすべての機能には、これまでにやったことのない新しいものが含まれます。確かに、ジュニアはクラスのプロジェクトで「ドア」の開閉などの単純な状態パターンを実行したことはあるかもしれませんが、そのパターンを現実世界に適用したことはありません。

その人は、あなたがどれだけ上手に教えるかによってのみ上達します。もし彼らが「ジャスト・ゲット・イット」できていたら、そもそもジュニアのポジションを獲得していたと思いますか？

私の経験では、後輩は採用され、先輩とほぼ同じ責任を与えられますが、給与が低いだけで、彼らがよろめき始めると無視されます。もし私が苦いように思えたら許してください、それは私がそうしているからです。

@jsmorris

私はかつて、上級開発者と「アーキテクト」から、夜遅くまで残って前夜にこのような「簡単な」タスクを完了したことを理由に、私とテスター（それが大学を出てからの最初の仕事でした）を電子メールで叱責されました。私たちは一日中それに取り組んでいて、午後7時に終了を告げました。私はその日の昼食前の午前11時からのたうち回っていて、少なくとも2回はチームのメンバー全員に助けを求めました。

私はそれに返信し、チームに次のようにCCを送りました。「ここ一ヶ月、あなたには失望していました。チームからの助けは決して得られません。必要であれば、通りの向かいのコーヒーショップに行きます。ほぼすべてが依存している 12 パラメーター、800 行のメソッドをデバッグできなかったのが残念です。」

コーヒーショップで1時間涼んだ後、オフィスに戻り、ゴミを持って出発しました。数日後、彼らから電話があり、入社するかどうか尋ねられたので、入社すると答えましたが、おそらく明日面接を受けることになりました。

「それで、辞めるの？」

ソースリポジトリ上:各コミットの前にフックを使用します (たとえば、SVN のコミット前フック)

そのフックで、メソッドごとに少なくとも 1 つのユースケースが存在するかどうかを確認します。事前コミットフックを介して簡単に強制できる単体テスト構成の規則を使用します。

統合サーバー上ですべてをコンパイルし、テストカバレッジツールを使用してテストカバレッジを定期的に確認します。コードのテストカバレッジが 100% でない場合は、開発者のコミットをブロックします。コードの 100% をカバーするテストケースを送信する必要があります。

自動チェックのみがプロジェクトで適切に拡張できます。すべてを手作業で確認することはできません。

開発者は、テストケースがコードの 100% をカバーしているかどうかを確認する手段を備えている必要があります。そうすれば、彼が 100% テストされたコードをコミットしなかったとしても、それは「おっと、ごめんなさい、忘れていました」という責任ではなく、彼自身の責任になります。

覚えて：人々は決してあなたが期待したことをするわけではなく、常にあなたが検査したことを実行します。

まず、ここのほとんどの回答者が指摘しているように、その男性がテストに価値を感じていない場合、それに対してできることはあまりなく、その男性を解雇できないことはすでに指摘されています。ただし、ここでは失敗は許されないので、いくつかの点についてはどうでしょうか。 できる する？

組織が 6 人を超える開発者を抱えるほど大きい場合は、品質保証部門を設けることを強くお勧めします (たとえ最初は 1 人であっても)。理想的には、テスター 1 人に対して開発者 3 ～ 5 人の割合にする必要があります。プログラマーに関することは...彼らはプログラマーであり、テスターではありません。私はまだ、適切な QA テクニックを正式に教えられたプログラマーにインタビューしたことがありません。

ほとんどの組織は、コードに触れる機会が最も少ない新入社員にテストの役割を割り当てるという致命的な欠陥を犯しています。理想的には、コードの経験がある上級開発者を QA の役割に移すべきです。そして、（できれば）コードの臭いや、発生する可能性のある障害点に対する第六感を発達させています。

さらに、間違いを犯したプログラマは、おそらくその欠陥を見つけることはできません。なぜなら、それは通常、構文エラー (コンパイル時に検出される) ではなく、論理エラーであるためです。コードを書くときと同じようにテストします。コードを開発した人にそのコードをテストさせないでください。他の人よりもバグが少なくなります。

あなたの場合、リダイレクトされる作業の労力に余裕がある場合は、この新しい担当者を QA チームの最初のメンバーにしてください。彼に「現実世界でのソフトウェアテスト:」を読んでもらいます。プロセスの改善」という理由は、新しい役割では明らかにトレーニングが必要だからです。彼が気に入らないなら辞めるだろうし、問題は解決したままだ。

もう少し執念深くないアプローチは、この人に自分の得意なことをやらせて（この人は実際に仕事のプログラミング部分で有能なので採用されたのだと思います）、テストを行うためにテスターを 1 人か 2 人雇うというものです（大学生は実習や「生協」の期間があることが多く、露出を好み、物価も安い）

サイドノート：最終的には、QA チームを QA ディレクターに報告するか、少なくともソフトウェア開発マネージャーに報告しないようにする必要があります。製品を完成させることが主な目標であるマネージャーに QA チームを報告させるのは利益相反だからです。

組織が 6 名未満の場合、または新しいチームを作成することができない場合は、ペアプログラミング (PP) をお勧めします。私はすべてのエクストリームプログラミング手法を完全に取り入れているわけではありませんが、ペアプログラミングを強く信じています。ただし、ペアになったプログラミングチームの両方のメンバーが献身的に取り組む必要があり、そうでないと機能しません。彼らは次の 2 つのルールに従わなければなりません。検査官は画面上で何がコーディングされているかを完全に理解するか、コーダーに説明を求めなければなりません。プログラマは、自分が説明できることしかコーディングできません。「わかりますよ」や「信じてください」、あるいは手を振ることは許されません。

あなたのチームにそれができる場合にのみ PP をお勧めします。なぜなら、テストと同様に、エゴに満ちた内向的な二人が協力することに抵抗がある場合、いくら応援したり脅したりしても、協力するよう説得することはできないからです。ただし、詳細な機能仕様を書くこととコードレビューを行うことの選択と、ペアプログラミングの場合、通常は PP が勝ちます。

PP が向いていない場合は、TDD が最善の策です。ただし、それを文字通りに受け取った場合に限ります。テスト駆動開発とは、最初にテストを作成し、テストを実行して実際に失敗することを証明してから、それを機能させるための最も単純なコードを作成することを意味します。その代償として、何千ものテストのコレクションが必要になる (はずです)。これもコードであり、製品コードと同じくらいバグが含まれる可能性があります。正直に言うと、私は TDD の大ファンではありません。これが主な理由です。しかし、テストケースドキュメントよりもテストスクリプトを作成したいと考える多くの開発者にとっては、TDD は機能します。テストは何もしないよりはあった方が良いのです。TDD と PP を組み合わせると、テストカバレッジの可能性が高まり、スクリプトのバグが減ります。

他のすべてが失敗した場合は、プログラマーに誓いの瓶と同等のことをしてもらいます。プログラマーがビルドを中断するたびに、20 ドル、50 ドル、100 ドル (スタッフにとって適度に痛い金額であれば何でも) をお気に入りの瓶に入れる必要があります (登録されています！）チャリティー。彼らがお金を払うまで、彼らを避けてください:)

冗談はさておき、プログラマにテストを書かせる最善の方法は、プログラマにプログラミングをさせないことです。プログラマーが必要な場合はプログラマーを雇いましょう。テストが必要な場合はテスターを雇ってください。私は 12 年前にジュニアプログラマーとしてテストの仕事を始めましたが、それが私のキャリアパスとなり、何にも代えられませんでした。適切に育成され、ソフトウェアを改善する権限と権限が与えられた堅実な QA 部門は、最初にソフトウェアを作成した開発者と同じくらい価値があります。

これは少し非情かもしれませんが、あなたの状況の説明では、この男を解雇する必要があるように思えます。あるいは、少なくとも次のことを明確にしてください。住宅開発の慣行に従うことを拒否する（筆記テストを含む） そして 他の人がクリーンアップしなければならないバグのあるコードをチェックインすると、最終的にはクビになります。

若手エンジニア/プログラマーがテストスクリプトの設計と実行に多くの時間を費やさない主な理由は、ほとんどの CS 認定資格ではこれがそれほど要求されていないためであり、デザインパターンなどのエンジニアリングの他の分野は大学のプログラムでさらに詳しく説明されています。

私の経験では、若手の専門家に習慣を身につけさせる最善の方法は、それをプロセスの一部として明示的に組み込むことです。つまり、反復にかかる時間を見積もるときは、ケースの設計、作成、および/または実行の時間をこの見積時間に組み込む必要があります。

最後に、テストスクリプトの設計のレビューは設計レビューの一部である必要があり、実際のコードはコードレビューでレビューする必要があります。これにより、プログラマは自分が書いたコードの各行を適切にテストする責任があり、上級エンジニアや同僚は書かれたコードとテストについてフィードバックと指導を提供する責任があります。

「設計がシンプルになることを示している」というコメントから、皆さんは TDD を実践していると思います。事後的にコードレビューを行ってもうまくいきません。TDD の本質は、それが設計であり、テスト哲学ではないということです。彼が設計の一部としてテストを作成しなかった場合、事後的にテストを作成しても、特に若手開発者にとっては大きなメリットは得られません。結局、彼は多くの例外的なケースを見逃すことになり、彼のコードは依然としてひどいものになるでしょう。

最善の策は、 とても シニア開発者が彼と一緒に座って、ペアプログラミングを行うよう患者さんに依頼します。そして彼が学ぶまでそれを続けてください。あるいは学習しない場合は、実際の開発者をイライラさせるだけになるため、彼をより適したタスクに再割り当てする必要があります。

誰もが同じレベルの才能やモチベーションを持っているわけではありません。開発チームは、アジャイルチームであっても、「A チーム」のメンバーと「B チーム」のメンバーで構成されます。A チームのメンバーは、ソリューションを設計し、すべての重要な運用コードを作成し、ビジネスオーナーとコミュニケーションをとるのですが、これらすべての作業には既成概念にとらわれずに考える必要があります。B チームは、構成管理、スクリプトの作成、不十分なバグの修正、メンテナンス作業などを扱います。これらの作業はすべて、失敗の影響が小さい厳格な手順が必要です。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow