Come analizzare uno scenario in cui un bug non è stato scoperto e regolare il flusso di lavoro di sviluppo per evitare errori simili

@ Il commento di RobertHarvey è perfetto: il processo non produrrà software privo di bug, ma un buon processo può almeno ridurre la ricorrenza di classi di bug. Sembra che tu stia tentando di raggiungere quest'ultimo, quindi farò il mio suggerimento su dove penso sia arrivato il tuo errore:

Non hai tenuto conto di tutti i dettagli del tuo ambiente di produzione nei test. I test dovrebbero essere eseguiti in un ambiente che simuli il più possibile la produzione. Nel tuo caso, hai perso il fatto che la produzione si concentra nel tempo in UTC mentre i tuoi test unitari erano in esecuzione con un fuso orario diverso.

Andando avanti, siate consapevoli del modo in cui il vostro ambiente di produzione è configurato e di come funziona nel maggior numero possibile di dettagli. Ogni volta che vai a scrivere dei test unitari, cerca le cose che possono variare per effettuare i test delle tue unità il più possibile, e cerca di far corrispondere quelle varianze con ciò che accade nella produzione.

Quel piccolo accorgimento quando scrivi i tuoi test unitari può aiutarti ad andare avanti in altri modi in cui i tuoi test non funzionano allo stesso modo della produzione. Scrivilo in una lista di controllo se usi quelle, in entrambi i casi cerca di essere consapevole di ciò quando scrivi i tuoi test.

Il processo non ti impedirà di finire con altri bug, anche quelli relativi a questo, ma con quella consapevolezza che va avanti speriamo che la classe di bug noti come "cose che falliscono nella produzione ma non in sviluppo" saranno ridotte in modo significativo .

Una cosa che potrebbe mancare è comune, è un documento che dettaglia il sistema che ha specifiche su tutte le cose che variano. Su quale fuso orario viene eseguito, su quali versioni dei linguaggi è scritto, a 64 bit oa 32 bit, tutte queste cose influenzano il comportamento del sistema. Averli documentati può aiutare una squadra a sapere molto di più sul sistema di quanto non facciano individualmente. Un singolo sviluppatore spesso conosce solo sottosezioni del sistema e potrebbe non essere a conoscenza di questi dettagli sistemici più grandi che li influenzano in modi altrimenti inconsapevoli.

1. Dove è stato interrotto il mio flusso di lavoro?

   • Dove i tuoi test hanno tentato di imitare la produzione

2. Quali modifiche posso apportare al mio flusso di lavoro per prevenire meglio questo tipo di errore in futuro?

   • Documenta o rendi conto di tali scostamenti tra gli ambienti di sviluppo e di produzione.

3. Come posso risolvere in modo più efficace un problema quando c'è un problema nella produzione ma non nei test?

   • Isolare le variabili che possono differire da sistema a sistema e controllarle tra gli ambienti di sviluppo e di produzione. Se vuoi impararlo, usare un debugger che può fare un dump della memoria e permettere di analizzare lo stato dei processi live può spesso aiutare in questo caso, anche se l'apprendimento è lontano da un'impresa non significativa.

Oltre alla risposta di Jimmy Hoffa: Tu chiedi a wide net su tutti i tipi di bug, ma il tuo esempio è un po 'più stretto: Per quanto posso vedere dal tuo esempio, ti sei imbattuto in un punto debole dell'applicazione in quanto non si adatta bene alla localizzazione. Questa è una grande area in cui possono insorgere bug sottili ed è molto ampia. Le differenze e le supposizioni locali su quelle possono darti grattacapi. Alcuni esempi:

• La domenica è il primo giorno della settimana negli Stati Uniti, il lunedì in Europa.
• Mese prima del giorno negli Stati Uniti rispetto al giorno prima del mese in Europa.
• Ma anche usando "," o "." quando si usano valori diversi.

Quindi la mia risposta sarebbe:

1) Dove è stato interrotto il mio flusso di lavoro?

Si è interrotto perché non hai tenuto conto della localizzazione.

2) Quali modifiche posso apportare al mio flusso di lavoro per prevenire meglio questo tipo di errore nel futuro?

Scopri la localizzazione e controlla l'intera applicazione per i problemi di localizzazione.

Altro da aggiungere ad entrambi: sebbene il processo non possa garantire un'applicazione priva di bug, nessuno dei due può coprire il 100% del codice mediante test unitari.
Infatti, avere questo può facilmente portare ad un falso senso di sicurezza, non si sarebbe la prima squadra cullati dal compiacimento dall'idea che "abbiamo una copertura del 100% del codice, ora il nostro sistema deve essere privo di bug". > Non solo ci possono essere bug negli unit test, nascondendo bug nel software, ma i test unitari non testano se parti dell'applicazione funzionano insieme come previsto. Se si dispone di un client di servizio Web e di un servizio Web, entrambe le unità sono state testate, ma rispetto a specifiche diverse (ad esempio, le specifiche sono cambiate dopo che il servizio è stato scritto, il client è stato scritto su un WSDL diverso da quello implementato dal servizio). non ti avviserò mai di questo.

Avrete anche bisogno di test di integrazione, test di regressione, test funzionali (il sistema implementa effettivamente le funzionalità richieste, se non può essere tecnicamente corretto ma è ancora inutile), test di usabilità (se funziona, ma è così kludgy gli utenti non lo usano o non lo usano come previsto, è comunque un sistema inutile). Tutti sono necessari, tutti hanno il loro posto, né è di per sé una garanzia che il sistema funzioni correttamente.

E naturalmente tutti dipendono da documenti di progettazione funzionale ben scritti, ben dettagliati e ben verificati e firmati, tradotti in documenti di progettazione tecnica corretti.