u/bilal-ziyan

Junior SDET here, 2 years in. I started under one of the seniors on my team who taught me how to write decent Selenium and Playwright tests. Last month she got pulled into a 1:1 and told her role is "merging into engineering" and she's now an engineer who focuses on quality. The same talk went to the other 3 seniors on the team yet I don't see anybody saying any of this in standup. I want to know if this is happening everywhere or just here.

We're a Tier-1 automotive supplier and have our first formal CSMS audit under ISO 21434 coming up in Q3. I've been put in charge of making sure our testing process is audit-ready and the more I dig into what auditors actually want to see the more I realize our current setup is going to be a problem.

Right now our team of engineers run tests and the results go into one system, then requirements traceability is maintained manually in another, so when an auditor asks to see the evidence chain from requirement to test to result we have to stitch it together manually every time. It works but it's REALLY slow and error-prone.

What ISO 21434 wants is a clear unbroken chain showing that every cybersecurity requirement was tested, that the test results are documented, and that the evidence is reproducible and verifiable without manual assembly before every audit cycle.

Has anyone here dealt with a similar traceability gap, automotive or otherwise, and found something that actually solved it?

So our CI coverage was around 87% and we still shipped a bug that only existed on the physical device. Green builds across the board. unit tests, integration tests, the works. felt solid.

Then a bug gets flagged post-ship, a timing-dependent failure that only reproduced on the actual edge device. Our test environment used emulation and never hit the same conditions as real hardware. It was invisible to everything we had. With two weeks to diagnose, CI was green the whole time.

We've since added an on-device validation stage that runs on real hardware before anything reaches staging. Blocking, not advisory. It's caught things every week since we turned it on.

The real issue is we built the entire pipeline around software assumptions. coverage metrics measure code paths, not hardware behavior. They're different problems and most pipelines treat them the same.

How do others here handle this? Do you have any on-device testing stage in your pipeline or is physical hardware validation still a manual step at the end?

Ok rant. I'm a senior embedded engineer and my main job is writing and shipping software, but last release cycle I spent 9 days producing compliance documentation because our technical writer went on sick leave three days in and my manager decided that knowing the codebase made me the right person to manually assemble evidence tables.

Let me explain what that actually looks like. Every release we produce a full traceability document: requirements mapped to tests mapped to results mapped to evidence artifacts.

Nine days of manually mapping test outputs to requirement IDs and pasting evidence into Word tables. The same sequence of actions hundreds of times. Every piece of evidence already existed in the system in machine-readable form. I was basically the bridge between two structured data formats because nobody had built the actual bridge.

What I cannot move past is that this feels like a solved problem in theory. The test run output is structured data and traceability tables are structured data. The mapping between them is deterministic.

We're now trialing a setup using askui for visual validation and squish for functional flows, piped into GitLab CI so the traceability output gets generated as a byproduct of the run itself. No separate documentation step and no human bridge.

Thanks for reading my rant. Wrote this during my commute home because I’m really curious to know how widespread this still is. How many engineering teams are still doing this manually every release cycle, and has anyone actually solved it?

Every time a new tool comes out—Compilers, IDEs, StackOverflow—the old guard calls it 'cheating' or 'lazy.' Now it's LLMs. If you can use an agent to do the boilerplate so you can focus on architecture and logic, you're a better engineer than someone spending 3 hours debugging a syntax error. Gatekeeping how code is generated is a waste of energy.

Just had finished midterm holidays and looking back at it I've noticed that I've spent 90% percent of my time staring to a screen either it's my phone or laptop and was wondering ,what do you all do for fun that doesn't require a battery or a Wi-Fi connection?

I started at an automotive Tier-1 six weeks ago as a junior test engineer and already hit a wall I can't get past. The engineer handling HMI test automation for one of our cluster projects left before I joined and my lead handed me the task of figuring out where they left off.

The cluster runs on QNX and my job is automating validation of the HMI layer. Tried Selenium first, no DOM so that was never going to work. I asked my lead and he said standard tools don't work here and I need something that interacts with the screen visually, but didn't point me to anything specific and I got the impression he hadn't actually solved this himself.

I've seen image-based testing mentioned but everything I read says it's fragile because any UI change between firmware versions breaks the comparisons and you're constantly updating baselines.

So right now I’m seeking help from professionals here. What's an approach i could go for for automating HMI tests on a target with no DOM and no accessibility tree?