Agreed, and if anything happens to not go perfectly - oops wrong software version, oops wrong pin, etc etc - then it’s easy to waste several hours just trying to figure out what is going wrong.
A big mistake people tend to make when estimating time is that they only estimate things going right, not factoring in the time required for figuring out when things go wrong.
Agree. Often times testing means intentionally trying things that may cause problems to make sure they dont. I am a champion of breaking software at work, even when I'm not trying to. :-)
I anticipate that a product is fairly well tested before requesting a road test, unless it is clearly stated the product is an alpha or early beta release.
Most road tests seem to be Charlie releases, and that's why a supplier benefits from the experience diversity of the E14 community and some unique project ideas to try. Those unique ideas do take time to troubleshoot and blossom especially if they exercise functions that may not be tested well enough yet.
I did this Pi 4 Roadtest a few years back: /products/roadtest/rv/roadtest_reviews/685/roadtest_the_raspber
I can’t remember now but would guess it took at least 24 hours.
The Pi4 was also a component in the Sound and Vibration Measurement Hat for Raspberry Pi.
I didn't spend too much time reviewing the Pi, but it got used in anger while I focused on the DAQ hat. Using the Pi4 for the 1st time, with the Buster OS, was easy.
For that road test? A Lot. I'd say 80 hours at least. Most likely more.
Not all of that time was efficiently used. Sometimes it was just fiddling around and see how things behaved. For the test gizmo I traveled to a makerspace and worked with balearicdynamics .
For the SCPI server and LabVIEW drivers and test flows, the hours are uncountable (and unaccounted for). Many of those hours were spent with shabaz on chat. He was working on a MatLab integration.
For the industry-relevant calculations and analytics, I worked with friend martinvalencia from Peru, at (my) night. He taught me all the calculus, and what KPIs were critical for predictive maintenance in heavy industry (mining).
I keep working on it (and blogging about it - although that goes unnoticed these days). Recently I tested a circuit (a good one !!) from michaelkellett on the road test kit.
That was a great RoadTest, especially bouncing ideas off each other! It helped we are in the same approx timezone too. People can do a lot with such high-res data acquisition with Pi, it's a great combination.
I've got a little list of features requests, waiting to submit them as soon as the site stability is there!
One of them is that whenever anyone replies, they get a choice of 2 buttons: one will subscribe them (i.e. the button should be "Reply and Subscribe" which will subscribe to all notifications (i.e. edits to the blog and any replies) and the smaller button next to it should be "Reply" which will not affect the subscription/notifications). That way, those that want granular control as it is today, still have it, but everyone else can have the improvement. Similarly for Likes, when people click on it, there should immediately be a pop-up, to either confirm the like, or to confirm _and_ subscribe. It will slow down 'Likes' slightly, but I can't see that could be a problem, or there simply should be a another option, i.e. a "Like&Subscribe" button. Also, the site messaging remains the same, if the pop-up is in JavaScript or if there is a separate button and no pop-up.
The latter could also encourage Likes because people will do that "Like&Subscribe' whenever they want to quickly be subscribed.