Dato che il revisore non fa parte del progetto, ma è stato assegnato alla revisione perché ha eseguito alcune codifiche per l'applicazione che è stata aggiornata / migliorata.
È compito del revisore assicurarsi che il requisito sia completo e corretto? O è questa la responsabilità del controllo qualità e del business test?
Se lo sviluppatore e il revisore non rispettano un requisito scoperto in UAT, anche il revisore è in errore (probabilmente in misura minore)?
Ovviamente dipende dal tuo processo di revisione del codice ma personalmente direi che la completezza funzionale del requisito è più all'interno del mandato del team di controllo qualità che del revisore del codice.
Questo non vuol dire che un revisore del codice non dovrebbe essere in grado di cogliere problemi con la funzionalità in cui li trova (supponendo che abbiano le conoscenze per identificarli), solo che non è il loro obiettivo primario.
Normalmente vedo la revisione del codice come un tentativo di scoprire errori di codifica e inefficienze, vulnerabilità, perdite di memoria, che non sta controllando che ciò che è stato implementato sia corretto rispetto alle specifiche, ma che sia "corretto" dentro di sé.
Se desideri estenderlo oltre a includere più di una revisione funzionale, devi accettare che ciò avrà un impatto sul tempo necessario per il commit. Se vuoi che il revisore abbia piena familiarità con i requisiti funzionali e che li controlli, devi ovviamente dedicare molto più tempo alla lettura e alla comprensione dei requisiti e alla verifica del codice nei loro confronti.
Ma non dovrebbe essere visto come un sostituto del QA e dei test corretti, al massimo questo sarebbe un ulteriore livello.
In senso lato:
Se il revisore individua qualche problema, deve sicuramente menzionarlo (specialmente se è lo SME).
Ma quando ricevo il codice che deve essere rivisto, mi concentro sul livello della funzione. Vedo che il mio compito principale come revisore è di assicurarsi che il codice sia leggibile e mantenibile in futuro (se trovo bug li indicherò ma non scriverò test di unità (anche se io individuare i test unitari mancanti, lo indicherò)).
La manutenibilità copre molto terreno. Alcune delle cose che cerco sono: lo stile (anche se qualsiasi cosa sottolineo con stile sono suggerimenti e non ho bisogno che vengano corretti). Errori evidenti o stili di codifica che possono causare problemi o che renderanno difficile estendere il codice. Algoritmi che sono molto efficienti (e ce n'è uno semplice che conosciamo meglio). Tutto ciò che non è una semplice autodocumentazione che non ha una descrizione di quale sia l'obiettivo del codice.
È compito dei test e del controllo qualità assicurarsi che faccia un lavoro sufficiente.
Ciò che cerchi in una revisione del codice dipende da ciò che speri di ottenere e da cosa tipo di revisione del codice che stai conducendo . Alcune revisioni del codice si concentrano sulla sicurezza e alla ricerca di vulnerabilità, altre guardano allo stile e alla conformità alle linee guida di codifica, mentre altre sono solo un controllo di integrità per il codice. In genere, viene detto al revisore (per linee guida o sotto forma di elenco di controllo) quali tipi di problemi la revisione del codice sta cercando, quindi la loro attenzione può essere focalizzata su sezioni critiche.
Se sei preoccupato per l'alta qualità, probabilmente vorrai introdurre recensioni in ogni fase. Le revisioni dei requisiti possono essere utilizzate per garantire la completezza e la comprensibilità dei requisiti. Le revisioni dei progetti vengono utilizzate per garantire che tutti i requisiti siano affrontati dall'architettura e dal design del sistema. Le revisioni del codice possono essere utilizzate per garantire che il codice corrisponda al design e non contenga errori prima del test, nonché per verificare la forza dei casi di test.
Quando si tratta di garantire che i requisiti siano correttamente implementati, è responsabilità di tutti, dal tecnico dei requisiti documentarlo all'architetto e agli sviluppatori per comprenderlo, progettarlo e implementarlo ai tester che scrivono casi di test e test procedure. Se qualcuno identifica un'ambiguità, requisiti in conflitto o alcuni aspetti del sistema che non soddisfano un requisito specificato, l'individuo deve documentarlo e in qualche modo segnalarlo (di solito segnalando un difetto nel bug tracker).
Is it the reviewer's job to ensure that the requirement is complete and correct? Or is this the QA and business tester's responsibility?
È responsabilità del QA ( garanzia della qualità del software ) garantire che il requisito sia completo e corretto. Chiunque sia assegnato a farlo indossa il cappello del tester indipendentemente da quanto sia grande il suo distintivo dello sviluppatore .
Tutto si riduce a ciò che TU vuoi che faccia. Ma in generale, penso che la revisione del codice sia una funzione molto specifica. Lui è lì per verificare il codice. Assicurati che il codice sia conforme agli standard e scritto in modo ottimale. Se fai in modo che il tuo revisore del codice faccia la stessa cosa che faresti il tuo Q & A persone, allora farai il doppio del lavoro per raddoppiare il tempo e gli stessi risultati. Che spesso non è necessario.
Questo diventa più critico quando si hanno diversi progetti. Non puoi fare in modo che 1 revisore spenda troppo tempo in un progetto, perché Q & A è in attesa di testarlo e tu ritardi l'intero processo.
Ecco perché le funzioni devono essere chiaramente definite, in modo da non duplicare il lavoro.
Sarò d'accordo con la risposta di Jon Hopkins che una revisione del codice dovrebbe riguardare principalmente il codice, non i requisiti.
Tuttavia, se in qualche modo l'architettura di base, il design o gli algoritmi del codice in esame semplicemente non sono in grado di soddisfare i requisiti di base o le specifiche, o sono altamente non ottimali per tali, potrebbe essere necessario indicarlo all'inizio del rivedere così tanto tempo non è sprecato andando in un vicolo cieco.
Leggi altre domande sui tag testing code-reviews qa
