Training testers at different skill levels has led me to reflect on different skill backgrounds and how they affect test automation approach. I believe that my background in software development shaped my approach to test automation in very different ways to testers who learned test automation as their first experience with programming.
I completed a computer science degree and my first job was as a software developer. So when I moved into test automation I had a solid background behind me of coding principles which shaped my expectations for the test automation code. It also shaped my expectations for the code in the system under test, and gave me a clear understanding of how easy it is to modify the system to cater for test automation needs.
Contrast this with a person who has started their career as a tester with no programming experience. This person’s first experience working with code may be a test automation codebase – a suite of end-to-end tests driving tests through the UI against a complete system under test. This person has been given this task because they are a tester. This person has no idea that they have been saddled with one of the hardest problems in software development – creating 100% reliable full-stack end-to-end tests.
Full-stack end-to-end tests are notoriously brittle because they are subject to so many uncontrolled variables, such as the enormous, ever-changing system under test which it is required to repeatedly and consistently assess. And yet, these tests are often the first professional programming experience testers are given. The codebases are often plagued with coding practices that would be unacceptable in the feature developer team’s codebase but they are allowed because they are “just tests”.
I imagine this shapes the testers’ experience in two crucial ways:
- Codebases full of bad coding practices are presented as acceptable in a professional working environment.
- Coding seems really hard because it’s so difficult to get these types of tests to ever work properly.
With regards to the coding practices, this is an issue that affects any development team – the standard of code will be determined by the coding culture of the team. This is why code reviews and good mentorship is so important in software development teams – both of these together will circulate good practices throughout a team. Without both code reviews and good code mentorship in the team, the codebase will be poorly coded and maintained and the developers may not be aware that it could be better.
With regards to the second point, I think this is why it’s crucial for testers to complement their test automation learning with a side project such as creating a simple app. This will not only teach the testers so much about how the system under test works, but it will demonstrate how simple it can be to make working software. It will also give them something crucial in programming – the feeling of joy in seeing something that you made all by yourself, working as intended. Finally, it may bolster the testers’ confidence in their programming ability and help them to apply their programming skills beyond automating end-to-end tests.
I’d love to hear from other testers about your experiences in learning test automation and programming. Does any of this resonate? What were your biggest challenges?