Are you testing embedded software? playing with hardware? screwdriver is a part of your testing toolkit ?
This is the thread for us!
Letās connect 
Iām testing āsoftware definedā switches
Basically a big metal box that look like an ethernet switch with input and output ports, but we use fibre optics and light instead of electric signals. The software are the user interfaces (telecommunication protocols from the 70sā¦), and how to make all the mechanical pieces inside do the magic of directing the light from input to outputā¦
I am SO HERE for you! I spent my last two days before vacation (Yes, Iām on vacation now) staring at an oscilloscope. It wasnāt the best of software testing days.
My main job is making (aka testing) gas meters, but Iāve done a lot of other things as well, including solar panels and train safety systems. Itās a great combination of everything from software and hardware combined to makeā¦ Well, everyday things.
1 Like
I would love to get involved with renewable energy testing!
The most recent ābest momentā for me was when I purposely short-circuited a board with a screw to restart it . I felt so āevilā it was awesome 
1 Like
Ever take off components just to see how the software would react? Bonus point if there was smoke involved. Extra bonus points if there was no smoke involved the second time you did it.
LOL ! I didnāt go that far (our circuit board are very expensive and I donāt have enough to go around :/)
but I did spot smoke coming out of one one dayā¦ turns out that board was definitely too broken, even to be used by engineeringā¦
We need to test our hypervisor tech stack on baremetal hardware - all the Intel chipsets that we support. For that, we created our test infrastructure, which we are now also providing for open source projects for free: https://docs.sotest.io
Itās generally fun to automate tests that are impossibly to automate, and it is lovely to see the results when they run in the tens of thousands of times per month for little teams and eat up all the regression before buggy code hits the master branch.
Iām testing system which controls valves and pipes in the buildings. There is a control board (with display) and multiple valves are connected to it via wires. Also, there is a possibility of connection via bluetooth using mobile app.
that looks cool ! I will have a good read through this weekend
1 Like
I didnāt even realised that smart/connected valves and pipes existed!
Are we talking about stuff like water/electrical pipes/valves or something completely different?
Intriguing, tell me more (if itās not confidentialā¦ )
Yes it really exists, In short lines, with bunch of sensors and electromotors it can be accomplished a lot
I have spent the last 20 years testing embedded systems (18 of those for military projects). I am currently testing software for the automotive industry.
I think I may need a bit more experience to qualify to be in this thread
I think 20 years just might be enough 
1 Like
I have never pulled a single component off a board but I have pulled a whole board out to test what the software would do. Things were not pretty and the software team and management did not thank me for doing it but the customer did.
2 Likes
Definitely the correct place to be getting thanks from. And Iām sure that the SW team and management were thankfulā¦ but chose an odd way of expressing it.
Do you run into the problem ānot enough -working- hardwareā?
Do you have hardware for developers and different hardware for testers?
Basically how do you manage your hardware resources pool?
Those are outstanding questions!
I donāt usually have to worry about not enough working hardware. We make sure thereās a budget for extras in an initial series of a product for the testers and developers to all have their own. But the problem is, there has normally been one each. This means that a significant time in the initial release of a product is in repairs. Fortunately, this means that the tester (or hardware guys, or some really talented software guys) knows exactly what the weaknesses in the hardware are, because we have broken it and fixed it.
After the prototype, 0-series, and once mass production starts, itās absurdly easy to find or order new replacements, as long as there isnāt some budget magic to work through (i.e. one department charging another department full price for ā¦ no idea why, it doesnāt make sense why they would do that.) And even then, something could be worked out.
The question of different hardware is answered byā¦ you have different hardware versions only if you want the project to fail, but the testers and developers donāt need to be fighting over a piece of equipment. So if the budgets allows, everyone should have their own gear. There ARE cases where the budget doesnāt allow it (like when I worked in solar power and we had a 100k euro solar panel simulator. It was a beautiful thing!) In that case something needs to be worked out in the team.
In my smaller company now, we have two working oscilloscopes and four people who need them. This can be challenging. But I do have so much of our products (mostly returned or refurbished) that having places to store it is more challenging than finding something that works. The other problem is what most of our community are familiar with. Our apps need to run on more types of systems than we have access to. Weāre looking for solutions to that now.
your reply makes me so happy!
The product Iām testing costs loads :? (weāre talking Ā£100K+ for a small size product, the bigger the more expensive), so we obviously canāt get production-quality HW to engineering.
We end up with the customer returns-to-bad-to-be-fixed or we made a few that are scaled down (like thereās no fibre-optic support for them) to test the software rather than the hardware or system. No ideal but until the company realises the need for simulator, weāre juggling with what we have 
I tried to get a resources flow from our manufacturing team to have first pick in their rejected hardware. They have to reject hardware (latest version !!!) for problems that are actually easy for us to work around. But finances/politics stopped that flow from happening because they would charge engineering full price for that reject hardware. so instead a Ā£1000 board is put to scrap, when engineering is crying for it.Itās mad and heartbreaking.
We have 8 (different variants) products and 10 team members. The only way we found to keep track of who uses what is a dedicated channels on slack/Teams. we have a list of all the test hardware and people put their name next to it and any comments that is useful to know for that hardware (like no serial connection available, etcā¦). It feels so old-school and Iām looking for another more-modern way to do thatā¦
And donāt even get me started with the lack of physical space to store all the kitsā¦ Thereās more politics involved in that than in the whole Brexit mess.
1 Like
I have issue with not enough hardware. the hardware for the last project I was on was over a million pounds per setup (military grade everything) so there was only 1 setup and it was set for the hardware team to ensure all their stuff was working properly and to see what updates very needed, for the software team to be able to see how their code was working and the test team to be able to run all needed tests for the sprint.
We ended up getting a rotor up but you were only allowed to book for so long and only 2 days in advance. I got round it most of the time by working very early in the morning and a fellow tester worked very late in the evening so at times we use to rerun each others tests before whilst doing our own.
1 Like
Similar hardware āproblemsā in our project. If you are lucky with your sw archtiecture you may run the top (application) layer on a host computer (virtual machine, sandbox) and simulate / model the underlying hardware. By doing so we can cheaply test most of the fetaures of our application software on inexpensive hardware available for every tester or developper.
1 Like