A developer who becomes a test automation engineer brings concrete advantages to the job: clean code, design patterns and software craftsmanship carry straight over into test automation. Test software follows the same quality principles as the application it tests. Add solid test methodology on top, and you combine both worlds and noticeably raise the impact on quality.
Key Takeaways
- Test software is real software and has to follow the same clean code and design pattern principles as the application it tests.
- Anyone getting started with test automation should learn principles before tools: knowing how to operate one tool is no substitute for understanding what happens underneath.
- A development background and deep testing knowledge come together best when people in a team learn from each other, not through training courses alone.
- As AI-generated code becomes the norm, the need for skilled testing grows, because nobody knows the quality of that code and someone has to check it.
From Developer to Test Automation Engineer Without a Degree
You don’t need a computer science degree to become a test automation engineer. Benjamin Bischoff started with a vocational apprenticeship as an IT specialist in application development, because he wanted to get into real work right away. He then spent six and a half years as a freelance web and Flash developer, and Flash eventually took him into the games industry.
Testing only entered the picture on the job. In a team that built software for game studios spread across the world, he first ran into QA, test processes, different test techniques and Selenium. That contact turned into interest, and the interest turned into a new role.
What tipped the balance was a shift in perspective. Writing software was one thing. Making sure that software was as free of defects as possible and easy to use was another. The first time Benjamin watched Selenium run browser tests on its own, he knew this was the direction he wanted to take. His employer at the time had no path into testing, so he moved to a test automation engineer role, which he has now held for almost ten years.
Test Code Is Code and Follows the Same Principles
Developers who move into test automation bring a mindset that treats test code like production code. That is the biggest difference from automation engineers who come from exploratory testing.
Both backgrounds have their strengths. Exploratory testers bring broad knowledge of test methods and an instinct for where to look to find bugs. Benjamin says he is still building that instinct after ten years.
Developers bring clean code principles, design patterns and software craftsmanship. The attitude behind it: test software is software too, and it has to follow the same principles as the application under test. That means test code that is itself tested, extensible and maintainable for years.
Whether spaghetti code in automation is a problem depends on how long the code lives. A quick script that checks something once and gets thrown away doesn’t need high standards. An internal test framework that stays the tool of choice for years does. It lasts that long precisely because it follows those principles, is tested and can be extended.
How Testing and Development Skills Pull Each Other Up
Development skills and test methodology work best together when both sides learn from each other. In practice, that happens through working side by side.
Benjamin describes a colleague who came from deep QA and took over a test automation role. The colleague picked up the technical side quickly, and Benjamin learns about test methods from him. Each raises the other’s level.
For Benjamin, that is the ideal role. He does work that makes the software better in every respect and still keeps the full scope to design and write code. That is exactly why he moved into testing in the first place.
Why Selenium Is Still the Tool of Choice
For browser tests, Benjamin sticks with Selenium, because knowing a tool in depth is worth more than chasing whatever is newest. If you know the code and how a tool works inside, you can judge what it can and cannot do.
He keeps an eye on Playwright and Cypress, but Selenium stays his tool of choice. He names two specific limits of Playwright: it doesn’t drive the browsers people actually use, only their engines, and Selenium is still stronger for testing on real mobile devices. At the same time, he acknowledges that Playwright has a large community and is a good tool with a lot of work going into it.
One point often gets lost in these comparisons. Selenium is more than a tool for controlling browsers. Part of the Selenium group works on standards, such as the W3C standard for bidirectional communication with browsers. Playwright also uses BiDi, a principle that comes out of the Selenium world.
The takeaway is simple: an older tool isn’t automatically a bad tool. Selenium keeps evolving and adapting.
How Developers Can Build Testing Knowledge
The most effective route runs through people, not material. Colleagues and mentors with long testing experience had the biggest influence on how Benjamin learned.
In practice, that means looking over the shoulders of experienced testers. How do they track down the cause of a defect? Which tools do they use? What reasoning do they follow? Some of his colleagues know the product features so well that they can tie a bug to a particular combination of features before they even look.
Blogs and conferences add to that. Benjamin deliberately goes beyond the technical talks and also picks experience reports and sessions on exploratory testing, because that is where he still wants to grow.
AI in Day-to-Day Testing: Used Daily, With Clear Limits
AI tools are part of everyday work now, but they don’t do the work for you. Benjamin uses them every day, and management backs this. The point isn’t to use AI for its own sake, but to learn what the tools can do and where they help.
Among the tools in use or under evaluation are Copilot, Claude, Cursor, Junie and CodeRabbit for reviews. An internal tool gives access to around twenty different LLMs to experiment with. Daily use also means the limits and risks show up daily.
Benjamin considers the promises of some testing tools overblown. He has heard claims like “this solves everything” or “we can get rid of our QA team.” Once you evaluate them, they turn out to be ordinary tools with ordinary limits. The pitch sells well right now, but often doesn’t survive contact with real projects.
“I swing between real fear of the future and the hope that it actually works. Honestly, that changes by the hour.”
(Benjamin Bischoff)
When AI Writes Most of the Code, Testing Matters More
The more code AI generates, the bigger the role testing will play. That is Benjamin’s central prediction for the future of the job.
He has little time for pure vibe coding, prototypes aside. He is skeptical of the idea that you just describe a piece of software and get it back working one hundred percent. If that ever happens, he says, he would have to look for a different career.
A different scenario is more likely, and it isn’t a comfortable one. There will be a great deal of software of unknown quality. On top of that, the same software will be copied over and over, including by people who can’t program and just want to sell the result. Without countermeasures, that can end in serious chaos. Someone has to look at all that code, and that shifts the weight firmly toward testing.
Principles Before Tools: Getting Started With Test Automation
If you come from testing and want to move into automation, don’t start with a tool. Start with principles. Clean code and design patterns are a better starting point than asking which framework is trending. For the fundamentals and for what is worth automating at all, see the overview on test automation.
The practical first step is small. Take something you do two or three times a day and put it into a short script. Bash or Python hardly matters. Once three lines of code save you repetitive work, you’re in.
The common mistake runs the other way. If you learn Playwright only because everyone uses it, you learn how to operate the tool, but not what happens underneath. That understanding matters more.
This is where a testing background helps. As a tester or QA engineer, you already work inside the software development lifecycle and know the basics. The job is to go deeper in the right places.
One last point takes some pressure off. If you can program, you aren’t tied to one language, because the concepts transfer. Benjamin now works in Python without having used it before. He knows the concepts and only has to learn the syntax and commands. It’s like picking up a new language when you already speak a related one.
Frequently Asked Questions
Do you need a degree in computer science to get into test automation?
No. Benjamin Bischoff started with an apprenticeship as an IT specialist for application development, worked as a freelance web and Flash developer for six and a half years, and entered the field of testing through the gaming industry. His exposure to QA, test processes, and Selenium didn’t begin until he started working. That led to a role as a test automation engineer, which he has held for nearly ten years.
Does test code have to meet the same quality standards as production code?
That depends on its lifespan. A script that quickly checks something and is then discarded doesn’t need to meet high standards. An internal testing framework that remains the tool of choice for years, however, does: It lasts only as long as it follows clean code principles, is self-tested, and is extensible.
What do automation engineers with a background in exploratory testing bring to the table?
They bring broad knowledge of testing methods and an instinct for where to look to find bugs. Some know the product features so well that they can attribute a defect to a specific combination of features before even checking. On the other hand, the development side brings clean code, design patterns, and software craftsmanship. Both sides lift each other up within the team.
Is Selenium outdated compared to newer tools like Playwright and Cypress?
An older tool isn’t automatically a bad tool. Selenium remains the tool of choice for browser testing because Playwright doesn’t drive the browsers people actually use, only their engines, and performs less well when testing on real mobile devices. Part of the Selenium group also defines standards, such as the W3C standards for bidirectional communication with browsers.
Are books, blogs, and conferences enough to learn testing methodology?
They’re helpful, but they’re not enough on their own. Colleagues and mentors with extensive testing experience have the greatest influence: look over the shoulders of experienced people, see how they find the causes of defects, what tools they use, and what thought processes they follow. At conferences, in addition to technical presentations, experience reports and talks on exploratory testing are also worthwhile.
Can AI tools replace a QA team?
No. Promises like “this solves everything” or “we can do away with our QA team” usually don’t hold up in practice, even if they sell well. Upon evaluation, it becomes clear that these tools are ordinary tools with ordinary limits. AI tools like Copilot, Claude, Cursor, or CodeRabbit for reviews are used daily, but they do not replace human work.
Does AI-generated code make testing obsolete?
The opposite is likely true. The more code is generated by AI, the more software there is whose quality is unknown. Added to this is the widespread copying of the same software, even by people without programming skills who want to sell the result. Someone has to review this code. This clearly shifts the focus toward testing.
Should you start your journey into test automation with a widely used framework?
Better not. If you learn a tool just because everyone else is using it, you’ll learn how to use it, but not what’s going on underneath. Clean code and design patterns make for a more sensible starting point. The pragmatic first step is a small one: turn a task you do two or three times a day into a short script, whether in Bash or Python.
