QA from the perspective of a Backend dev

Testing can be hard. That’s why some developers are more than happy to pass it over to QA engineers, which leads to higher workloads on their side and creates a lot of stress. But it doesn’t have to be that way.

In this talk, I will share simple changes we’ve made in my team to improve cooperation and leverage the different skills we have, leading to better results and less stress on both sides.

Firstly, testing should not start only after a feature has been developed. Having possible test scenarios as part of the original story helps tremendously to avoid miscommunication in the first place.

Secondly, the tester does not have to test all the cases manually. This is a lot of work and can be quite frustrating. Same goes for test data – creating it manually can be extremely time-consuming while it can be just a little task for a developer to do. Instead of doing it on your own, have a conversation with the developers about what has been covered already by unit tests and request to see an early diff of the Pull Request so you can check what is already there and e.g. request some missing edge cases to be covered.

Moreover, as a developer, I want to write high-quality code. Applying my skills to make my code more contained, isolated and testable leads to better-designed code in general. This also leads to a mindset which puts testability first and can change the culture of the whole engineering team on how testability and testing in general are perceived.

In this talk, I will explore simple measures you can take to improve the process of testing between testers and developers, also talking about culture and mindset.