April 28, 2023
Currently, I work on a project where the team follows the approach of testing own code changes between team members. We don’t have a manual tester who could check every task or bug which I introduce to the development environment. This is an interesting approach because developers need to spend time on testing, and we faced many situations where we had to spend a few hours for testing during two-week-long sprints. How does it work, and what are my thoughts about this? Let’s find out!
It was the main thing that I was curious about when I found out that the team has no manual tester. Previously, in other projects, every change I provided was tested by a manual tester. It was a pretty comfortable approach where some edge cases could be found out by the tester and me, as a developer, didn’t have to spend time on it. I could focus on the next tasks in the sprint.
In the current project, the approach drastically changed. I had to take care of most cases of functionality, provide unit and cypress tests and verify my changes after they are merged. It required a more detailed investigation of the problem, more time to provide specific tests for different cases, and spend some time on manual testing in the development environment. The whole approach looks like this:
What surprised me the most was the excellent app quality after using such an approach. Most functionalities that we provided only had a few really small bugs which didn’t break any processes. There were some workarounds that users could do to get rid of such situations and use the system as normal. Such problems were normally resolved in following sprints or if problems looked more annoying we simply provided a hotfix.
What’s most important, the whole development team has excellent app knowledge. While testing someone’s changes, many times we first have to find out the whole process in the system and prepare test data in different views. This gives a really good understanding of the project, application and processes which users normally use. It gives a huge advantage while investigating future functionalities and estimating them. Every team member can take part in discussions about how some features should be developed and what situation we should care about. This is a really great value.
Quick sum-up:
Well, yes, definitely. This approach forces us to estimate some time for testing changes and put on a 20-25% time buffer for sprint capacity. This, of course, causes less time for development which results in a little bit smaller functionalities chunks that we can deliver at the end of the sprint.
What’s more, there is always a problem with testing the frontend by the backend team. Normally most tasks accumulate until someday and then the backend team tests multiple user stories at once. It also often happens on Thursday, the day before the sprint ends. It very often leads to very difficult and long Thursdays and even Fridays with some quick, small fixes. It of course can end positively with good quality sprint goals delivered, but many times developers are simply tired after such days. It’s hard to develop your own, estimated user stories and find time for testing someone’s changes quickly after changes appear in the development environment. All of this requires very good time management and isn’t as easy as it might look.
Finally, developers got in fact two responsibilities: development and testing. True, developers should take responsibility for their own changes, but there are always multiple components, situations, and edge cases that can negatively affect solutions and are very hard to investigate while developing/testing that bugs are inevitable. They simply appear when we got some feedback from users in the production app. In such situations, I think testers got better testing skills and can find more problems that users can face while using the app.
Quick sum-up:
Might be boring, but this approach has advantages and disadvantages, and I can’t clearly say if it’s worth it or not. I think it depends on what expectations the project manager sets. When we don’t have very strict deadlines, it might have really nice value among team members. On the other hand, testing by developers might not be so precise and might take longer than by a manual QA tester. This is why the IT industry is so interesting because it is very complicated in multiple fields of it and requires huge flexibility to match requirements with processes.
Wojeciech Jakubek
.png)
.png)
