I tester dovrebbero approvare i comunicati o semplicemente riferire sui test?

La maggior parte dei posti in cui ho lavorato con il personale di controllo qualità hanno una sorta di passaggio di approvazione, ma non hanno l'autorizzazione finale se il rilascio procede o meno. La loro firma indica che hanno completato il test previsto dal piano di rilascio, non che il rilascio è impeccabile.

In fin dei conti QA! = l'azienda e l'azienda devono decidere se sono disposti a implementare il codice nello stato attuale o se i benefici superano il lato negativo o altro. Questo viene spesso fatto dai clienti o dalle parti interessate immediatamente prima della distribuzione e viene spesso chiamato Accettazione dell'utente.

Se il tuo QA è anche il tuo gruppo di accettazione degli utenti, esiste la possibilità che abbiano l'autorità per definire inaccettabile il tuo candidato per il rilascio, ma se lo stai facendo su problemi che non rientrano nell'ambito della correzione / iterazione / sprint / richiesta di modifica / qualunque sia il tuo tempo, allora il Project Manager o gli stakeholder della business line devono venire a incontrare Gesù con il team di QA.

Va bene riportare difetti preesistenti o esiti involontari di nuovi requisiti, ma se è fuori ambito e non disastroso, generalmente non è accettabile etichettarlo come un problema di blocco. Va nel backlog per il proprietario del prodotto per dare la priorità come tutto il resto.

Someobody ha bisogno di quell'autorità . Che si tratti di un tester, il team di tester, il leader del team di tester o il leader dell'organizzazione di sviluppo è in qualche modo irrilevante. O forse più esattamente, dipende dall'organizzazione.

In definitiva, la scelta di rilasciare il software è una funzione aziendale. L'azienda deve decidere se la qualità è appropriata. Probabilmente, il direttore dell'assicurazione della qualità dovrebbe prendere quella decisione, o alimentare quella decisione alla business unit appropriata. Tutto dipende dalle dimensioni dell'azienda, dall'importanza relativa della qualità, ecc.

Tutto ciò che viene detto, le informazioni utilizzate per prendere la decisione iniziano con il tester . Se hanno il potere di interrompere o meno un rilascio, dovrebbero sentire la responsabilità di informare i responsabili delle decisioni quando vedono qualcosa che secondo loro dovrebbe causare un ritardo nel rilascio.

Assegnare all'autorità di disconnessione (vale a dire il diritto di veto) per i rilasci ai tester ha lo stesso senso che attribuire tale diritto agli sviluppatori: nessuno affatto.

I tester e gli sviluppatori sono principalmente persone tecniche, quindi è probabile che prenderanno le loro decisioni per lo più per motivi tecnici. Ma le preoccupazioni che devono essere soppesate quando si rilasciano sono preoccupazioni sia tecniche che economiche. Ovviamente, il cliente non sarà felice se fornirai un prodotto bug-driven, ma il cliente sarà ugualmente infelice se continui a posticipare un rilascio perché ci sono ancora problemi aperti sul prodotto.

Qualcuno deve trovare il giusto equilibrio tra un buon prodotto e rispettare il programma che è stato promesso al cliente. Per farlo, dovresti non essere coinvolto nel progetto in un ruolo puramente tecnico, ma piuttosto in un ruolo più orientato al business / gestione come project manager o product owner e prendere il tuo input dai tester e dai gli sviluppatori.

La decisione di "rilasciare" o "non rilasciare" è una decisione aziendale alla fine della quale è necessario eseguire un'analisi rigorosa di rischio / rendimento.

Per qualsiasi organizzazione è folle chiedere al team di test di assumersi questa responsabilità o al team di test di accettare questa responsabilità.

Il ruolo del team di test è quello di fornire un'analisi della qualità del software, la sua disponibilità a essere rilasciata e qualsiasi rischio identificato come input alla decisione aziendale di rilasciare o non rilasciare.

Come altri hanno notato, _ qualcuno _ (e credo che sia un individuo) ha bisogno dell'autorità per prendere la decisione "rilascio" o "non rilasciare". Quella stessa persona può aver delegato tale decisione in condizioni specifiche (cioè senza errori P1 o P2)

Ho lavorato con la stessa situazione in cui i tester raggiungono e inventano modi sempre più creativi per rompere un sistema che, quando viene valutato il rischio, è incredibilmente improbabile che accada mai nella produzione.

Pur comprendendo e elogiando il team di test per non voler inviare la versione imperfetta, è necessario disporre di una strong proprietà del prodotto per definire ciò che è un "rischio accettabile".

Secondo la mia esperienza, il team di test dovrebbe avere il diritto di veto sul rilascio di software, ma questo veto dovrebbe essere sostituibile dal proprietario del prodotto, ma solo dopo aver discusso con i principali tester.

Il software non sarà mai perfetto, se si soffre di creep test non si otterrà mai nulla rilasciato fino a quando non si verificherà un grosso problema di produzione (che non verrà testato correttamente) e si esaurirà.