Monday morning, 9 a.m. The project group and I are ready to kick-off a new project. A project with many components and quite a bit of variety. Exactly what gives me energy!
Ikea cabinet!
The requirements have already been collected by our business analysts and the user interface is ready to be created. A project like this feels like assembling an IKEA cabinet with the Allen key and screws already ready. All you have to do is assemble it.
First week
The first week goes smoothly. Everyone grabs a user story on. We work in 2-week sprints, after which we deliver part to be tested by our tester. This is also the case after the second week. Although the delivery is only a bit boiler plating with not too many complex user interactions, quite a bit of what we've created is already visible.
We'll shift the stories that have been sent to the 'completed' status in Azure DevOps and move on to the next sprint.
These features were finished, right?
But then... Halfway through sprint 2, our tester comes up with findings. And a nice list too! Some input fields are not validated correctly. You can even enter text in date fields. We did not immediately take this into account. After all, it was the first sprint and we mainly wanted to make progress quickly and look at any details later.
More work in the sprints
The findings provide 3 additional items on product backlog on DevOps... And that while we were already busy with the following items. The next sprint delivery is no different. This time, 5 extra items are added, while we were able to tick away 3. So more work... This time, our tester also tested a part of the system that was not 100% finished yet. We, as developers, were aware of this. But the transfer was apparently too brief so that the tester didn't know.
Time for a good conversation. I tell our tester that we are not making meters fast enough this way. The DevOps board is full of important things that we want to address quickly. Of course, he also understands that, but for him, the preconditions for some tasks are simply not well defined.
The test server down? How then?
Another day and everyone is back to work hard. Also our tester. When I close my laptop around 5 o'clock, I get a message from him. The test environment is broken, and the system is unreachable...
Sigh...
This hasn't happened to me once in this project. So how does he manage to do it? We really can't waste any more time this sprint, so I open my laptop again and start debugging the system. I quickly find out that our tester found an issue specifically related to the use of Google Chrome. That's why this hadn't happened to me yet!
Halfway through the project: taking stock
Halfway through the project, we see that we are well on our way. We deliver results that work and the customer is more than satisfied with the process. Although for me, it feels like we're only a quarter. Why? Because we completed many more tasks that “got in between” than the agreed items that were initially recorded.
During the retrospective some more pain points are coming up. As developers, we find it annoying when people don't use our created solution in the way we thought. If a tester brings that out and also ruins things even more with their far-fetched tests, we don't like that.
You're going to doubt your own skills. Did I miss something? Am I doing it wrong? Don't I understand how people are going to use the system? The harmony between a developer and a tester consists of mutual acceptance, I get that. But I don't like it.
Optimal cooperation = occasional clashes
Still, I wouldn't want to work on a big project without a tester. After all, I'd rather it break during development iterations than after going live. I take it for granted that we sometimes clash. Where developers have full focus on what to create, testers have a sense of why it needs to be created. This is how the tester keeps the group sharp.
.jpg)
