Gestione della comunicazione cross-thread per problemi / segnalazioni di errori

Naviga le tue risposte
4

Nel mio progetto attuale abbiamo due o tre ingegneri che sono contrassegnati come supporto Tier 2 o Tier 3. Lavoriamo spesso direttamente con i clienti per raccogliere informazioni dettagliate sui rapporti relativi a bug e problemi.

Spesso riceviamo cross-talk nei thread e nelle conversazioni via email relativi ai problemi. Mentre discutiamo sul numero 1, qualcuno dice "Oh dal modo in cui abbiamo trovato il numero 2". O avendo risolto il problema numero 1, ci viene chiesto "Grazie per averlo risolto. Dove ti trovi con il numero 3".

Lo trovo incredibilmente fastidioso e può rendere complicato svelare i thread quando si rivede la cronologia di una segnalazione di bug perché i thread sono tutti mescolati.

Qualcuno può suggerire qualche strategia per gestire questa comunicazione? C'è un modo educato per affrontare questo e mantenere le singole attività focalizzate? C'è uno svantaggio per un focus su un singolo problema?

    
posta Freiheit 04.10.2011 - 15:27
fonte

2 risposte

2

Il mio suggerimento è semplicemente di smettere di usare la posta elettronica per comunicare sui difetti.

Una volta segnalato un difetto, da parte di un cliente / utente o da un team di test interno, dovrebbe essere inserito in uno strumento di tracciamento dei bug di qualche tipo. Da quel momento in poi, tutte le discussioni riguardanti il bug vengono eseguite solo attraverso lo strumento di tracciamento dei bug. Una volta inserito, è prioritario e assegnato in base al tuo processo interno.

Non sono sicuro di quali strumenti utilizzi, ma ho utilizzato sia Trac che ClearQuest per il rilevamento dei problemi, ed entrambi supportano le notifiche e-mail di modifiche ai problemi, che consentirebbero alle persone di seguire i difetti a cui sono interessati (da prodotto, per gravità, o perché sono coinvolti nel trovarli e ripararli) come sono cambiati.

    
risposta data 04.10.2011 - 16:17
fonte
5

È necessario uno strumento per il monitoraggio dei bug: link

Questo articolo spiega praticamente tutto così ti lascio leggere. In pratica, ti aiuterà a ottenere buoni bug bug e a seguirli durante l'intera durata dello sviluppo della correzione.

Un vantaggio è quello di aggiungere unittest per evitare la regressione in futuro. Ma questo è fuori tema qui.

    
risposta data 04.10.2011 - 15:34
fonte

Leggi altre domande sui tag

È possibile sviluppare un'applicazione sia per la metropolitana che per lo stile classico? Le migliori risorse per comprendere davvero la complessità del runtime [chiuso]