Il tempo del tester deve essere incluso nella stima dei biglietti?


17

Quando si creano stime del tempo per i biglietti, il tempo impiegato per i tester (QA) dovrebbe essere incluso in un preventivo dei biglietti? In precedenza abbiamo sempre stimato senza il tempo dei tester, ma stiamo parlando di includerlo sempre. Ha senso per il nostro attuale sprint, l'ultimo prima di un rilascio, in quanto dobbiamo sapere il tempo totale che i biglietti impiegheranno con una settimana per andare.

Ho sempre capito che la stima era solo per il tempo degli sviluppatori in quanto tende a essere la risorsa limitante nei team. Un collega sta dicendo che è stato incluso anche ovunque abbiano lavorato prima che il tempo del tester.

Per essere chiari, questo è per un processo in cui gli sviluppatori stanno scrivendo test di unità, integrazione e UI con una buona copertura.


Che dire del tempo per le correzioni di errori dovute a problemi rilevati dal tester? È una cosa davvero difficile da stimare :).
Frank Puffer,

3
Il test fa parte della tua definizione di fatto, o stiamo parlando di un intero altro team / dipartimento?
nvoigt,

2
È perfettamente possibile che lo sforzo del tester sia la stragrande maggioranza del tempo speso per un "biglietto". Quindi, IMO; sì.
Grimm The Opiner,

@nvoigt Testing fa parte della nostra definizione di done.
Trasmessa il

Risposte:


33

Il mio consiglio: includere il tempo di test nel ticket o aggiungere un ticket per rappresentare l'attività di test stessa. Qualsiasi altro approccio ti porta a sottovalutare il vero lavoro necessario.

Mentre il tempo degli sviluppatori è spesso un collo di bottiglia, nella mia esperienza, ci sono molti team vincolati ai test. Supponendo che la risorsa limitante sia l'uno o l'altro senza prove, può morderti.

Come collega, non ho visto un'organizzazione di successo che non tenga conto del tempo di prova.

Addendum per il tuo chiarimento: anche se gli sviluppatori scrivono test automatizzati, in particolare i test unitari (i test di integrazione fanno meglio), non sono sufficienti per testare correttamente.

Se sono coinvolte persone con QA, il loro tempo deve essere stimato, in un modo o nell'altro. Solo se stai decidendo di rimuovere gli addetti al controllo qualità dal libro paga, il loro tempo di lavoro è effettivamente svanito e puoi rimuoverlo dalla stima. Ma questo avrebbe effetti collaterali che sono facili da ignorare. E potresti ancora mancare test di prestazioni, stress, sicurezza e accettazione.


6
La posizione del collo di bottiglia dipende dalla società. A mio avviso, abbiamo 8 sviluppatori che alimentano una risorsa QA. Il QA è ovviamente il collo di bottiglia
Marshall Tigerus,

2
Sono d'accordo che l'aggiunta di un biglietto per i test è una buona opzione qui. Sembra che OP non abbia alcun controllo sul QA ed è fatto da un team separato. Se trovano qualcosa di sbagliato, questo potrebbe essere considerato un bug e un nuovo ticket creato per la correzione / modifica.
Mi fa male la testa il

@MarshallTigerus: Penso che in genere sia più facile coordinare le persone necessarie per fornire QA agli sviluppatori N (il numero esatto dipende dal prodotto), piuttosto che coordinare N sviluppatori. Quindi, in un certo senso, il QA "non dovrebbe" essere il collo di bottiglia, dovresti "assumere un altro QA (e licenziare uno sviluppatore per rendere disponibile lo stipendio e lo spazio sulla scrivania, ma speriamo che non arrivi a quello). Ovviamente non tutto è sempre come dovrebbe essere.
Steve Jessop,

1
+1 per un altro biglietto, rende molto più facile sapere dove le cose si bloccano.
Matthieu M.

1
@SteveJessop Molte cose "Dovrebbero" accadere :)
Marshall Tigerus,

19

Enfaticamente

I test fanno parte del processo di sviluppo. Se il tuo team effettivamente impiega tempo a testare il software, il tempo impiegato per i test deve essere parte del preventivo.


5

Se questo è agile, includerei lo sforzo di test come parte dei punti della trama totale. Ad esempio, lo sforzo di sviluppo può essere di 1 giorno e il test di 1 giorno in modo che sia una storia a 2 punti.

Dipende da quale sia la tua definizione di fatto, ma di solito il suo sviluppo è completo, l'accettazione da parte degli affari e i test approvano nell'iterazione. Se il DoD è solo un'accettazione aziendale, non è necessario includere gli sforzi di test nei punti della storia, ma devono comunque essere monitorati.


2

Il preventivo dovrebbe tenere conto di tutto il lavoro necessario per completare il biglietto. Se il test è una parte obbligatoria del ticket, è necessario includerlo nel preventivo. Se il test è un ticket separato, non dovrebbe esserlo.

Questo ovviamente può diventare tutto sfocato quando inizi a usare i punti trama, poiché la differenza tra un dev-only 5 e un dev-only 8 sarà abbastanza proporzionale a un dev-and-QA 5 rispetto a un dev-and-QA 8.

Ho visto includendo il lavoro del tempo del tester. Ho visto storie separate funzionare. Ho visto compiti separati, ciascuno stimato dal gruppo che li faceva funzionare. Fai ciò che ha senso per te, dopo tutto il processo è lì per servirti, non viceversa.


2

Il fatto che tu non possa rispondere a questo suggerisce fortemente che non sai perché stai scrivendo stime (o almeno che non sei d'accordo con il tuo collega perché stai scrivendo stime). Questo è un problema più grande che se le stime dovrebbero o meno includere test.

Scopri o raggiungi un accordo, perché stai scrivendo stime. Se si tratta di prevedere ciò che un determinato team raggiungerà in un determinato momento, la risposta dipende semplicemente dal fatto che quel team, quello che si sta valutando, esegua i test o meno. Se il tuo team di controllo qualità è separato e ha una propria pianificazione, potrebbero essere interessati a sapere quanto tempo di test tu (gli sviluppatori) ritieni necessario da loro su un determinato biglietto. Potrebbero ignorare i tuoi numeri e inserirne i propri. In entrambi i casi possono seguirlo separatamente dalle stime del tempo di sviluppo.

D'altra parte, se una squadra sta facendo tutto lo sviluppo, i test e il QA, e lo scopo delle stime temporali è prevedere e pianificare ciò che quella squadra sta facendo in un determinato intervallo di tempo, ovviamente le stime temporali devono includere QA, insieme a qualsiasi altra attività che è necessario per quella squadra per raggiungere l'obiettivo dichiarato. Del resto, se devi tenere una riunione preliminare per ogni biglietto, o compilare un po 'di scartoffie al completamento, allora il tempo per l'amministratore deve essere lì da qualche parte . Non puoi semplicemente ignorarlo.

Se è tutto un team ma con ruoli separati "sviluppatori" e "tester", ciò potrebbe significare che hai molti ticket su cui solo un lato della divisione è in grado di lavorare e il tuo (forse ipotetico del tutto) diagramma di Gantt esattamente come sarebbe il grafico per due squadre separate. Questo fatto sconvolgerà alcune metodologie più di altre, e potresti essere meglio a dividere la pianificazione a causa di ciò, ma se non la dividi allora devi ticket e stimare tutto ciò che il team deve fare o le tue previsioni saranno senza speranza .

Se lo scopo delle stime è diverso dalla previsione e dalla pianificazione, ad esempio "perché seguiamo insensatamente un rituale vuoto che li include", o "perché la direzione li usa come un bastone per batterci per farci fuori gli straordinari", o "perché dobbiamo fare un'offerta a prezzo fisso e i numeri vanno in una formula enorme" (grazie John Wu), allora potrebbe essere più difficile capire cosa dovrebbero includere ;-)


1

Stimare sempre tutto il lavoro che deve essere fatto per rendere davvero user-story / funzionalità / ticket. Lo chiamiamo Fatto .

Abbiamo finito quando siamo pronti per la produzione .

Ciò include qualsiasi test manuale ed esplorativo, ma anche test di accettazione da parte dell'utente.

Un team Agile dovrebbe essere in grado di rilasciare una nuova parte del lavoro finito in qualsiasi momento. Come:

Il software di lavoro è la misura principale del progresso.

Come fai a sapere se funziona, se non l'hai ancora testato? Ora scrivi che il tempo di sviluppo è il collo di bottiglia del tuo tempo. Come ingegnere addetto al controllo qualità, penso che la maggior parte dei team abbia il collo di bottiglia nella capacità di test o che stiano semplicemente prendendo scorciatoie.

Per farla breve, stimare anche lo sforzo di test. Tieni presente che ciò potrebbe influenzare la tua velocità . Se hai fatto stime relative nei punti della trama, i test potrebbero essere già incorporati nella tua velocità media.


1

Ecco qualcosa di molto importante: tutte le stime dovrebbero essere accompagnate da ipotesi ed esclusioni .

Ciò include la specifica di cosa è incluso: solo sviluppo, progettazione e sviluppo, test di sviluppo e unità, copertura per test di collaudo, costruzione di infrastrutture, ecc.

Se si sta fornendo un documento di stima a un project manager, questi lo convertiranno in un ordine di lavoro o in una dichiarazione di lavoro per un cliente o (se un progetto interno) per il PMO . Essi possono avere formule set per l'aggiunta di spese generali (per esempio, alcuni progetti possono aggiungere X% per coprire QA, quindi aggiungere Y% alla governance di copertura e gestione del progetto) impostati per contratto o insieme con l'esperienza. E non vuoi raddoppiare il conteggio. D'altra parte, potrebbero non aggiungerli automaticamente.

Le pratiche differiscono. Chiunque stia usando questi numeri dovrà sapere cosa significano i numeri e dovresti essere esplicito se stai includendo il tempo del test o meno.


1

Il tempo dovrebbe essere incluso nel preventivo ma non si dovrebbe stimare il tempo dei tester, invece i tester dovrebbero stimare il loro tempo .

Non includere il tempo di test è una falsa stima del tempo totale necessario, ma il tempo dello sviluppatore e il tempo del tester non sono intercambiabili (anche perché presumibilmente si lavora in parallelo, con i tester dietro un'iterazione), quindi è necessario stimarli separatamente. Inoltre, non sei in grado di stimare i time tester che dovranno testare eventuali modifiche, solo lo stesso team di test dovrebbe farlo.


1
Dato che che è il si che attraverso il biglietto, e che il tempo di prova dovrebbe essere incluso, quindi il dev dovrebbero includere un 'stima ipotetica' per testare, per la raffinatezza più tardi. È facile creare un buco nero con stima 22 con determinate regole ... Questi buchi si verificano in molte attività di compilazione di moduli.
Philip Oakley,

0

incapsulamento

Ho intenzione di affrontarlo da un punto di vista dello sviluppo del software e del linguaggio.

  • Sei un piccolo ingranaggio in una grande macchina.
  • Dall'esterno del tuo team, il tuo sistema di ticketing funge da interfaccia / API per il tuo team
  • Gli utenti aziendali che utilizzano il sistema di ticketing non sono sviluppatori

Da una buona progettazione del software, è necessario semplificare e incapsulare il più possibile.

Quindi, per guardare il processo dal punto di vista degli Utenti Business, a loro interessano solo 2 cose.

  1. Quanto costerà?
  2. Abbiamo ancora finito?

Consentire all'utente aziendale di conoscere il processo interno del proprio team è una cattiva gestione; simile a dare publicaccesso allo stato interno.

La mancata protezione dello stato interno del tuo team sta invitando altri team a gestire le tue risorse e rovinare il tuo stato interno.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.