Adversarial Testing, was Thou shalt have no 1627

the ww1 trench cooperation ... if i don't shoot at you, you don't shoot at me ... there is some quid-pro-quo.

the disk engineering have extremely detailed error tracking over period of years ... if the product test engineers let something slip thru ... it reflects back on the product test engineers (they are on the line for not catching it ... and may involve large number of people physically visiting customer locations to remedy the problems)... there is nothing the development engineers can offer to really ameliorate-compensate. one issue is that there is an accountability infrastructure that really holds people accountable. this has been long term operation spanning decades producing long string of products.

a bigger issue in this scenario is to not have the product test engineers contaminated by buttumptions made by the development engineers ... so they don't become blind to same-similar short comings in the product ... it isn't a backscratching issue ... it is a view point contamination issue. if development engineers have overlooked something ... possibly because of the way they are thinking about the subject ... you don't want the same symptoms affecting the product test engineers.

for some topic drift ... a tale about how serious some of this is taken. there is this industry service that gathers erep (error reporting) data from customer installations about errors and publishes it. long ago and far away i had done this software hack for channel (aka local i-o bus) extension over telco link ... and if there was an unrecoverable error ... i simulated something called channel check to the regular channel processing error handling code (which would retry the operation in various ways).

some time later, a new processor was coming out which they had designed to have no more than 3-4 channel checks per year across all customers (not 3-4 channel checks per year per machine ... but an aggregate total of 3-4 channel checks per year across all machines). well to their dismay ... the industry reporting service shows up with there having been an aggregate of 15 channel checks across all machines the first year of operation. this kicked up some serious forensics (? the current in-word). They eventually tracked it down to this stuff I had done for channel extender over telco link and asked if I could change it. After some investigation, i determined that if i simulated IFCC (interface control check) instead of CC (channel check) ... the error recovery-retry processes would for all intents and purposes be the same.

--