The switch from software development to test automation brings concrete benefits: Clean code, design patterns and software craftsmanship principles flow directly into test automation. Testing software follows the same quality principles as the application to be tested. Those who also master test methodology combine both worlds and thus measurably increase the quality impact.
Key Takeaways
- Test software is real software and must follow the same clean code and design pattern principles as the application it is testing.
- Those starting out with test automation should first learn principles, not tools: mastering a concrete tool is no substitute for understanding what’s going on underneath.
- The combination of software development background and deep testing knowledge is most effectively developed through mutual learning in a team, not through training alone.
- As AI-generated code becomes standard, the need for skilled testing increases because the quality of that code is unknown and someone has to check it.
From developer to test automation engineer: a career path without studying
The path to test automation does not necessarily lead to a degree in computer science. Benjamin Bischoff began by training as an IT specialist for application development because he wanted to get straight into the field. He then worked as a freelance web and Flash developer for six and a half years before Flash development took him into the games industry.
He first came into contact with testing on the job. In a team that built software for globally distributed games teams, he came into contact with QA, test processes, various test techniques and Selenium for the first time. This contact turned into interest, and interest turned into a new role.
The decisive moment was a change of perspective. Writing software was one thing. The fact that this software had to be as error-free as possible and have good usability was another. When Benjamin saw for the first time how browser testing could be automated with Selenium, it was clear to him that he wanted to pursue this direction. Because there was no path in the testing direction at the time, he switched to a Test Automation Engineer role, which he has now held for almost ten years.
Test software is software and follows the same principles
Coming from software development into test automation brings a mindset that treats test code like production code. This is the biggest difference to automation specialists who come from exploratory testing.
Both approaches have their strengths. From exploratory testing comes a great deal of knowledge about test methods and an instinct for where to look to find errors. Benjamin says that he is still developing this instinct after ten years.
In contrast, clean code principles, design patterns and software craftsmanship come from development. The core attitude behind this: Testing software is also software and must follow the same principles as the application under test. This includes testing code that can be tested, extended and maintained for years.
Whether spaghetti code is a problem in automation depends on its lifespan. Code that is quickly tested and then thrown away does not need high standards. An internal testing framework that remains the tool of choice for years does. Precisely because it follows the principles, is tested and extensible, it lasts so long.
Why testing and development knowledge are mutually reinforcing
The combination of development knowledge and test methodology is most effective when both sides learn from each other. In practice, this works through direct collaboration.
Benjamin describes a colleague who came from deep QA and took on the test automation role. The colleague learned the technical side quickly, Benjamin learned from him about test methods. Both pull each other up.
For Benjamin, this is the ideal role. He does something that makes the software better in all respects, while retaining the full potential to develop and code. That was precisely the reason why he went into testing in the first place.
Why Selenium remains the tool of choice despite new tools
Benjamin continues to rely on Selenium for browser testing because deep tool knowledge is worth more than the latest tool. If you know the code and how a tool works internally, you can judge what it can and cannot do.
Playwright and Cypress are in view, but Selenium remains the tool of choice. Benjamin mentions two specific limitations with Playwright: it does not map the real browsers used, but the engines, and Selenium is still better when testing on real mobile devices. At the same time, he recognizes that Playwright has a large community and is a good tool that a lot of work goes into.
One point is often overlooked in the comparison. Selenium is not just a browser control tool. Part of the Selenium group defines standards, such as the W3C standards for bidirectional communication with browsers. With BiDi, Playwright also uses a principle that originates from the Selenium world.
This leads to a simple classification: an older tool is not automatically a bad tool. Selenium continues to develop and adapt.
How to acquire testing knowledge when you come from development
The most effective way is through people, not material. Colleagues and mentors with extensive testing experience had the greatest influence on Benjamin’s learning path.
In concrete terms, this means looking over the shoulders of experienced people: How do they find the causes of defects? What tools do they use? What thought processes do they follow? Some colleagues know the product features so well that they can assign a defect to a specific feature combination before they look it up.
Blogs and conferences complement this. Benjamin deliberately doesn’t just look at technical presentations there, but also experience reports and articles on exploratory testing, because he wants to grow in this field.
AI in everyday testing: used daily, with clear limits
AI tools have arrived in everyday working life, but they do not replace work. Benjamin uses them every day, and the management is also behind them, but not as an end in itself, but to learn what the tools can do and where they can help.
Among others, Copilot, Claude, Cursor, Juni and Code Rabbit are in use and being evaluated for reviews. An internal tool provides access to around twenty different LLMs to try out. With daily use, the limits and risks also become apparent on a daily basis.
Benjamin believes that the promises made by some testing tools are exaggerated. He has seen statements such as “this solves everything” or “we can do away with our QA team”. When evaluating, however, it becomes clear that they are only boiling water. It sells well at the moment, but often doesn’t stand up to practice.
I vacillate between great fear of the future and hope that it will really work. For me, that actually changes every hour.
- Benjamin Bischoff
When AI writes most of the code, testing becomes more important
The more code is generated by AI, the greater the role of testing will become. This is Benjamin’s central prediction for the future of the role.
He thinks little of pure vibe coding, apart from prototypes. He takes a critical view of the expectation that you just describe a piece of software and get it back one hundred percent functional. If that were to happen, he says he would have to look for another career.
Another scenario is more likely, and it is not a pleasant one. There will be a lot of software whose quality is unknown. In addition, the same software will be copied many times, even by people without programming skills who want to sell the result. This can lead to a great deal of chaos if no countermeasures are taken. Someone has to look at this code, and that clearly shifts the emphasis towards testing.
First principles, then tools: an introduction to test automation
If you are coming from testing and want to get into automation, you should not start with a tool, but with principles. Clean code and design patterns are a better starting point than the question of which framework is currently in vogue.
The pragmatic first step is small: put an activity that you do two or three times a day into a short script. Whether Bash or Python is of secondary importance. If three lines of code save you repetitive work, you’re in the ballpark.
The common mistake is to go the other way around. If you only learn Playwright because everyone uses it, you learn how to use the tool, but not what happens underneath. Understanding this is more important.
This is where a background in testing helps. As a tester or QA engineer, you are already part of the software development lifecycle and have basic knowledge. It’s about going deeper at the right point.
One last point makes it easier to get started. If you can program, you are not tied to one language because the concepts are portable. Benjamin now works with Python without having done it before. He knows the concepts, but he has to learn the syntax and commands. It’s like learning a new language when you already speak a related one.
