How do you guys ask development to rush on reviews of PRs in Review, so it doesn’t affect testing? Any funny examples are welcome.
3 Likes
Volunteer to do the review, I know just enough to be dangerous at that.
Its worth looking at the history of the review step, its an important step but unless its throwing up major things on a daily basis I’ll often test whilst its still pending the review.
Any bottle necks at all are always good for process improvement opportunities.
3 Likes
Do I understand it right that your developers prefer to take new tasks instead of reviewing PRs?
You are not very explicit about your situation. I guess you have a test system where you want the changes to be deployed?
Make it clear to the team, especial to the management, that delayed testing because of delayed reviews is a risk for the project and product.
Reviewing should have priority before picking new work.
You work on the tasks as team. No matter what your official structure says.
5 Likes
Thank you Sebastian. That’s is exactly what is happening. And often QA ends up waiting for the work to be reviewed and moved to Ready for Testing board.
I was just looking for clever, witty ways to make them prioritize reviews and speed up the move tickets to RFT.
3 Likes
How about a carrot and stick system? Every 10 code reviews they do, they get a free chocolate bar/rubber duck/whatever devs are into.
Or maybe every hour there’s a PR waiting for them to review, a random key is remapped on their keyboard, making it harder and harder for them to ignore it…
2 Likes
I work instead the other way, and start testing the branch that is under PR review and then I can give feedback before the code is even merged. This can work great when pairing with the developers themselves.
4 Likes
Ahhh OK that makes sense, and it is a problem. Depending on your relationship with the team, I would raise it with the team, maybe at retrospective, to prioritise review before taking new tasks.
One thing I’ve seen worked well for teams I’ve been in before, is a habit to check PR’s in the morning before starting any of your own tasks.
Also, another option is to start scheduling sessions for review, share the screen and walkthrough together with a Dev or two.
3 Likes
Another approach could be to change the system so that before work starts on a card the tester and developer discuss how the card will be tested. If this is done then the developer will can not start on a new card without the tester. This system also has the advantage of the tester and developer collaborating to find issues before work starts.
3 Likes
I’ve always loved this idea, and I’ve managed it once or twice, but I’ve failed to make it a lasting habit and still suffer from developers who just start anyway.
1 Like
At one place I worked it was included in the Defnition of Done and it was great!
2 Likes
Basically I would just ask friendly-bluntly.
Depending on your relation to the developer you can do it in a funny-ironic way.
Like the others say, this is finally a team/project issue with which not only you should have to bother.
2 Likes
Great idea! I might bring this up in retro. Thanks
1 Like
Good luck, I’d be really interested to hear more about how it works out!
1 Like
This sounds like a team culture issue. If you’re doing something like scrum and sprints, one of the premises is that a sprint is the entire team working towards a common goal. In my scrum team, we try to identify who’s going to be the inspectors for each development item in a sprint as part of our sprint planning, before the sprint even starts. And if an item is running behind, we talk during the sprint about how we can accelerate/streamline the work (without rushing or cutting corners), whether it’s pairing, doing some of the testing in parallel on the feature/side branch as someone else mentioned, etc. We also harp on “starting the sprint as a team and ending the sprint as a team”, meaning everyone prioritizes helping with other sprint work before picking up work from the product backlog.
Of course, if you’re not doing scrum or using sprints this doesn’t help much. But if you are at least nominally, framing the problem you’re seeing using the language of scrum could be helpful.