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.

Improve this question
6
  • 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).
    – Bernhard Barker
    Aug 6, 2015 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, 2015 at 21:50
  • 1
    Does your test team not have an automated regression suite?
    – Telastyn
    Aug 7, 2015 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, 2015 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, 2015 at 6:39

5 Answers 5

Reset to default
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.

Improve this answer
0
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.

Improve this answer
2
  • 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, 2015 at 21:53
  • That clearly works but it seems inefficient.
    – usr
    Aug 13, 2015 at 21:17
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.

Improve this answer
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.

Improve this answer
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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