I originally thought the same thing as Battar. In stuff I used to work on, test routines were never kept in the main operational software. They changed the timing, for one. But that was in the old days when cycles weren't "free." I can see if you architected generalized tools, as you say, Chris, then adapted them for different applications right at the outset, the could "live" in the real code because they'd go thru the complete test and dev cycle like everything else.
@ Battar: Additional code certainly does increase the software V&V burden, but if architected properly they can actually make the SW team's work easier. In every instance where I've requested operational additions I architect them to be generalized tools that everyone can use for test and debug. Once implemented, I then work with the SW team to work these features into their V&V test plans and procedures. In the end, the additions have actually reduced the overall SW test load and have repeatedly streamlined the whole development process.
I can never get the software crew to add test routines to the "operational" software. They insist that this would require retesting the entire software, and they are right. Their policy is to program the test routines, run the tests, then re-program with the operational file. What iif a bug caused a jump to a non-existant address, wihch in you setup would suddenly exist?
You alreayd corrected the typo in the article (burning room? Where are those smoke detectors when you need them - or was this a device to identify firemen while they enter a building ;-)
I presume that the relay was the first installment of the test and not used as soon as the solution was found in adding test routines in the unit's own software that would automatically scan every minute, so they only had to place the cups with simulated retina, throw the hidden switch and there was no need to have something interact with the device to initiate the test.
I recall our automated test of mobility-enabled DECT base stations and terminals. Two base stations were installed at two sides of a room, toy train tracks were laid out between them, the train cars were stuffed with handsets that had a special version of their normal software, the added User Interface routines generated (and tallied) outgoing calls with random timing. After a night of testing you could read the tallies and compare with statistics from the Base Station to see how many calls were missed or dropped, while the terminals roamed between the base stations.
So how did you attach the relay to the fixtures holding the scanners, so that it could physically execute the key press? And did you have to build those fixtures; I'm assuming not, since you were using the burn-in room anyway, prior to your time-saving auto-keypress solution.
What should be the perception of a product’s real-world performance with regard to the published spec sheet? While it is easy to assume that the product will operate according to spec, what variables should be considered, and is that a designer obligation or a customer responsibility? Or both?
Biomimicry has already found its way into the development of robots and new materials, with researchers studying animals and nature to come up with new innovations. Now thanks to researchers in Boston, biomimicry could even inform the future of electrical networks for next-generation displays.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.