14

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.

migrated from stackoverflow.com Aug 6 '15 at 21:36

This question came from our site for professional and enthusiast programmers.

  • I found some suggestions which might be helpful - Code Review in Agile Teams – part II (found from a very quick Google search - you may be able to find more). – Dukeling Aug 6 '15 at 21:27
  • 1
    Are your testers working on "released" tasks? Does your team's definition of "released" include the code review and action item resolution? Or is the code review happening outside of your team's definition of done? – Kent A. Aug 6 '15 at 21:50
  • 1
    Does your test team not have an automated regression suite? – Telastyn Aug 7 '15 at 2:04
  • 5
    How do you do “code reviews”? Is this a lengthy formal process where the reviewers have to work through a whole checklist of quality metrics (effort: multiple person-hours)? Or is it just any other team member looking through the code and asking questions if something seems off (effort: 10–30 mins for coder and reviewer)? Why do you do code reviews? To ensure code quality? To catch bugs? To spread knowledge of the system between multiple persons? Does your code review mechanism help fulfil these goals, or is it just bureaucracy no one wants to do? – amon Aug 7 '15 at 7:10
  • I like all the answers, but let me add a point I consider important. You are asking if you are misinterpreting Agile but you don't say which methodology. Are you following Scrum? Most important: do you have a definition of "Done"? I'm asking because I find it very .. strange that you are considering something "delivered" before having finished actually working on it. Sounds like code review is something "extra" you do just because. – Lorenzo Dematté Aug 20 '15 at 6:39
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.

  • 2
    +1 In a daily release Agile methodology, don't re-open tasks. Create a new task to address the issues found and schedule it according to your team's priorities. New tasks = new QA action (which likely means running the same tests again). If QA doesn't like it, there are lots of other careers. – Kent A. Aug 6 '15 at 21:53
  • That clearly works but it seems inefficient. – usr Aug 13 '15 at 21:17
7

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.

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.

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.