We all read in books how great is to have our product with lots of unit tests, automated tests, integrations test, etc… but we don’t always are lucky enough to work like this, most of my professional experience has been working on quite old projects where very low percentage of the code was covered by tests, if any.
The consequence of this, is that if you have a team where you have developers and testers, probably the developers capacity of doing software is much higher than the capacity of the testers to test, I’m pretty sure this is not new for you, but let me show you an image I made.
Development + Code Review
As you can see, we have several developers working on their tasks, a great collaboration by doing each other code reviews.
Once the tasks are code reviewed then tasks are ready to go to the testing phase where the tester will verify that each task works as expected.
Manual testing, task acceptance
As I said, there is a tester that will have a list of tasks pending to be tested, and the tester will verify if tasks are working as expected or not, and if they don’t, tasks will go back to developers where the original developer will fix the issue found by the tester.
Change the behavior and mindset
You have probably realized that this is not the best way of working as a team, the fact of not having any coverage in the system makes the tester to have to test all manually, and because the capacity of doing software is not the same as testing software, the tester will never have time to create the needed infrastructure to start getting rid of all the manual work.
I won’t be extending myself here talking about cross-functional teams and the benefits of them, but teammates should help each other when needed, they should hold accountable each other and by their own, they should try to fix this team behaviors by caring more about the system as a whole.
Last but not least, if you work in Sprints, what’s gonna happen is that probably, the first days of the Sprint the tester will not have anything to test, or maybe yes… tasks from previous Sprints, and tasks from current Sprint will start pilling up pending to be tested, causing stress.
Start promoting testers and developers collaboration by a more effective code review process
What I’m going to show you is a code review process that will help to start making developers and testers to collaborate more, will make the developers to be more involved in the testing phase and will give time to testers to focus on what really matters for a tester, create an infrastructure around the project to start automating all needed tests to avoid manual work.
Don’t think this is the best process, of course not, and you shouldn’t work like this for a long time, this is just the first step to create more collaboration and create awareness among the team.
Let’s go step b step…
Step 1
Let’s say a developer finish the coding part, so will create a pull request, that pull request will have to be assigned to two people:
- Option 1 is that gets assigned randomly to 2 developers of the team.
- Option 2 is that you decide to whom you want to assign the pull request.
Step 2
As I said, the pull request will be assigned to 2 developers, which means that they will get a notification about a new code review needed, we also have some options we can take to notify pending code reviews.
- Gets notified by e-mail.
- You might want to consider to integrate an add-on in your IDE, like integrating something in IntelliJ IDEA.
- You just tell face to face, maybe the Daily Scrum can be a good moment to remind that you need those code reviews done in order to achieve the Sprint Goal.
- If you have an internal chat like Slack, you maybe can also integrate a bot there, or you could just write them through slack.
- These are just some options that came to my mind, of course, you can be as creative as you want.
Step 3
Here is where interesting stuff starts happening, each developer with the pull request assigned will have some To Do’s, a different To Do’s
- Developer 1 To Do’s
- Pull changes to local computer
- Check Code
- Developer 2 To Do’s
- Pull changes to local computer
- Start checking if the Acceptance Criteria is satisfied
- Verify that everything is working as expected(Dev Testing)
- Check things like database performance, security, potential bugs, etc…
- Check Code
Developer 1 has fewer things to worry about, his or her focus will be mainly on the code and architectural part.
Why the developer 1 is who has “less” work to do? very simple, because this will motivate the developers to go and be the first ones, and leave the more elaborated “code review” to the developer 2.
Maybe you are wondering why some of the To Do’s of the second developers are in bold, and it’s because these are things that a tester really knows how to check, in Agile we don’t refer to the tester by the someone who checks that everythings is working, this is part of the developers responsability, the tester should focus on other things like the ones mentioned, for example having systems to make sure that the performance of the product is not affected, or data base performance, or think ahead preventing bugs comming, improving the automation testing pipeline, making them faster and better, making sure we are really stafistying the business needs and many many others, finding bugs shouldn’t be a key part of his or her responsabilities.
We are not born with the lessons learned, and this is why we will not call it Quality Assurance, we will call it Quality Assistance
Check the following image.
We will create a more collaboration between developers and testers by making sure the testers coach and mentor the developers in knowing how to test tasks, I often listen the following statement:
- “Developers thing different, they should not test, testers should be the ones testing the tasks” -> I don’t like this statement at all, of course, everyone can check if stuff works as expected, and if testers are the ones who know really how to do that, they should coach, mentor and train the whole team in becoming better at it. Actually, a way to check if a tester is performing well is by checking the ability of the others around in becoming better on assuring the quality of something, because quality is not just that the tasks do what is said in the ticket, as I said before there are many aspects to take into consideration.
This is why the tester will assist the second developer doing the code reviews with tips and good processes about how to assure the quality of something.
Testers will focus on what matters
One of the best things will be that the tester will have more time to focus on what matters, which is start automating the product in order to start reducing the manual work.
Step 4
After both developers have approved the pull request, the task will go automatically to the “Waiting to be tested queue”, by the way, I did not mention this before, but I have data that proves that this process helps to reduce the bottleneck in that queue and that it doesn’t hurt the quality of the product.
Step 5, the last one
Every morning, one of the developers and the tester will meet and will decide which tasks are not critical to be really tested by the testers, and which ones can already be merged and have the quality stand on it, because the testers will be trusting more how the developers assured the quality of the tasks, basically because testers are the one training them!
This will help to reduce the bottleneck, not all tasks have the same complexity and risk, some of them doesn’t really need to go through the testers, will be tester’s job as well to make sure they train properly the developers, because at the end, the tester will be who holds accountable, if something happens the tester will be probably the one who gets into trouble.
Conclusion
We have to go step by step, if we see that something is not working as expected, or a team is not behaving as expected, we can not just change everything, we need to go step by step, and I hope this code review process will start helping the team by creating a more collaboration between developers and testers, giving more time to testers to focus on what really matters, and creating a “team” mindset where we all hold accountable during the whole process.
