コードレビューが配信/テストサイクルに遅れている

アジャイルプロセスには2週間のスプリントがあります。タスクは毎日配信され（毎日ビルド）、テストチームは翌日または同じ日にテストを完了します。

Devコードレビューもありますが、これには時間がかかります（1〜2時間）ため、週3回、月曜日から水曜日にスケジュールされます。開発者が集まり、コードを改善/リファクタリングする方法を提案します。

問題は、コードレビュー後にアクションアイテムが登場するまでに、ほとんどのタスクが既にテストされていることです。テスターは、既にテストに合格したものを再テストしたくない。内部の開発者の変更を気にしません。

アジャイルプロセスを誤解していますか？コードレビューは毎日のリリース/テストサイクルと互換性がありませんか？毎日コードレビューを行うことはできません。すべての人の時間がかかるからです。

テスターが再テストしたくないのは、「コーダーはリファクタリングしたくない」と言っているようなものです。仕事の一部。プロセスは次のように言い換えることができます。タスクが作成されます。コードが生成されます。コードがテストされます。コードがレビューされます。コードに欠陥があります。これらの欠陥に対処するために、新しいタスクが作成されます（たとえば、コードがリファクタリングされます）。これらの新しいタスクには、新しいテストが必要です。

ある時点でコードをレビューする場合、レビューを早期に行うのに費用はかかりません。そして、あなたは高価なテストプロセスを持っているようですので、二度テストしたくありません。したがって、テストする前にコードを確認する方が安価です。テスト後にコードをレビューしても、作業は速くなりません。これにより、処理速度が低下し、記述が不十分であるがテストに成功したコードを提供するようになります。時間が経つにつれて、この未確認のコードはすべて、作業をますます遅くします。次に、より効率的な競合他社がより低コストで優れた製品を提供し、ゲームオーバーになります。

また、テストを自動化します。手動テストは1970年です。

現在QAの前にコードレビューを実施するのが難しい場合は、@ Dukelingが投稿したアジャイルチームのコードレビュー、パートIIで説明されているように、コードレビューの軽量化を検討する必要があります。

コードレビューと呼ばれる可能性のある最も単純なことでもメリットがあることがわかりました。コードをコミットする（またはDVCSをプッシュする）前に、他の開発者を呼び出して、変更を確認します。これには5〜10分かかります。このコードレビューの目標は、「これは他の開発者にとって意味がありますか？」です。目標は、設計の実装を急ぐことでも、どのように書かれるべきかについてのレビュアーの個人的な考えに完全に従うことでもありませんでした。次の利点がありました。

• コードの仕組みに関する共有知識の改善
• コードを説明する行為で作者が物事を再考するのに十分だったため、混乱したり潜在的にエラーのあるコードをキャッチした
• 物事の説明が簡単になったため、チームのイディオムとスタイルを徐々に進化させました
• チームからのごくわずかな不平

より深いコードレビューは、問題を見つけるために絶対にうまく機能します。しかし、あなたはそれらを実行し、価値を得るために行動することができなければなりません。常に実行できる軽量プロセスは、延期され続ける、または単にバックログに物事を追加するだけの重量プロセスよりも役立ちます。

この問題の解決策の1つは、ユーザーストーリーが終了したら、別のピアによるコードのクイックレビューを実行することです。これにより、コードに基本的/明らかな間違いがないようにします。

ただし、これはテストサイクルの前に行う必要があります。その後、すべてのチームで大規模なレビューを行うと、テスト後のコードの変更が少なくなります。

それの音から、テストは痛みを伴う/高価なプロセスであるため、テスターは再テストしたくありません。

開発者とテスターに​​よるテストの自動化は、アジャイルな方法で作業しようとするチームにとって大きなボーナスです。テストが安く、簡単で、再現性が高いほど、テストを実行できます-何かを変更することに抵抗が少なくなります。

開発者のフィードバックに基づいて、迅速なリファクタリングを行いましたか？リグレッション/スモークスイートを実行する大きな赤いボタンを押して、一度手動でクイックマニュアルを実行し、発生した可能性のある視覚的な問題を確認します。簡単！

そのような場所にいれば、再テストは面倒なことではありません。