È un programmatore che le correzioni dei bug di "controllo qualità" e i bug generati dai tester hanno un ruolo riconosciuto?

In quasi tutti i luoghi in cui ho lavorato, queste responsabilità ricadono sull'ingegnere responsabile della correzione del difetto e il responsabile della qualità incaricato di accertarsi che il difetto sia stato effettivamente corretto e che il sistema funzioni ancora come previsto .

Quando viene segnalato un problema (da chiunque - un altro ingegnere, qualcuno in qualità o dopo una distribuzione), viene assegnato a un ingegnere per l'indagine e la risoluzione. Questa persona è responsabile non solo dello sviluppo della soluzione, ma del tracciamento dai requisiti attraverso l'implementazione e di eventuali test automatici associati per effettuare la determinazione appropriata. Questo ingegnere dovrebbe assicurarsi che il difetto sia effettivamente un difetto e non un errore dell'utente, quindi apportare gli aggiornamenti appropriati ad alcuni prodotti di lavoro per risolvere il problema. Dopo la correzione, se ci fosse stata una modifica all'implementazione, mi aspetto che l'ingegnere esegua la modifica per eseguire almeno una serie di test di base per assicurarsi che la loro correzione non abbia introdotto altri problemi nel sistema.

Dopo che un ingegnere ha finito di sistemare il sistema, mi aspetterei che qualcuno dalla garanzia della qualità verificasse che il difetto è stato effettivamente risolto e chiude il difetto. Mi aspetto inoltre che eseguano altri test sul sistema per garantire che non siano stati iniettati altri difetti. Questi sarebbero probabilmente più completi o rigorosi rispetto ai test eseguiti da un ingegnere. Se sono stati rilevati difetti, questi verranno aggiunti al sistema di tracciamento e il processo ricomincerà.

Mi sembra che iniettare una terza persona in quello che dovrebbe essere un processo a due persone (beh, tecnicamente un processo di tre persone, dal momento che c'è probabilmente qualcuno che prende in considerazione le segnalazioni di problemi, le dà la priorità e forse le assegna loro ) aggiunge solo un overhead. Il processo di indagine per correggere un difetto è cruciale per fornire effettivamente una buona soluzione per qualsiasi problema, oltre a mantenere (o migliorare) una comprensione del sistema. Tranne che nei sistemi più banali, non vedo come ci si possa aspettare che una persona scriva codice senza una buona comprensione di quali altri moduli o sottosistemi con il loro codice sta interagendo. Fa anche parte della responsabilità professionale garantire in un certo senso la qualità del proprio lavoro.

Questi sono due ruoli. Entrambi i ruoli appartengono alla gestione del controllo delle modifiche del software.

Il ruolo che pre-verifica le richieste di modifica è chiamato triage. Questo ruolo classifica ogni richiesta come difetti o miglioramenti, si correla con richieste simili, assegna priorità (o respinge richieste a bassa priorità)

Il ruolo che rivede le modifiche al codice di manutenzione è la revisione del codice.

Questa persona è un revisore e probabilmente un leader nel loro ambiente. Sul termine "fixing", stai parlando di code-review-on-stero. I tuoi migliori programmatori dovrebbero svolgere questo compito e il loro consiglio dovrebbe essere considerato come la regola d'oro dei loro pari. Alla fine del "test", stai parlando del triage dei difetti e dell'analisi delle tendenze. Solo chi ha una profonda conoscenza del tuo sistema può farlo bene, e le loro opinioni dovrebbero essere rispettate sia dai tester che dai programmatori.

Naturalmente, nel mondo reale, questo lavoro di scout viene distribuito ai livelli inferiori se fatto. Altro è il peccato.

Ci sono due titoli che funzionano per questa posizione a seconda delle circostanze:

Programmatore dei mentori:

Con un nuovo dipendente che sta imparando le corde del tuo sistema, questa può essere una posizione molto preziosa. Ti dà la possibilità di istruire sul codice specifico, sul sistema nel suo insieme, sul software di segnalazione dei bug e su qualsiasi regola scritta (e non scritta) per lavorare con il team di QA. Come con qualsiasi nuovo dipendente, vuoi essere molto pratico all'inizio e poi tornare indietro dopo aver sentito qualcosa una o due volte e dargli la possibilità di farlo da soli.

Programmatore Nosy:

Penso che siamo tutti colpevoli di questo in un modo o nell'altro, forse è lento e hai bisogno di qualcosa in più o forse stai lavorando a qualcosa di grosso e vuoi solo fare qualcosa di piccolo per una vittoria veloce, ma alla fine stai conficcando il naso negli affari di qualcun altro. Potresti risparmiare tempo a breve termine, ma stai danneggiando la loro produttività generale privandoli della possibilità di imparare dai loro errori. Sembrerà anche che non ti fidi del controllo qualità o del programmatore per eseguire correttamente il lavoro.

Ho lavorato come Support Programmer , un possibile terzo titolo, ma faceva rigorosamente correzioni di bug dopo l'implementazione insieme a interfacce di terze parti, prodotti aggiuntivi e tutto ciò che non adattarsi perfettamente al programma di sviluppo della release principale. Sono stato davvero bravo a imparare dagli errori di altre persone e ho imparato quali errori avrebbero dovuto essere ripetutamente determinati programmatori. Hanno commesso quegli errori perché non hanno mai avuto la possibilità di imparare dai propri errori e perché sapevano che avrebbero potuto mandare qualcosa fuori dalla porta e sarebbe stato il problema di qualcun altro se non avesse funzionato correttamente dopo l'implementazione.

Ho usato il lavoro in un ruolo chiamato Defect Coordinator. Ero responsabile per il primo triage dei difetti (ove possibile) quindi quelli che erano chiaramente Non il nostro problema / Non un difetto non finiva nei nostri rapporti settimanali alla direzione, scartando i difetti alla squadra (e inseguendoli per vedere cosa il progresso era), e verificando che le correzioni fossero effettivamente rilasciate. Vorrei precisare che il triage non è stato necessariamente fatto dalla persona che finisce per correggere il difetto; dipendeva davvero dalla complessità del difetto. Conosco questo ruolo come gestore degli errori in altre organizzazioni.

Per quanto riguarda la revisione delle correzioni, ciò è dovuto al team. Il fixer sceglieva due o tre persone rilevanti nel team che potevano fornire un feedback adeguato sul cambiamento. Abbiamo utilizzato Code Collaborator per la revisione e un link alla recensione sarebbe stato incluso nel rapporto del difetto per dimostrare che era stato fatto. La correzione non sarebbe stata approvata per la presentazione fino a quando i revisori non fossero tutti soddisfatti della correzione. Anche l'analisi delle cause di root è stata parte del processo, ma ho scoperto che la gestione superiore non ha fatto assolutamente nulla con queste informazioni.