I am trying to introduce to my team a more sophisticated branching model than “commit to master and push”.
We are a small team of two analysts, three developers and one tester. At the moment, a developer will commit their changes to master, then build the master branch on our test environment. They will then notify the tester that the changes are available to test.
My proposed workflow is based on this, with GitHub enabling code reviews via pull-requests on merging feature branches. Each feature or bug has its own branch created, on which the work is done. When the developer is finished they request a merge and their code is reviewed and then merged into the dev branch.
My question is this: At what point during the new process is it appropriate to ask the tester to test the functionality? As I see it, the options are:
- The tester tests the functionality after the code has been reviewed and the branch has been merged into
dev- Pro – the review hopefully caught some bugs and saved the tester from rejecting the work
- Con – the team has to wait until someone does the review before the tester can sign it off
- Or, the tester tests the functionality before the code has been reviewed
- Pro – the tester is able to test and sign off the work before the code is reviewed
- Con – if any changes are suggested, the tester will need to re-test the changed code
There is also the question of how the tester would be able to access the feature branch before it is merged. We use TeamCity as a deployment tool, and can specify a branch name to build – but I am concerned that it won’t be clear which feature branch is currently ‘active’ on our test server.
So really this boils down to: when should the tester do their testing, and if it is before the branch has been merged, how should that situation be dealt with?
If you really believe in code reviews, then coding isn’t finished until the review-revise-repeat loop exits. Until then, the code is in a sequence of preliminary forms, not its final form. Your tester could test one or more preliminary versions of the code, but the tests ought to be repeated from the beginning on the final code. Good testing practice certainly would not allow a sign-off on code that still needed to be revised.
With 3 more years of development experience under my belt, I’ll answer my past self with the suggestion that test and code review can happen at the same time, iteratively. Two things will help:
- Automated tests. The work to write them only needs to happen once, as opposed to the work of a manual tester which is required on every iteration. They also guard against regressions long after you’ve moved away from the code (and perhaps the team/company). They’re also much faster to execute than a manual tester can be, so your feedback loop becomes tighter. Don’t just test at a single level – integration tests and unit tests both have a part to play.
- Break down changes into the smallest possible units. Fewer changes mean fewer possibilities to break functionality, and quicker code review turnaround (normally with higher quality review comments as a bonus). If you need to refactor before writing code, write that as a separate change request and get it signed off before adding the new feature – you can be doing this while the refactoring task is under review. Asynchronicity is the key to productivity when there are several people/roles involved in getting a feature into production.
At what point during the new process is it appropriate to ask the tester to test the functionality?
The tester should start the testing process on the first day, in the same branch as the developer. There is plenty of work to be done. They can work with the devs to make sure the code is going to be easy to test (eg: adding ids to web elements, etc). They can start creating test data needed to test the software. They can start to write test plans and automated acceptance tests, so that when the code is ready to test there will already be tests ready and waiting.
Testing needs to happen before the final review, since there’s not much point to reviewing code if it doesn’t work. Tests need to happen after the review to make sure changes that came out of the review are properly tested.
In short, testing should be a continuous process, not just something that gets tacked on to the end.
1