Ah sorry, I didn’t so much mean to push for switching entirely from developing software to designing hardware. I was trying to suggest aiming for developing software for low level hardware, like embedded development. If you’re comfortable with C#, it likely will be simpler to at least start reading C++. I went in the opposite direction there myself though.

I started learning programming by playing around with TI-Basic on Texas Instruments graphing calculators. Then I learned Z80 Assembly to get around a common bug with hitting left and up at the same time in writing games on the calculators. Then I got a different calculator that had a Motorola 68000 or something CPU in it instead of a Z80, so I attempted to learn that assembly, but noped out of it and learned C instead. Then naturally progressed into C++ before I ever took a programming course, which ended up being on Visual Basic.

It only took me a mere 9.5 years to graduate with my four year bachelors degree, so I started in tech support with no degree, then moved into Operations with no degree as an internal promotion. I’d been working in Operations helping with testing for years before I finally finished and got my degree, then just kept working there for several years more. So I think I get the self taught part pretty well at least. All of the things my degree tried to teach me, I had already learned either on my own directly, or by being pushed there for work.

I’m unfamiliar with that ISTQB certification, but if it is that expensive, they very well may be willing to pay for you to take the certification if you ask about it. Especially if they’re having trouble finding people to hire.

I guess just to try and describe my own experience with “testing”, although largely focused on testing hardware. The developer/engineer provided information on what the thing was supposed to do and how it should act. Sometimes they even had documentation instead of just a verbal discussion and a whiteboard. They would often provide a software tool or API to get into some portion of the hardware and allow access to various things to verify whether they were working. This often involved physically connecting various components to the device and trying to send data across. So there was a lot of send this thing, then try to read it back and see if it came through the same as a basic test that everything was connected. Then drivers/firmware would get installed/updated and we’d try some higher level functional usage of the device as best we were able. Depending on the purpose of the hardware, this wasn’t always possible to test in actuality, so a lot of the time this would be running more things in a loopback mode that the drivers supported, even by customers in the field. We used Linux, bash, perl, python, and various other things to try and automate as much of this procedure as possible for the hardware. By the time we were done automating, testing most of the hardware was as simple as install it in the test fixture and connect it according to a diagram, then turn on the test fixture. The fixture would identify what was installed, load the correct test, and report whether the results were nominal. If they were not, it would at least outline the step that failed so the test operator knew what to inspect if possible.

As for more direct me testing, that would be the returned field failures. Much of our hardware ran in a regular PC, so there was a lot of regular PC troubleshooting steps to reproduce/verify a failure. Then I eventually learned soldering and was taught some PCB/hardware stuff to do deeper dives on the boards, but that was all taught/learned on the job.

I basically got the operations position because I had shown I was good at troubleshooting and problem solving in general, and that I was capable of learning a system enough to be considered the local “expert” on it. Then I was taught or learned anything else I needed to know after I got the position.

So, hopefully you haven’t given up too much yet, and perhaps you can try out applying for some positions where you don’t quite meet all the “requirements” for it. Then just describe situations that show your general capabilities, and that you can learn what they need after you get onboard. Hopefully your luck will turn soon and you can get on into something somewhere.