La complessità dei test accelerati

Vi è mai capitato di eseguire test accelerati su un prodotto? Cosa ne pensate?

Io credo si tratti di verifiche estremamente complesse, alle quali è necessario prestare molta attenzione.
Vi faccio un esempio.

Immaginiamo che ci venga chiesto di progettare un dispositivo con la funzione di aprire e chiudere le porte di un ascensore, che sia in grado di supportare 500mila cicli di apertura/chiusura. Cosa si fa in questi casi? Lo si progetta, si effettuano le varie simulazioni virtuali, ma, per verificare quanti cicli sia effettivamente in grado di fare, se ne deve necessariamente costruire il prototipo per poi fare un test reale.
Una fase, quest’ultima, che molto spesso ha dei tempi lunghi e, di conseguenza, dei costi significativi. Nel caso del nostro ascensore, per esempio, la fase di test consisterà nel far fare alla porta 500mila cicli di apertura/chiusura.

Molto spesso per risparmiare si effettuano dei test accelerati, che però non sono mai oggettivi, perché nella realtà il più delle volte subentrano fattori esterni che finiscono per incidere sul risultato finale di tale test. Torniamo al nostro esempio del dispositivo per aprire e chiudere le porte dell’ascensore. Nel caso si effettui un test accelerato si deve necessariamente tenere conto del fatto che la porta di un ascensore si apre e si chiude 500mila volte senza mai fermarsi, ma – al contrario – ha diversi momenti di stop: si apre, i passeggeri entrano, si chiude, raggiunge il piano, si riapre per far scendere le persone e poi, molto probabilmente, fa un’altra sosta che sarà più o meno lunga e così via.
Ogni momento di sosta, quindi, dovrà essere tenuto considerazione anche in fase di test del prototipo perché, per esempio, permetterà al motore del dispositivo di raffreddarsi. Se continuassimo a testare il dispositivo senza intervalli, la verifica non sarebbe realistica.

Tenendo in considerazione tutti questi fattori, però, si dilaterebbero ulteriormente i tempi della fase di test (e di conseguenza i costi). Questa è la ragione per cui è pratica comune parametrizzare i dati: si stima, per esempio, che a 500mila cicli velocizzati ne corrispondano per esempio 200mila reali.
Ma è proprio il calcolo del coefficiente alla basa della parametrizzazione dei dati che mi lascia un po’ perplesso. La domanda infatti è: questo coefficiente è davvero reale oppure è stato solo ipotizzato?

Se non si tratta di un’applicazione già sperimentata precedentemente e dove quindi il dato è reale (o comunque molto verosimile), secondo me si sta ipotizzando. E se si sta ipotizzando, com’è possibile capire davvero se il dispositivo che si sta testando funziona oppure no?

Ma non solo. Pensate al lubrificante. Vien da sé che se devo fare una prova di funzionamento in continuo opterò per un tipo di lubrificante che mi permetta di far fronte al surriscaldamento del motore del dispositivo in questione. Al tempo stesso, però, ne sceglierò uno con qualità diverse se il funzionamento di tale dispositivo non sarà più in continuo, bensì a intervalli (e quindi con una soglia più bassa di surriscaldamento).
Perciò, se considero l’importanza che un prodotto come il lubrificante ha nella soluzione che ho appena progettato, non posso certo pensare di usarne uno in fase di test e poi uno differente nella vita reale del prodotto, anche perché questo già di per sé renderebbe poco verosimile il mio test. Siete d’accordo?

Mi piacerebbe conoscere qual è la vostra opinione ed esperienza in proposito.