Lavoro in un'azienda di medie dimensioni (150 dipendenti, un team di ingegneri di dimensioni pari a 10) e la maggior parte dei miei progetti riguarda l'interfaccia con apparecchiature di laboratorio (oscilloscopi, analizzatori di spettro ottico, ecc.) ai fini di applicazioni di test semi-automatizzate . Ho riscontrato diversi scenari in cui non sono in grado di risolvere o testare efficacemente il nuovo codice perché non ho più o non ho mai avuto a disposizione la configurazione dell'hardware.
Esempio 1: Un'impostazione in cui i processi da 10-20 "burn-in" vengono eseguiti in modo indipendente utilizzando un sensore di tipo da banco: sono riuscito a ottenere uno di questi sensori per testare e talvolta a rubare un in secondo luogo per simulare tutte le sfaccettature dell'interfacciamento a più dispositivi (ricerca, connessione, streaming, ecc.).
Alla fine è apparso un bug (e alla fine si è ritrovato nei firmware e driver del dispositivo) che era molto difficile da riprodurre con precisione con una sola unità, ma colpire vicino ai livelli "show stopper" quando 10-20 di questi dispositivi erano in uso contemporaneamente. Questo è ancora non risolto ed è in corso.
Esempio 2: un test che richiede un costoso analizzatore di spettro ottico come componente principale. Il dispositivo è piuttosto vecchio, legacy secondo il produttore che è stato acquisito da una società più grande e sostanzialmente disciolto, e la sua unica documentazione era un documento lungo e disinformato che sembra tradotto male. Durante lo sviluppo iniziale sono stato in grado di tenere il dispositivo alla mia scrivania, ma ora è legato, sia fisicamente che in programma durante i suoi test di 24 ore su 24, 7 giorni alla settimana.
Quando i bug si presentano correlati o non correlati al dispositivo, spesso ho bisogno di passare attraverso il problema di testare il codice esterno all'applicazione e installarlo, o scrivere codice alla cieca e tentare di spremere un po 'di tempo tra un test e l'altro, la maggior parte della logica del programma richiede che l'OSA e il resto dell'hardware di test siano installati.
Credo che la mia domanda sia come dovrei approcciarmi a questo? Potrei potenzialmente passare del tempo a sviluppare simulatori di dispositivi, ma capire che nella stima di sviluppo si gonfierà più di quanto la maggior parte probabilmente apprezzerebbe. Potrebbe non riprodurre accuratamente tutti i problemi, ed è piuttosto raro vedere la stessa attrezzatura utilizzata due volte qui. Potrei migliorare al test unitario ... ecc ... Potrei anche essere rumoroso riguardo al problema e far capire agli altri che saranno necessari ritardi temporanei, non molto più di un mal di testa per la ricerca e lo sviluppo, ma di solito percepito come uno scherzo quando presentato alla produzione.