I tester dovrebbero approvare le versioni o semplicemente riferire sui test?

20

Ha senso dare l'autorizzazione alla firma ai tester? Dovrebbe un team di test

Basta testare funzionalità, problemi, ecc. E riferire semplicemente in base al pass / fail, lasciando ad altri la possibilità di agire su tali risultati, oppure
Hanno l'autorità di trattenere le pubblicazioni stesse sulla base di tali risultati?

In altre parole, i tester dovrebbero essere tenuti a firmare effettivamente sulle versioni? Il team di test con cui sto lavorando ritiene che lo facciano e stiamo riscontrando un problema a causa del "creep dell'ambito del test": il rifiuto di approvare le versioni a volte si basa su problemi esplicitamente non risolti dalla versione in questione.

testing release-management process

— Ernest Friedman-Hill
fonte

2

Ti preghiamo di riformulare la tua domanda in modo che non sia un sondaggio. Qual è il problema che stai cercando di risolvere?

— M. Dudley,

5

"dovrebbe" dipende in gran parte dalla struttura organizzativa dell'azienda. Se vengono misurati su bug trovati in produzione, essere in grado di trattenere un rilascio difettoso è uno strumento essenziale.

Ottimo punto, @MichaelT. Nella mia organizzazione, il testing è un ruolo piuttosto che una descrizione del lavoro e la valutazione è più ad hoc e per nulla quantitativa. Le distribuzioni riuscite porterebbero a recensioni positive, ma i bug nella produzione non sarebbero negativi specifici, non più che per chiunque altro nel team.

— Ernest Friedman-Hill

5

Se hai problemi con i tester che rifiutano di approvare rilasci basati su problemi non pianificati per essere affrontati, allora hai problemi di comunicazione (non sanno che i problemi non sono pianificati per essere affrontati) o problemi delle persone (si stanno rendendo importanti; se rilasciare è in definitiva una decisione commerciale).

— Jan Hudec,

27

La maggior parte dei posti in cui ho lavorato, le persone addette al 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 i test previsti dal piano di rilascio, non che il rilascio sia impeccabile.

In definitiva QA! = Il business e il business devono decidere se sono d'accordo con la distribuzione del codice nello stato attuale o se il vantaggio supera il rovescio della medaglia o altro. Ciò viene spesso eseguito da clienti o parti interessate immediatamente prima della distribuzione e viene spesso chiamato Accettazione utente.

Se il tuo QA è anche il tuo gruppo di accettazione degli utenti, esiste la possibilità che abbiano l'autorità di definire il candidato della release come inaccettabile, ma se lo stai riscontrando su problemi che non rientrano nell'ambito del bugfix / iteration / sprint / change richiesta / qualunque sia il periodo in cui trascorri il tuo tempo, quindi il Project Manager o le parti interessate della linea di business devono venire a Jesus incontrando il team QA.

Va bene riferire su difetti preesistenti o risultati non intenzionali di nuovi requisiti, ma se è fuori campo e non disastroso non è generalmente accettabile etichettarlo come un problema di blocco. Nel backlog il proprietario del prodotto ha la priorità come tutto il resto.

— Conto
fonte

Chi decide se inviti il cliente a eseguire un test di accettazione sulla build 1234 o che non è abbastanza buono per i test di accettazione?

— Bart van Ingen Schenau,

3

@BartvanIngenSchenau: il product owner / project manager deve avere l'ultima parola su questi. Perché anche i test di accettazione spesso si gonfiano se necessario (vuoi ora la funzione X anche se non riusciamo a far sì che Y lavori con essa, o vuoi aspettare altri 2 mesi prima di ripararlo?) E il proprietario del prodotto lo sta negoziando.

— Jan Hudec,

oltre a quello che ha detto Jan, in molte metodologie ci sarebbe programma o cadenza qui. alcune persone distribuiscono tutti i candidati che sopravvivono al test del fumo iniziale su UAT, altri distribuiscono automaticamente qualsiasi cosa nel ramo candidato, altri tutto ciò che viene controllato in principale. idealmente hai mostrato i progressi delle parti interessate mentre vai in qualche modo, quindi alla fine non dovrebbe esserci molta sorpresa. in alcuni di questi casi finisci per mostrare agli stakeholder ciò che le persone addette al controllo qualità ti stanno trascinando attraverso i carboni e dicono solo "chi se ne frega" ed è finita.

— Bill

Nei moderni SaaS con implementazione continua, il ciclo di implementazione del codice (servizio) può essere separato dal ciclo di rilascio delle funzionalità (business). Questo ciclo di rilascio delle funzionalità può essere implementato utilizzando flag o opzioni, ad esempio da alpha (interno) a beta (opt-in) alla disponibilità generale. Questo è un modo per coinvolgere un accordo commerciale più formale separato e indipendentemente dalla implementabilità di un particolare codice o servizio. L'opposto, legando i rilasci di funzionalità alle distribuzioni di servizi, introduce l'accoppiamento e il rischio nel processo che può essere evitato con la tecnica di flag delle caratteristiche.

— Sarà il

@will Non sono in disaccordo, ma qualcuno sta ancora esprimendo il proprio giudizio se quelle funzionalità nascoste sono abbastanza nascoste da non essere notate da utenti diversi dal team beta durante la distribuzione iniziale e alla fine ovunque io abbia usato l'approccio con cui si gioca la sequenza più o meno lo stesso, ma con etichette diverse sulle parti mobili e il rischio si è spostato un po '. Preferisco la situazione che descrivi, ma il team addetto al controllo qualità che trova qualcosa di preesistente o il product manager che decide di procedere comunque è qualcosa di più in questo modello che di qualsiasi altra nelle mie esperienze.

— Bill

6

Qualcuno 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ù precisamente, dipende dall'organizzazione.

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

Detto questo, le informazioni utilizzate per prendere la decisione iniziano con il tester . Indipendentemente dal fatto che abbiano il potere o meno di interrompere un rilascio, dovrebbero sentirsi responsabili di informare i responsabili delle decisioni quando vedono qualcosa che ritengono debba causare un ritardo nel rilascio.

— Bryan Oakley
fonte

6

Concedere l'autorizzazione alla firma (vale a dire un diritto di veto) per i rilasci ai tester ha lo stesso senso che dare quel diritto agli sviluppatori: nessuno.

I tester e gli sviluppatori sono principalmente tecnici, quindi è probabile che prendano le loro decisioni principalmente per motivi tecnici. Tuttavia, le preoccupazioni che devono essere soppesate quando si rilascia un rilascio sono preoccupazioni sia tecniche che commerciali. Ovviamente, il cliente non sarà contento se consegni un prodotto pieno di bug, ma sarà altrettanto 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 promesso al cliente. Per fare questo, si dovrebbe non essere coinvolto nel progetto in un ruolo puramente tecnico, ma piuttosto in un business / gestione orientata al ruolo più come project manager o del proprietario del prodotto e prendere il vostro input dai tester e gli sviluppatori.

— Bart van Ingen Schenau
fonte

1

L'ho votato perché fondamentalmente non sono d'accordo con diversi punti e ipotesi che stai formulando. Non sono d'accordo sul fatto che il QA non dovrebbe avere l'autorità di porre il veto su una versione perché anche molti gruppi di QA operano in un ruolo di accettazione dell'utente. Inoltre, non sono d'accordo con l'ipotesi che i tester siano tecnici. Non sempre, non tutti i gruppi che rilasciano software possono permettersi un team completo di QA, quindi quel ruolo può ricadere su analisti aziendali che potrebbero non essere affatto tecnici.

— maple_shaft

1

oltre al punto di maple_shaft vedo spesso l'ultima chiamata su questa sinistra a chiunque ricopra il ruolo di cliente a meno che non ci sia qualcosa di terribile identificato. è in definitiva la loro consegna e molto probabilmente avranno il giusto punto di vista sul rischio assumendo che tu fornisca loro informazioni accurate.

— Bill

5

La decisione di "rilasciare" o "non rilasciare" è in definitiva una decisione commerciale, in cui è necessario eseguire un'analisi rigorosa rischio / rendimento.

È assurdo che qualsiasi organizzazione chieda al team di test di assumersi questa responsabilità o che il team di test accetti tale responsabilità.

Il ruolo del team di test è quello di fornire un'analisi della qualità del software, della sua disponibilità a essere rilasciata e di tutti i rischi identificati 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 di "liberare" o "non rilasciare". La stessa persona può aver delegato tale decisione a condizioni specifiche (ovvero senza bug P1 o P2)

— Giordania
fonte

3

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

Mentre capisco e lodo il team di test per non voler inviare un rilascio imperfetto, richiede una forte proprietà del prodotto per definire ciò che è un "rischio accettabile".

Nella mia esperienza, il team di test dovrebbe avere il veto sul rilascio del software, ma questo veto dovrebbe essere annullato dal proprietario del prodotto, ma solo dopo una discussione con i lead tester.

Il software non sarà mai perfetto, se si soffre di creep di prova, non si otterrà mai nulla fino a quando non ci sarà un grosso problema di produzione (che non verrà testato correttamente) e si precipiterà fuori.

— Michael
fonte

1

Questo è un vero problema, ma non sono sicuro che sia necessariamente il problema del PO. La mia interpretazione è che in qualche modo i tester stanno interpretando nuovi requisiti che non erano stati originariamente definiti.

— maple_shaft

2

la mia esperienza con i team di test mi ha portato a cadere dall'altra parte di questo. Per me il QA non dovrebbe aspettarsi di essere in grado di bloccare uno schieramento senza fare valere il resto del team o convincere il proprietario a scavalcare il team.

— Bill

1

Vero - probabilmente non ero abbastanza esplicito, gli stessi problemi si verificano quando i tester sollevano difetti, e cito "nel giro della storia" che porta agli stessi problemi - nulla viene mai rilasciato.

— Michael,

Nel mio caso, è più l'interpretazione di @maple_shaft; non tanto essere subdoli nel trovare il modo di rompere il software, quanto riportare l'incapacità di gestire casi esplicitamente non supportati.

— Ernest Friedman-Hill

1

@ ErnestFriedman-Hill Sembra che tu stia descrivendo i requisiti negativi e questi sono ciò che manca ai documenti dei requisiti funzionali. Un requisito negativo è una dichiarazione esplicita su ciò che un sistema NON farà, e può essere accettabile come i requisiti regolari. Se questi vengono dichiarati, i loro casi di test rispetto ai Requisiti negativi non sono validi.

— maple_shaft