Come risolvere in modo efficiente o testare il nuovo codice quando è difficile o impossibile ottenere l'installazione dell'hardware per riprodurre i bug?

Lavoro in un'azienda di medie dimensioni (150 dipendenti, team di progettazione di circa 10 dimensioni) e la maggior parte dei miei progetti prevede l'interfacciamento con apparecchiature di laboratorio (oscilloscopi, analizzatori di spettro ottici, ecc.) Ai fini di applicazioni di test semi-automatizzate. Mi sono imbattuto in alcuni scenari diversi in cui non sono in grado di risolvere i problemi o testare il nuovo codice in modo efficiente perché non ho più o non ho mai avuto la configurazione hardware disponibile per me.

Esempio 1: una configurazione in cui 10-20 processi di "burn-in" vengono eseguiti in modo indipendente utilizzando un sensore di tipo da banco: sono stato in grado di ottenere uno di questi sensori per i test e occasionalmente rubare un secondo per simulare tutte le sfaccettature dell'interfaccia per più dispositivi (ricerca, connessione, streaming, ecc.).

Alla fine è apparso un bug (e alla fine è finito nel firmware e nei driver del dispositivo) che è stato molto difficile da riprodurre accuratamente con una sola unità, ma ha colpito quasi i livelli di "show stopper" quando 10-20 di questi dispositivi erano in uso contemporaneamente. Questo è ancora irrisolto ed è in corso.

Esempio 2: test che richiede un costoso analizzatore di spettro ottico come componente principale. Il dispositivo è piuttosto vecchio, eredità secondo il produttore che è stato acquisito da una società più grande e sostanzialmente sciolto, e la sua unica documentazione era un documento prolisso (e non informativo) che sembra tradotto male. Durante lo sviluppo iniziale sono stato in grado di tenere il dispositivo sulla mia scrivania, ma ora è bloccato, sia fisicamente che nei tempi previsti durante i test di più di 24 settimane.

Quando i bug si presentano correlati o non correlati al dispositivo, spesso ho bisogno di superare il problema di testare il codice esterno all'applicazione e inserirlo, o scrivere codice alla cieca e tentare di spremere un po 'di tempo di test tra una corsa e l'altra la logica del programma richiede che OSA e il resto dell'hardware di test siano installati.

Immagino che la mia domanda sia: come dovrei affrontarlo? Potrei potenzialmente dedicare tempo allo sviluppo di simulatori di dispositivi, ma immaginando che nella stima di sviluppo ci riusciremo più di quanto probabilmente la maggior parte apprezzerebbe. Potrebbe anche non riprodurre accuratamente tutti i problemi ed è abbastanza raro vedere la stessa attrezzatura usata due volte qui. Potrei migliorare ai test unitari ... ecc ... Potrei anche essere forte sul 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 lanciato alla produzione.

La direzione comprende che ci vorrà più tempo per sviluppare e gestire il software quando non si ha pieno accesso all'hardware di prova. È necessario tenerne conto quando si effettuano le stime. Parte dei criteri di accettazione per mettere in produzione il tuo software dovrebbe essere che hai un modo per mantenere il software nella maggior parte dei casi senza interrompere la produzione. Se stai praticando il TDD, questo dovrebbe accadere in modo abbastanza naturale.

Scrivevo software per aerei da $ 60 milioni. Ovviamente, è richiesto un alto grado di affidabilità e sono riluttanti a offrire a ogni sviluppatore uno per la propria scrivania. Fondamentalmente avevamo 5 livelli di ambienti di test, con più hardware reale per ogni livello, fino a un aereo completo. Stimo che il 95% del nostro software potrebbe essere sviluppato e sottoposto a debug solo con emulatori e unit test. Il 95% delle funzionalità rimanenti potrebbe essere lavorato al livello successivo e così via.

Prova a impostare livelli simili di ambienti di test per te stesso. Non puoi aspettarti di non aver mai bisogno di accedere all'hardware reale, ma se l'hai impostato in modo da non poter lavorare sulla GUI del tuo software senza l'hardware disponibile, stai sprecando tempo prezioso su una risorsa costosa (non per menzione di alcuni problemi di accoppiamento con la tua architettura). Considera che altri sviluppatori hanno probabilmente i tuoi stessi problemi. Vorrei chiedere al fornitore dell'hardware se hanno già emulatori o altre risorse di test disponibili.

Devi anche cambiare la tua mentalità in qualche modo se hai un accesso limitato all'hardware. Anziché provare a eseguire il debug dell'applicazione in modo seriale normale, spesso è necessario scrivere codice specificamente allo scopo di raccogliere informazioni il più rapidamente possibile.

Ad esempio, forse hai un bug e puoi pensare a 10 possibili cause. Se l'unica volta che riesci a salire su una macchina sono i 15 minuti mentre l'operatore è in pausa, scrivi un breve, autocontenuto, corretto (compilabile), esempio che innesca il bug e scrivi 10 test automatici usando quel SSCCE per testare le tue teorie e registra un mucchio di dati. Di nuovo alla tua scrivania puoi impiegare tutto il tempo necessario per vagliare i dati per il tuo prossimo tentativo. L'idea è di massimizzare l'utilità del tuo tempo limitato con l'hardware.

Stai cercando di risolvere un problema che non è tuo da risolvere.

La direzione deve dare la priorità all'accesso all'apparecchiatura. Ciò può significare che si ottiene un maggiore accesso, ma può anche significare che si finisce con meno.

Presenta le sfide che hai in un formato obiettivo al tuo team di gestione e chiedi loro una guida. La tua presentazione sarebbe molto più forte se avessi collaborato con gli altri che hanno anche bisogno di accesso, in modo che tutti voi possiate presentare il vostro caso allo stesso tempo.

Da lì, la società (gestione) deve stabilire le priorità di chi accede e quando. È una decisione aziendale che devono prendere poiché la (mancanza di) disponibilità delle risorse sta influenzando lo sviluppo del business.

Stai effettivamente codificando cieco.

Se la gestione non pagherà per i dispositivi di test, allora c'è un'alta probabilità di bug o anche lo sviluppo impiega più tempo di quanto sarebbe se avessi dispositivi reali da usare.

Non è necessario che il costo dei dispositivi sia completamente allocato al ciclo di "sviluppo". Forse potrebbero essere ruotati in uso di produzione o come backup. Potrebbero anche essere rivenduti di seconda mano altrove?

Prova a costare le fasi di correzione dei bug, in tempo e denaro e mostra il costo complessivo per il tuo team / azienda.

Discutere con i tuoi capi è molto più facile quando hai alcuni numeri, o almeno alcuni pro e contro a portata di mano, quindi il mio suggerimento è quello di provare a fare un'analisi costi contro benefici. L'idea approssimativa è questa:

• quanto impegno di sviluppo ti aspetti per scrivere un simulatore di dispositivo? (Si noti che un simulatore di dispositivo non può sostituire l'hardware originale al 100%, specialmente quando l'hardware presenta alcune stranezze inaspettate).

• quanti sforzi di test / debugging ti aspetti senza un tale strumento? Includi i costi per i tuoi addetti al laboratorio perché devi bloccare l'hardware a scopo di test. Includi anche i costi per il tempo in cui il sistema non può essere utilizzato a causa di bug e hai difficoltà a trovare la causa principale.

• quanto costerà l'hardware aggiuntivo per i test?

• quanto tempo pensi di dover bloccare l'hardware a scopo di test?

Certo, la realtà potrebbe non essere così semplice, e ci sono molte variabili sconosciute in questa equazione, ma prova a fare delle stime e dove non sei sicuro, chiedi ad altre persone del tuo ambiente.

Presenta i risultati alla tua direzione, discuti delle alternative e poi lascia che decidano.