AutomationCareers

What happens when your first coding experience is test automation?

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?

12 thoughts on “What happens when your first coding experience is test automation?

  1. I’m a test automation engineer that really started out in automation. A lot of my work initally was pulled from other existing code and I think also set me up with some bad habits from the get go.

    FWIW, in Specification By Example, it’s mentioned also that automation/test suites should be maintained by experienced engineers, not junior ones. Testing is more often given to junior devs as it’s considered easier, but that’s absolutely not the case. On top of that, being able to appropriately architect and maintain something that requires that level of planning takes experience.

    I’ve been working on side project and improving myself as an engineer, and while I’ve still got a good amount of room to improve, it’s definitely helped.

    Thanks for writing this, great article!

  2. So my question about this article is if good coding practices matter when the automation tool being used in TOSCA Commander, with WebSphere MQ, and REST where the only language is SQL which used to bring back data for TOSCA to validate?

  3. So you are saying “code reviews and good mentorship is so important in software development teams”. The question is how to conduct a mentoring if junior test automation engineer demonstrates zero interest in learning the tools and technologies?

  4. I also started out as a programmer, back in the Stone Age. When I managed test teams, anyone who was interested in doing test automation (this is the bad old days when few programmers would automate tests), I trained. One of my earliest jobs was setting up training programs for both programmers and non-programmers who needed to learn to code, and that experience served me well. I also brought in people to do training – eg. a developer of the test automation framework/library we were using. The results were good. But admittedly this was in the 90s when our web apps were simpler.

    These days, my preference is for a tester and programmer to pair up to do automation. The tester is great at specifying tests and the programmer (hopefully) has the expertise with good design patterns and coding practices to write robust, maintainable code. Even better is when a team does all their test automation along with their production code in a mob that includes testers.

    There are tools that are easier for non-coders to learn to use. However, I think even a non-coding tester should have a basic understanding of not only their product’s architecture, but also good coding patterns, principles and practices. And they can help the non-testers learn testing basics. It helps us work better as a whole team, which I think is the most effective way to work. I get it that not everyone gets to work that way.

  5. I had been a manual tester for 15 years and after that, 2 years ago, I did a lot of learning to code in my own time to get into automation.

    I’m in a role now as the sole tester and have been tasked with writing E2E automated UI regression tests. It’s been hard with a lot of google assistance and asking Devs in work questions but we have a suite that runs stable now. I don’t have constant access to Devs and I’d love to be able to work closer to show them my code. I do have doubts that some of it has been done the right way so I’d like to learn where I could smarten things up a bit.

    My next role I will definitely be looking for an environment where I’m working with other automation testers. Mentoring is such an important part of the learning process.

  6. I did a small course of javascript development for mobile devices (back in 09) and then landed a job in test. Started maintaining a huge monolith of c#-based automation. Tuffed it out for about a year or two and when I thought I had the hang of it and had the right people on the sut, one summer I deleted the whole thing and started from scratch with the same techniques that the devs were using – nodejs, mocha and chai. For the end2end bit I used webdriver.io. Really good experience for me and my colleague. We also got lots of good ideas and help from devs who now understood that we also coded stuff and with “cool javascript”… It also lifter the fact that tests were important and actually useful! The old framework had about 300 e2e tests, took about 7hrs to run and had one fully green run in 2 years. Constant maintenance and headache. New node-app had 12 e2e covering the same stuff, took about 10 min to run and much easier to maintain. Also as stated, same technology stack as the devs used, so they had no problems with jumping into the test code and doing stuff if they got an error. This change in direction was awesome. Short feedback loops meant that the tests actually had value for everyone and the team started taking responsibility not just QA. :)

  7. I think if you’re using any kind of programming language in a professional environment then good coding practices matter. Good coding practices help with maintainability.

  8. I sympathise, and I don’t think you can force anybody to learn something. That said, I think that mandatory code reviews are a good way to enforce a common standard of code quality across the team, even if some team members don’t want to listen. Limiting the reviewers to senior team members is a good way to make sure that good coding practices are being enforced by reviewers.

    I think if you have a repeat offender who refuses to learn how to become better at their job, that may be a management / performance issue ultimately.

Leave a Reply