This content originally appeared on HackerNoon and was authored by Raj
The first half of my career was Selenium. The second half so far has been Fire TV streaming sticks and an AI bug triage agent. Those sentences look unrelated until you realize they're both test engineering, and then they look unrelated for a different reason: each one demands a completely different mental model of what your job actually is.
This is an observation about the field, not a how-to-pivot guide. I am not going to tell you what to study or which certifications to chase. I am going to tell you what each of these worlds demands, what travels between them, and what doesn't. Because the test engineering field is in the middle of a quiet transition right now, and I think a lot of people are about to find themselves on the wrong side of it without realizing why.
World one: web automation, where the bug is in the page
If you came up through Selenium and Java like I did, your model of test engineering looks something like this. There is an application. The application has a UI. The UI is rendered by a browser. Your job is to drive that browser, simulate the things a user would do, and assert that the right things happened in the right places.
The skill set that this rewards is specific. You get good at locating elements in a DOM. You learn the personality of XPath versus CSS selectors. You build Page Object Models so your tests don't fall apart when somebody renames a button. You wire up TestNG or JUnit, you bolt on Cucumber if your team likes BDD, you spend a non-trivial amount of time keeping Selenium Grid or Sauce Labs running so your tests can execute in parallel across browsers. If your team is mature, you eventually layer Karate API tests over the same domain so you're testing both the front-end and the API contracts.
This work is not glamorous, but it is not easy either. The hard parts are mostly invisible to people outside the discipline. Flaky tests. Asynchronous waits. The fact that the same UI behaves slightly differently on three browsers and you have to decide which differences matter. The fact that your test suite takes ninety minutes to run and somebody just asked if it could take thirty. The fact that an entire release can be blocked because a CSS class name changed and nobody told you.
The mental model that makes you good at this is one of pattern matching against a known surface. The application is a black box that emits HTML, and your job is to know what the box is supposed to emit and complain when it doesn't.
World two: embedded devices, where the bug is in the universe
Then I started working on Fire TV streaming sticks. The shape of the problem changed completely.
In web testing, the device under test is a browser running on a laptop you control, talking to a server you can SSH into. Everything is in software, everything is observable, and if a test fails you can read the logs. In embedded testing, the device under test is a piece of hardware sitting in a lab, possibly drawing power from an instrumented socket, possibly being power-cycled by a programmable USB switch, possibly being driven by an emulated infrared remote, possibly being watched by a high-speed camera so you can verify the splash screen actually rendered. You don't SSH into it the way you SSH into a server. You're lucky if you can get ADB working over Wi-Fi without it dropping out every twenty minutes.
The shape of "a bug" is different too. In web testing, a bug is a thing that happened in software. In embedded testing, a bug might be a thing that happened in software, or it might be a thing that happened because the wall power was noisy that day, or because the device thermally throttled in a way the test didn't anticipate, or because a firmware update changed the timing of a signal you were relying on. The system you're testing has a physical existence, and that physical existence has its own opinions.
This is also the world where regulatory testing lives, which is something most web engineers never have to think about. Devices that draw power and ship to consumers have to certify against energy regulations in every market they're sold in. The US has DOE and CEC. Europe has ErP. Canada has NrCan. India has BEE. Japan has its own regime. Each one writes a number on a page and says your device cannot draw more than this many watts in active mode, this many in active standby, this many in passive standby. If you can't prove your device complies with documented test results, you can't ship it in that market. That's a different kind of stakes than "a unit test failed."
The skills that travel from web to embedded are mostly the meta-skills. Designing test frameworks. Writing maintainable Python or Java. Understanding what a flaky test is and why you should not tolerate it. Knowing how to think about test coverage as a portfolio rather than a checklist. The skills that don't travel are most of the surface knowledge. None of your XPath instincts help you debug why a power meter is reporting noisy readings at three in the morning. None of your Selenium Grid experience prepares you for orchestrating thirty-three devices across two physical labs and making them run regulatory test suites unattended for weeks.
Web engineers who try to enter this world without respecting that gap tend to get humbled fast. So do embedded engineers who try to go the other direction and assume web testing is trivial because it's "just clicking buttons." Both groups are wrong about the other in symmetric ways.
World three: testing systems that aren't deterministic
And then there's where the field is going right now, which is testing systems that don't have stable answers.
In both web and embedded testing, the assumption underneath every test you write is that the system has a correct behavior, and your job is to verify it produced that behavior. Click the button, expect the dialog. Send the IR command, expect the device to enter standby within two seconds. The output is deterministic. The test is a comparison.
Now think about an LLM-based system. You give it a bug report. It produces a root cause analysis with a confidence score. Run the same input twice and you might get slightly different prose, organized differently, with different supporting evidence pulled from a knowledge base. The output is not wrong, but it is not the same. Your old comparison-based test framework has nothing to say about this situation.
Building an AI-powered bug triage agent forced me to actually sit with this problem. The agent uses RAG over a corpus of 1,100+ previously resolved issues, computes a weighted confidence score across five signals (historical pattern match, source code match, crash stack analysis, log evidence, fix ownership), and produces an analysis a human triager either accepts or pushes back on. The interesting question is not "did the model say the right thing." The interesting question is "did the model produce a useful output, and does its confidence score correlate with whether it was actually useful."
Those are different questions. The first one looks like traditional testing. The second one looks like something closer to evaluation, and evaluation is where most test engineers are weakest, because it's the part of the discipline that hasn't been formalized yet.
The field has frameworks for unit tests, integration tests, end-to-end tests, performance tests, security tests, accessibility tests. It does not have widely-agreed frameworks for "is this LLM output good enough." That gap is being filled in real time. Some of it will end up looking like statistical evaluation borrowed from ML research. Some of it will end up looking like A/B testing borrowed from product engineering. Some of it will end up looking like nothing we've seen before.
This is the part of the field that I think most test engineers are underestimating. It is not the case that AI is going to make traditional QA obsolete. Web applications still need Selenium tests. Embedded devices still need power profiling. None of that is going away. But the new layer that is being added on top, the layer where you have to make probabilistic statements about whether a non-deterministic system is producing useful outputs, is going to demand new skills and a different mental model. The engineers who get there early will have a large advantage.
What actually transfers
The thing that transferred from world to world for me, more than any specific skill, was a discipline about engineering the test infrastructure itself.
Test code is software. It deserves the same care as production code. It needs documentation, it needs tests of its own, it needs a clear ownership model, and it needs to be designed so somebody other than the original author can maintain it. This sounds obvious and is widely ignored. The cheap version of test infrastructure is one engineer's pile of scripts. The durable version is a framework that other engineers can extend without asking the original author what "that one config flag" does.
The other thing that transferred was a healthy respect for what you don't know. The first time you go from web to embedded, you should expect to feel stupid for about six months. The first time you go from embedded to AI, the same thing happens. The temptation in both cases is to lean on your old expertise and pretend the new domain is just a variation on the old one. It isn't, and pretending otherwise is how you ship things that look right and aren't.
If I were giving advice to a test engineer five years into their career, it would be: spend a year working on something genuinely outside your current discipline. Web engineer? Go work on hardware-in-the-loop automation for a quarter. Embedded engineer? Go build something that talks to an LLM API and figure out how you'd test it. The discomfort of being a beginner again is the price of admission for staying relevant in a field that keeps reinventing itself.
Where this goes next
I'm not going to predict where the field will be in ten years. People who do that are mostly wrong. But here's what I think is currently true.
Traditional test automation is becoming table stakes. Knowing Selenium and TestNG used to be a differentiator. Now it's the floor. Anybody who wants to stand out has to be able to design test infrastructure, not just write tests against an existing framework.
Embedded and hardware-adjacent testing is going to grow as more software ships in physical products. There are a lot of consumer electronics teams that are about to discover they need real test engineering practices, and there aren't enough people who know how to build those practices in a hardware context.
AI evaluation and LLM testing is the wide-open frontier right now. The vocabulary is unstable. The frameworks are immature. The titles are inconsistent. This is exactly when it's most worth getting in, because the people who help define the practice over the next few years will end up being the people who set the rules.
The career path that I'd watch out for is the one where you stay in your current world too long, get really comfortable, and then look up one day and realize the field has moved. Selenium engineers who never learned API testing got stuck. API testers who never learned cloud got stuck. The pattern is recurring. The current iteration of it is unfolding around AI right now, and I don't think most people in test engineering have noticed yet.
The good news is that the meta-skills do travel. If you've been a careful test engineer in any domain, you have most of what you need to be a careful test engineer in the next one. You just have to be willing to be a beginner for a little while.
\
This content originally appeared on HackerNoon and was authored by Raj
Raj | Sciencx (2026-05-14T02:58:44+00:00) Ten Years in Test, Three Different Worlds: What I Learned Moving from Web to Embedded to AI. Retrieved from https://www.scien.cx/2026/05/14/ten-years-in-test-three-different-worlds-what-i-learned-moving-from-web-to-embedded-to-ai/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.