アジャイルプロセスでは、2週間のスプリントがあります。タスクは毎日(毎日のビルド)で配信され、テストチームは翌日または同じ日にすぐにテストを完了します。
また、開発コードのレビューもあり、時間がかかるため(1〜2時間)、週に3回(Mon-Weds-Fri)スケジュールされます。開発者が集まり、コードを改善/リファクタリングする方法を提案します。
私たちの問題は、コードレビュー後にアクションアイテムが表示されるまでに、ほとんどのタスクが既にテストされていることです。テスターは、すでにテストに合格したものを再テストしたくありません。彼らは内部の開発者の変更を気にしません。
アジャイルプロセスを誤解していますか?コードレビューは、毎日のリリース/テストサイクルと互換性がありませんか?全員の時間を費やすため、毎日コードレビューを行うことはできません。
テスターが再テストを望まないのは、「コーダーがリファクタリングを望まない」というようなものです。その仕事の一部。プロセスは次のように言い換えることができます:タスクが作成されます。コードが生成されます。コードがテストされます。コードがレビューされます。コードに欠陥があります。これらの欠陥に対処するために新しいタスクが作成されます(たとえば、コードがリファクタリングされます)。これらの新しいタスクには、新しいテストが必要です。
ある時点でコードをレビューする場合は、レビューを早期に行うことはそれほどコストがかかりません。そして、それはあなたが高価なテストプロセスを持っているように思われるので、あなたは二度テストしたくありません。したがって、テストする前にコードを確認する方が安上がりです。テスト後にコードを確認しても、作業が速くなるわけではありません。それは遅くなり、不十分に書かれているがうまくテストされたコードを提供するように誘惑します。時間の経過とともに、このすべてのレビューされていないコードにより、作業は徐々に遅くなります。次に、より効率的な競争相手がより少ないコストでより良い製品を提供し、それがゲームオーバーです。
また、テストを自動化します。手動テストは1970年のことです。
現在QAの前の時間にコードレビューを実施するのが難しい場合は、コードレビューをより軽量にすることを検討してください アジャイルチームでのコードレビュー、パートII @Dukelingが投稿した議論する。
コードレビューと呼ばれる可能性のある最も単純なものでもメリットがあることがわかりました。コードをコミットする(またはDVCSをプッシュする)前に、他の開発者に電話をかけて、変更を説明します。これには5〜10分かかる場合があります。このコードレビューの目標は、「これは他の開発者に意味があるか」です。目標は、設計の実装をひっくり返すことや、それをどのように記述すべきかについてのレビュー担当者の個人的なアイデアに完全に準拠することではありませんでした。それはこれらの利点を与えました:
より深いコードレビューは、問題を見つけるために絶対的に良く機能します。しかし、あなたはそれらを実行し、価値を得るために行動することができなければなりません。常に実行できる軽量プロセスは、延期されたり、単にバックログに物事を追加したりする重量プロセスよりも役立つ場合があります。
それの音から、テストは苦痛な/高価なプロセスであるため、テスターは再テストしたくありません。
開発者とテスターによるテストの自動化は、アジャイルな方法で作業しようとするチームにとって大きなボーナスです。テストをより安く、より簡単に、より再現性の高いものにすることで、より多くのテストを実行できるようになり、何かを変更する抵抗が少なくなります。
開発者のフィードバックに基づいて迅速なリファクタリングを行いましたか?回帰/煙のスイートを実行する大きな赤いボタンを押して、手作業でもう一度やり直して、発生した可能性のある視覚的な問題を確認します。かんたん!
そのような場所にいったん入ると、再テストは面倒なことではありません-それは第二の性質になるでしょう。
この問題の解決策の1つは、ユーザーストーリーが終了したら、別のピアがコードをすばやく確認することです。これにより、コードに基本的なミスや明らかなミスがなくなります。
ただし、これはテストサイクルの前に行う必要があります。次に、すべてのチームで一緒に大きなレビューを行うと、テスト後にコードの変更が少なくなります。