15

In our Agile process we have 2-week Sprints. Tasks are delivered on a daily basis (daily builds), and the Test Team completes their testing immediately the next day or even the same day.

We also have Dev code reviews, which require some time (1-2 hrs), so they are scheduled 3 times a week: Mon-Weds-Fri. Developers get together and suggest how to improve/refactor code.

Our problem is, by the time Action Items come up after a code review, most of the tasks have already been tested. Testers don't want to re-test what already passed their tests. They don't care about internal dev changes.

Are we misunderstanding the Agile process? Are code reviews incompatible with a daily Release/Test cycle? We can't hold code reviews every day, as they take up everyone's time.

gnat
  • 20,543
  • 29
  • 115
  • 306
gene b.
  • 315

5 Answers5

9

If you are going to review the code at some point, it's no more expensive to do the review early. And it seems you have an expensive testing process, so you don't want to test twice. Therefore it is cheaper to review the code before testing. Reviewing the code after testing doesn't make the work go faster. It makes it go slower and tempts you to deliver poorly written but successfully tested code. Over time all this un-reviewed code will make the work go slower and slower. Then a more efficient competitor delivers a better product at less cost and it's game over.

Also, automate the testing. Manual testing is so 1970.

kevin cline
  • 33,798
8

Testers don't want to re-test is kind of like saying "coders don't want to refactor." Its part of the job. The process can be restated as something like this: Tasks are created. Code is generated. Code is tested. Code is reviewed. Imperfections are found in the code. New Tasks are created to address these imperfections (e.g. the code is refactored). These new tasks require new testing.

John
  • 181
5

If you are finding it hard to get code reviews to happen in the time you currently have before QA, you should consider making code reviews more lightweight, as Code Review in Agile Teams, Part II that @Dukeling posted discusses.

I found that even the simplest thing that could possibly be called a code review gave benefits: before committing code (or pushing in a DVCS), call one other developer over and walk them through your change. This might take five or ten minutes. The goal of this code review is "Does this make sense to the other developer?" The goal was not to nitpick on design implementations or to conform completely to the reviewer's personal ideas about how it should have been written. It gave these benefits:

  • Improved shared knowledge of how the code worked
  • Caught confusing or potentially erroneous code because the act of explaining the code was enough to make the author rethink things
  • Helped gradually evolve team idioms and style, because it made it easier to explain things
  • Very little grumbling from the team

Deeper code reviews absolutely work better to find problems. But you have to be able to do them and act on them to get the value. A lightweight process that you can do all the time can be more helpful than a heavyweight process that keeps getting put off, or merely adds things to the backlog.

Alan Shutko
  • 1,430
1

One solution for this problem is to do do a quick review of the code by another peer once a user story is finished, so that there won't be any basic / obvious mistakes in the code.

But this has to happen before the test cycle. Then there would be less code changes after the test, when you do a larger reviews with all team together.

Low Flying Pelican
  • 1,612
1

From the sounds of it testers don't want to retest because testing is a painful/expensive process.

Test automation both by devs and testers is a huge bonus for teams trying to work in an agile way. The cheaper, easier, and more reproduceable your tests are then the more you can execute them - and the less resistance you'll get to changing something.

Done a quick refactor based on some dev feedback? Press the big red button that executes your regression/smoke suite and do a quick manual once-over to check for any visual problems that might have cropped up. Easy!

Once you're in a place like that, re-testing won't be a chore - it'll be second nature.

f1dave
  • 362