This weekend I recalled that up to 10 years ago I used to write New Year posts. There was little to no action in the past 10 years on this blog, but another decade – and 2021 – deserves a “hello again” post!
2020 was by all means special. You may think it was bad, it was good, neutral – but you will agree it was special. 2020 made us rethink the way we live and relate, and the way we study and work.
A month ago, I presented at TestFlix, an online video conference to which The Test Tribe was kind enough to invite me. The conference was scheduled on Shabbath, so I risked missing the conference (and my own talk)… luckily it continued after the Shabbath was over and I got to attend a couple hours of it – including the weird experience of listening to myself.
As far as online conferences went, it was pretty fun, with a small expo and different chat rooms. You look around your room and there’s no one other than your coffee mug, and yet you’re in touch with people around the globe.
EuroSTAR had a similar conference recently, for which you can see the stunning (stunning, I say! Content is top-notch, but just look at that graphic design!) program here.
Everything is online now! The joys of remote working from home sitting in a small room from dawn to dusk!
We’re a household of 10, with 6-7 of the kids studying over Zoom/Teams/Classroom, encouraging a tired and sweating D-Link router to make it through one more Mb – You can do it, little D-Link, you’re a big Cisco!
Testing in the time of Corona… Covid-19 gave us opportunities for many interesting conversations on Testing. From the discussion on whether testing more causes more bugs (after all, looking at your clock makes it tick slower, right?), to the realization that testing is the most important thing ever, all the way through rethinking your work routine.
On a practical and personal note, one of the things that working remotely demonstrated is, well, that testing remotely is possible in embedded and invisible systems. That statement is not as trivial as it seems: You see, working with embedded software means your product does not fit in the contents of a USB-Key, or in a GitHub repo. The embedded product (software) is located in a big board with a specific processor, usually connected to a bigger power supply and having all sort of flimsy wires tied to weirdly named devices (JTAG? Aardvark? Saleae? Lauterbach? Kvaser? Who’s naming these things??) that you connect to your computer when you test. It looks so scary, that once we needed one abroad for a business trip and we mailed it instead of taking it on the plane because it looked so much like a bomb 🙂 .
The quickest way to test this software is to be relatively close to it so you can turn it off and on, look at the LEDs, disconnect cables, reconnect cables, plug in other analyzers, look at it angrily to see if it finally obeys, nudge it in despair, and so on. Can we do this with no hands?
In 2015 I presented at EuroSTAR a talk called ‘Demystifying Embedded Software‘ (it was frontal, not online, as the internet didn’t exist back then). We discussed the many similarities between a desktop/mobile application and embedded software running on a specialized processor and an OS, and also the differences (which include optimizations of storage and power, runtime accessibility, unusual interfaces and fuzzy IO, and limitations in the software’s lifecycle).
I debated with myself briefly on whether to include the fact that embedded software needs you near. I was testing sensor subsystems at the time, so tests included shaking, rotating, and flashing lights at our product – certainly much harder to do from a distance. However, we were able to work from a distance – as we had robots to rotate, lightboxes to illuminate, coils to reorient, and all sorts of fancy toys. The conclusion was clear: It is possible to test a system like that remotely (so this didn’t make the slides), it is much harder too.
Jump forward 5 years and we must test things remotely 24/6. I am not testing sensors anymore, but the above still holds true: While I can test remotely, it requires fancy solutions as a medium.
While everyone will quickly tell you that that makes the work slower, I now discovered slowness is not the major drawback. The problem is that mediation means talking with the product through a translator. And if in person you can get a feeling of the software’s mood (is it slowing down? is it in trouble? did it restart surreptitiously?), having an SSH commanding an automatic query makes it much harder to notice the software’s reactions (is the network slow? is the serial interface in trouble? did the JTAG interface flicker?).
If on one hand I have now a full remote setup that allows me to control the product, on the other hand I still haven’t overcome the alienation that distance brings: I can’t feel the product due to the noise caused by the input and output toolchains. Monitoring the tools in use is becoming as important as monitoring the product itself.
“Monitoring the tools in use is becoming as important as monitoring the product itself.”
— Previous Paragraph
My lesson? When working remotely, we have to be double alert.
It is an interesting place to be, and it will hopefully retranslate into sharper instincts once we come back to normal.
“
Markus’s main motivation for organizing this talk was noticing an economic downtime a few years back, where conventional commercial education was costly to follow and pay for by companies or individuals. But even in this situation, if you’re in a position where you want to learn and educate yourself, there are other ways…