Un piano di test solido è ciò che impedisce ai bug di raggiungere la produzione. Con Trupeer, puoi risparmiare ore sulla pianificazione dei test partendo da un modello di piano di test gratuito, personalizzandolo con le tue linee guida del brand e trasformando i piani di test in video-guide dettagliate che allineano i team di ingegneria, prodotto e QA.

Che cos'è un modello di piano di test gratuito?

Un modello di piano di test gratuito è una struttura riutilizzabile per il documento che definisce cosa verrà testato su una specifica release o progetto, in quali ambienti, da chi, secondo quale pianificazione e come si saprà che il testing è terminato.

L'elenco delle sezioni è standard e indiscusso. Ambito, approccio, ambienti, risorse, pianificazione, criteri di ingresso, criteri di uscita, rischi, deliverable. Ogni modello pubblicato lo contiene ed è rimasto sostanzialmente stabile da quando le tradizioni ISO e IEEE lo hanno stabilito decenni fa.

Il modello non è il punto in cui i piani di test falliscono. Falliscono in un momento specifico, mesi dopo l'approvazione del piano, e il fallimento ha sempre lo stesso andamento.

Il formato segue l'uso. Un modello di piano di test gratuito in formato Word si adatta al piano stesso, che è un testo in prosa che viene revisionato e approvato; per una piccola release è sufficiente un layout semplice di una o due pagine. Un modello di piano di test gratuito in versione Excel si adatta alla pianificazione, alla matrice di copertura e alle risorse. Un modello di piano di test gratuito in formato PDF è la copia approvata allegata al registro della release, e un esempio di documento di piano di test in PDF proveniente da una fonte pubblicata è il modo migliore per vederne uno fatto correttamente.

I piani di test vengono letti una volta e discussi in seguito

Un piano di test viene scritto settimane prima dell'inizio dei test, quando nessuno è sotto pressione. Viene esaminato con calma, approvato e archiviato.

Viene poi letto di nuovo esattamente in un'unica occasione: il giorno in cui qualcuno vuole rilasciare il prodotto e i test non sono finiti.

In quel momento, tutti i presenti nella stanza sono fortemente coinvolti. La data è stata comunicata. I clienti se l'aspettano. Il marketing ha pianificato qualcosa. Il team di ingegneria lavora a questo obiettivo da settimane e vorrebbe che finisse. E qualcuno apre il piano di test, legge i criteri di uscita e scopre che non risolvono nulla.

Tutti i difetti ad alta priorità risolti. Suite di regressione superata. Approvazione UAT ottenuta.

Ognuno di questi punti sembra fermo e nessuno di essi regge sotto pressione, per le ragioni trattate nella sezione successiva. Così la decisione viene presa nel modo in cui è sempre stata presa, da chiunque sia più senior e più coinvolto, e il piano di test fornisce un documento da mostrare piuttosto che un vincolo.

L'intero valore della stesura anticipata di un piano di test risiede nel fatto che le decisioni prese con calma sono migliori di quelle prese alle nove di sera di un giovedì. Questo valore si realizza solo se le decisioni sono state effettivamente prese, mentre nella maggior parte dei piani sono state solo descritte.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dal menu di navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la vista del modello

Se necessario, espandi la vista del modello per vedere chiaramente il layout completo e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor, puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo personale.

Passaggio 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere come appare il tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di piano di test puoi:

• Risparmiare ore di scrittura: Evita la pagina bianca grazie a una struttura creata appositamente per il QA.

• Migliorare la copertura dei test: Le sezioni integrate assicurano che non venga tralasciato nulla di critico.

• Rimanere fedele al brand: Applica il tuo logo, font e colori utilizzando il kit del brand di Trupeer.

• Standardizzare tra le release: Usa lo stesso modello di piano di test per ogni prodotto e release.

• Essere sempre pronto per gli audit: Allineato con gli standard IEEE 829, ISO 29119 e simili.

• Raggiungere team globali: Traduci i piani di test in oltre 65 lingue con un solo clic.

Scrivi prima i criteri di uscita e indica chi può concedere le deroghe

Due modifiche, entrambe a basso costo, e rappresentano l'intero argomento di questa pagina.

Scrivi i criteri di uscita prima di qualsiasi altra cosa nel piano. Prima dell'ambito, prima dell'approccio, prima della pianificazione. Questo inverte l'ordine abituale e porta la questione più difficile in primo piano, quando si tratta ancora di una discussione e non di una negoziazione. Tutto il resto del piano esiste per soddisfare i criteri di uscita, quindi deciderli per primi tende anche a produrre un piano più breve.

Indica chi può derogare a ciascuno di essi. Non il team. Una persona, identificata dal ruolo, e nello specifico non la persona il cui compito è effettuare il rilascio.

L'autorità di deroga è la modifica che fa funzionare le cose. I criteri di uscita non vengono quasi mai formalmente ignorati, perché non esiste un meccanismo per farlo, quindi vengono invece reinterpretati. Un difetto viene riclassificato. Un criterio viene letto con generosità. Qualcuno firma qualcosa che non ha verificato.

La reinterpretazione è invisibile e non lascia traccia. Una deroga è visibile, richiede che una persona specifica vi ponga la propria firma e produce un documento che si può consultare in seguito. Questa differenza cambia il comportamento prima di cambiare qualsiasi altra cosa, perché riclassificare un difetto in una riunione è facile, firmare una deroga no.

Aggiungi un ulteriore campo: in caso di deroga a un criterio, registra quale azione compensativa viene intrapresa. Rilascio iniziale solo al dieci percento dei clienti, o con un piano di rollback pronto, o con il team di supporto informato. Una deroga senza compensazione è solo una decisione di accettare il rischio, il che a volte è corretto e dovrebbe essere almeno dichiarato come tale.

Rendere i criteri di uscita applicabili

Tre proprietà, e la maggior parte dei criteri pubblicati non ne ha nessuna.

Un numero. Non "suite di regressione superata" ma "suite di regressione: cento per cento dei casi a priorità uno eseguiti, novantacinque per cento superati, zero fallimenti a priorità uno aperti". Superato ed eseguito sono cose diverse, e un piano che non le distingue riporterà il novanta percento di superamento su una suite eseguita al sessanta percento.

Un verificatore che non sia la persona sotto pressione. La classificazione della gravità è il punto debole di ogni processo di test, perché le persone che classificano i difetti sono spesso le stesse che vogliono effettuare il rilascio. Indicare chi assegna la gravità, scegliendo qualcuno esterno alla linea di delivery, rimuove la via di fuga più semplice da un criterio.

Un'autorità di deroga designata. Come sopra, e dovrebbe essere una persona diversa dal responsabile della release.

Un audit utile su un piano esistente: leggi i criteri di uscita e chiediti, per ciascuno, cosa dovrebbe fare qualcuno per aggirarlo senza mentire. Se la risposta è disponibile in meno di dieci secondi, il criterio ha bisogno di un numero e di un verificatore.

Cosa deve contenere un modello di piano di test

Dieci componenti, con i criteri di uscita al primo posto.

Le righe relative agli ambienti e ai dati di test meritano più spazio di quello solitamente concesso dai modelli. Moltissimi difetti che raggiungono la produzione non sono sfuggiti a causa di casi di test deboli. Erano semplicemente irraggiungibili, perché l'ambiente di test aveva mille record laddove la produzione ne ha quattro milioni, o perché la condizione temporale che li attiva non può verificarsi su una singola macchina.

Modello di piano di test gratuito: la struttura da copiare

Compilato con un esempio reale invece di segnaposto. Il sistema è un software per punti vendita (POS) per negozi di alimentari.

Copia da qui.

Criteri di uscita. Scritti per primi, con numeri, verificatori e autorità di deroga.

Le deroghe vengono registrate per iscritto con l'azione compensativa, prima del rilascio, non dopo.

Criteri di ingresso. Build distribuita in staging. Smoke test superato. Dati di test caricati e aggiornati. Nessun difetto a priorità uno aperto dal ciclo precedente.

Ambito. Nell'ambito: transazioni di cassa, rimborsi, riconciliazione di fine giornata, modalità offline e il nuovo motore promozionale. Fuori dall'ambito: la suite di reportistica del back office, che rimane invariata in questa release; la certificazione hardware per le nuove periferiche, che seguirà separatamente; e le integrazioni con fornitori terzi di programmi fedeltà, coperte dai test del fornitore stesso e accettate su tale base, il che costituisce un rischio registrato di seguito.

Approccio. Regressione automatizzata per i percorsi esistenti di cassa e rimborso. Test esplorativi manuali sul motore promozionale, che è nuovo. Test di performance al picco simulato. Modalità offline testata scollegando fisicamente i dispositivi, non tramite simulazione.

Ambienti. Staging, con un database ripristinato da uno snapshot di produzione di una rete di grandi negozi. Quattro casse fisiche di due generazioni hardware diverse. Si noti che lo staging ha un singolo application server mentre la produzione ne ha sei, pertanto il comportamento di bilanciamento del carico non è rappresentato e questo costituisce un rischio dichiarato.

Dati di test. Snapshot di produzione, anonimizzato, aggiornato settimanalmente. Include almeno un negozio con più di cinquantamila transazioni storiche, poiché in passato si sono verificati difetti legati ai volumi.

Pianificazione e finestra temporale. Tre settimane. Lo sforzo stimato per l'esecuzione è di undici giorni-uomo per due tester, ovvero quattordici giorni lavorativi a fronte di una finestra di quindici giorni. Un solo giorno di contingenza, il che è risicato e registrato come rischio.

Risorse. Due tester, a tempo pieno. Un ingegnere delle performance per tre giorni. Business owner per due giorni di UAT. Se uno dei due tester viene spostato sul supporto, la finestra non regge e il criterio due è il primo a essere a rischio.

Rischi. Singolo application server in staging. Un giorno di contingenza nella pianificazione. Integrazione fedeltà di terze parti non testata da noi. Il business owner è nuovo nel ruolo.

Deliverable. Risultati dei test eseguiti con relative prove, report dei difetti, un report di riepilogo dei test e l'eventuale registro delle deroghe firmate.

Copia fino a qui.

Esempio di piano di test: tre difetti ad alta priorità che sono diventati due

Danecroft Retail Systems fornisce software per punti vendita a negozi di alimentari e impiega circa centottanta persone. Ha rilasciato una versione principale per una rete di trecentoquaranta negozi.

Il piano di test era normale. I suoi criteri di uscita recitavano: tutti i difetti ad alta priorità risolti, suite di regressione superata, approvazione UAT ottenuta.

Il giorno della decisione sul rilascio, erano aperti tre difetti ad alta priorità. La suite di regressione era stata eseguita al novantuno percento e il piano non distingueva tra eseguito e superato. L'UAT era stata firmata da un product owner in carica da sole cinque settimane.

Il release manager ha sottoposto la questione al CTO. Il CTO ha chiesto se i tre difetti fossero davvero ad alta priorità.

Due sono stati riclassificati a media priorità durante quella riunione. Il terzo è stato accettato sulla base dell'esistenza di una soluzione alternativa (workaround).

Nessuno aveva mentito e nessuno aveva violato alcuna regola. Il piano non conteneva alcuna definizione di alta priorità, nessuna dichiarazione su chi assegna la gravità, nessuna soglia sull'esecuzione della regressione e nessuna autorità di deroga designata. Non c'era nulla da scavalcare, quindi non c'era nulla da registrare.

Uno dei due difetti riclassificati ha causato blocchi delle casse in una specifica condizione promozionale. Si è verificato durante il picco delle vendite di un sabato in tutta la rete di negozi. Il rivenditore ha stimato le vendite perse in circa ottocentonovantamila sterline, ha applicato una penale contrattuale e Danecroft ha dovuto accreditare diversi mesi di canoni.

La revisione ha identificato tre punti deboli specifici, tutti nei criteri di uscita e nessuno nel testing in sé.

La gravità era assegnata dalle persone sotto pressione per il rilascio. Superato ed eseguito erano usati in modo intercambiabile, quindi il novantuno percento sembrava una percentuale di successo. Inoltre, l'approvazione non indicava alcun nome specifico e non definiva cosa la persona confermasse di aver fatto.

La riscrittura ha assegnato a ogni criterio un numero, ha designato un verificatore esterno alla linea di delivery, ha nominato un'autorità di deroga diversa dal release manager e ha richiesto deroghe scritte accompagnate da un'azione compensativa.

Nelle sei release successive sono state concesse due deroghe. Entrambe sono state registrate, entrambe prevedevano un'azione compensativa e nessun difetto è stato riclassificato durante le riunioni decisionali sul rilascio.

Il testing era stato adeguato. Il piano non aveva fornito alcun meccanismo per rendere rilevante quel testing.

Come scrivere un piano di test in sei passaggi

1. Scrivi prima i criteri di uscita, con numeri, prima di qualsiasi altra cosa nel documento.

2. Indica un verificatore per ciascuno di essi, assicurandoti che non sia qualcuno i cui obiettivi includono la data di rilascio.

3. Indica un'autorità di deroga per ciascuno, inclusi i criteri che non possono essere derogati affatto. Avere almeno un criterio non derogabile è ciò che dà significato agli altri.

4. Scrivi l'ambito, includendo ciò che è escluso, e spiega perché ogni esclusione è accettabile.

5. Descrivi l'ambiente in modo onesto, in particolare laddove differisce dalla produzione in modi che potrebbero nascondere i difetti.

6. Fai i calcoli della pianificazione e registra la contingenza, in modo che quando la finestra temporale si restringe, la discussione verta su quali criteri sono a rischio piuttosto che sul fatto che il testing sia quasi terminato.

Il terzo passaggio è quello che cambia i risultati. Un piano in cui tutto può essere derogato dalla persona che effettua il rilascio è solo una dichiarazione di intenzioni.

Ambito e cosa non si sta testando

La sezione fuori dall'ambito è la seconda parte più preziosa di un piano di test, eppure riceve una sola riga nella maggior parte di essi.

Vi appartengono tre categorie, e sono diverse tra loro.

Escluso deliberatamente perché invariato. Ragionevole, e vale la pena dichiararlo con la relativa motivazione, perché "invariato" è un presupposto che a volte si rivela errato.

Escluso perché testato da qualcun altro. Componenti di terze parti, integrazioni di fornitori, certificazione hardware. Specifica chi lo sta testando e in base a quali prove lo stai accettando. È qui che il rischio si trasferisce silenziosamente.

Escluso perché non può essere testato qui. Comportamento del bilanciamento del carico, reti di pagamento reali, volumi di dati di produzione, concorrenza reale. Questi sono i punti di onestà e dovrebbero apparire sia nella sezione dei rischi che in quella dell'ambito, poiché indicano i difetti che il tuo processo non è in grado di rilevare.

La terza categoria è quella che prevede gli incidenti in produzione. Un team in grado di elencare ciò che i suoi test non possono raggiungere è un team che sa dove guardare quando qualcosa va storto.

Piano di test, strategia di test o caso di test?

Tre livelli, e la confusione tra di essi è abbastanza comune da meritare di essere chiarita chiaramente.

Una strategia di test è a livello organizzativo. Come testa questa azienda, quali tipi di test utilizza, quali standard si applicano. Viene scritta una volta e si applica a tutti i progetti.

Un piano di test è specifico per una release o un progetto. Questa pagina.

Un caso di test è un singolo controllo, con passaggi e un risultato atteso. La pagina dei modelli di documentazione di test copre questi aspetti, spiegando anche perché il risultato atteso è il punto in cui la maggior parte delle suite di test fallisce.

Al di sopra di tutti e tre si colloca il piano di QA, che copre tutto ciò che viene fatto per prevenire i difetti piuttosto che per trovarli: revisione dei requisiti, definizione di "done" (completato), standard di revisione del codice. Il modello di piano QA copre questa distinzione. Se il tuo piano QA contiene solo testing, hai scritto un piano di test con un titolo più ampio.

La fattibilità del rilascio di una release è una questione più ampia rispetto al semplice completamento dei test, poiché è condizionata anche dalla documentazione, dalla prontezza del supporto e dalla configurazione della fatturazione. Il modello dei requisiti di rilascio copre questo aspetto.

Varianti del piano di test

La struttura rimane la stessa, ma l'enfasi si sposta.

Piani di test Agile o per sprint. Solitamente molto più brevi, spesso di una singola pagina, e frequentemente inseriti nella definizione di completato. L'argomento dei criteri di uscita si applica inalterato e conta di più, perché la decisione si ripete a ogni sprint.

Piani di test di accettazione utente (UAT). Il criterio di uscita è una persona che firma qualcosa, quindi specifica cosa sta confermando di aver fatto personalmente. Una firma su un documento che nessuno ha letto è il controllo più debole comunemente utilizzato.

Piani di test di performance e carico. Le soglie sono naturalmente numeriche, il che rende questi piani i più facili per i quali scrivere criteri applicabili. La difficoltà si sposta sul fatto che l'ambiente sia in grado o meno di generare un carico rappresentativo.

Ambienti regolamentati e validati. I settori farmaceutico, dei dispositivi medici e contesti simili hanno requisiti definiti per la documentazione dei test, la tracciabilità e l'approvazione; il piano fa parte di un pacchetto di prove che potrebbe essere ispezionato anni dopo. Costruisci il piano in conformità allo standard applicabile con il contributo di esperti qualificati, poiché nulla in questa pagina può sostituirlo.

Hardware e sistemi integrati. I piani di test devono coprire le configurazioni fisiche e le condizioni ambientali, e la sezione relativa all'ambiente diventa solitamente la parte più lunga del documento.

Cosa non può risolvere un modello di piano di test gratuito

Una data che non può essere spostata. Se la release deve uscire in ogni caso, il piano documenta ciò che è stato saltato piuttosto che prevenirlo. Questa è talvolta una decisione aziendale legittima e dovrebbe essere dichiarata come tale anziché essere camuffata da criterio superato.

Un ambiente che non può rivelare il difetto. Nessun download gratuito di modelli di piani di test ti fornirà i volumi di dati di produzione o la concorrenza reale.

Gravità assegnata dalla parte interessata. Il modo più comune in cui i criteri di uscita vengono aggirati; si tratta di una scelta di governance piuttosto che di documentazione.

Una finestra temporale che non è mai stata realistica. Fare i calcoli nel piano rende almeno visibile la discrepanza finché c'è tempo per cambiare qualcosa.

Dimostra che il testing è avvenuto

I criteri di uscita dipendono dalle prove, e nella maggior parte delle organizzazioni la prova è rappresentata da una colonna di stato.

La suite di regressione è stata eseguita. Qualcuno ha spuntato i casi. Se ogni caso sia stato eseguito come scritto e cosa sia stato effettivamente osservato non viene registrato da nessuna parte, il che significa che un criterio che indica il cento per cento di esecuzione si basa su un'affermazione piuttosto che su una registrazione. Dopo un incidente, è proprio questa affermazione a essere esaminata, e di solito non può essere comprovata in alcun modo.

Trupeer AI produce questa registrazione come sottoprodotto. La registrazione di una sessione di test genera una guida scritta con screenshot già catturati e posizionati, insieme al video, con il branding della tua azienda. Ciò che è stato osservato in ogni fase esiste concretamente invece di essere semplicemente affermato, che è ciò di cui un verificatore ha bisogno per firmare un criterio in modo onesto.

Registralo. Personalizzalo con il tuo brand. Traducilo. Usa Trupeer.

Seguono due punti. Laddove il testing viene eseguito da un team esterno o offshore, la prova di ciò che è stato effettivamente fatto vale più di un report di stato, e una registrazione è la forma più economica per ottenerla. Inoltre, la registrazione di un tester esperto che lavora su uno scenario complesso è il modo in cui un nuovo tester impara cosa significhi effettuare una verifica corretta, un'abitudine che nessun caso scritto può trasmettere.

Il materiale risiede nella tua knowledge base e funge anche da formazione. L'uniformità tra i tuoi documenti è solo questione di impostare il kit del brand una volta sola, e la configurazione è descritta nella guida alla configurazione dei modelli di documento.

Domande frequenti

Esiste una versione Word gratuita del modello di piano di test?

Word si adatta bene al piano stesso, poiché la maggior parte di esso è testo in prosa che viene esaminato e concordato, e perché solitamente richiede un'approvazione. Un file Word come modello di piano di test è il formato di lavoro corretto.

Inserisci la tabella dei criteri di uscita a pagina uno. Tutti i modelli li inseriscono verso la fine, che è il punto in cui vengono letti per ultimi durante la stesura e ricevono meno attenzione, eppure sono l'unica parte del documento che verrà effettivamente utilizzata sotto pressione.

Esiste una versione Word semplice del modello di piano di test?

Sì, e per una release di piccole dimensioni o per un singolo sprint, un file Word semplice di una o due pagine per il piano di test è assolutamente appropriato.

Taglia le sezioni relative all'approccio e alle risorse prima di tagliare i criteri di uscita. Un piano di una sola pagina con criteri numerici, un verificatore designato e un'autorità di deroga vale più di un piano di quindici pagine che ne è privo.

Esiste una versione Excel gratuita del modello di piano di test?

Excel si adatta alle parti di un piano di test che sono tabulari: la pianificazione, la matrice di copertura, l'assegnazione delle risorse e la tabella stessa dei criteri di uscita. Un file Excel come modello di piano di test gestisce al meglio questi elementi.

Le sezioni relative all'ambito, all'approccio e ai rischi sono testi e appartengono a un documento. Suddividere un piano su due file va bene, a condizione che uno faccia riferimento all'altro e che solo uno di essi sia la versione approvata.

Esiste un modello di piano di test gratuito in PDF?

Il PDF è la copia approvata allegata al registro di rilascio. Esporta un PDF del piano di test gratuito una volta concordato, con la versione e la data, e conservalo insieme ai risultati e all'eventuale registro delle deroghe.

Quel pacchetto è ciò che verrà esaminato se qualcosa dovesse andare storto in seguito, e il registro delle deroghe è la parte che le persone vorrebbero aver compilato. Un piano senza traccia di ciò che è stato derogato costringe tutti a ricostruire una riunione basandosi solo sulla memoria.

Dove posso trovare un esempio di documento di piano di test in PDF?

Le università, i dipartimenti per gli appalti pubblici e i settori regolamentati pubblicano documenti reali; un esempio di documento di piano di test in formato PDF proveniente da queste fonti è più utile di un modello commerciale perché è stato scritto sotto vincoli reali e spesso revisionato da qualcuno con autorità.

Leggi i criteri di uscita e la sezione fuori dall'ambito. Questi due elementi mostrano se il piano è stato uno strumento di controllo o una semplice formalità, e sono le sezioni che differiscono maggiormente tra le organizzazioni che rilasciano software in modo affidabile e quelle che non lo fanno.

Esiste un download gratuito di un modello di piano di test che valga la pena utilizzare?

L'elenco delle sezioni è stabile da decenni, quindi un download gratuito di un modello di piano di test ti farà risparmiare poco e ogni versione offre all'incirca la stessa struttura.

Valuta ognuno di essi in base a una sola domanda. I criteri di uscita prevedono lo spazio per una soglia, un verificatore e un'autorità di deroga? Nessuno lo fa. Aggiungere queste tre colonne richiede due minuti e fa la differenza tra un piano che decide qualcosa e un piano che descrive semplicemente un'intenzione.

Cosa dovrebbero dire in concreto i criteri di uscita?

Numeri, verificatori e autorità di deroga. Non "suite di regressione superata" ma "cento per cento dei casi a priorità uno eseguiti e superati, verificati dal QA lead, non derogabili".

La prova del nove è verificare se qualcuno potrebbe soddisfare il criterio senza fare il lavoro e senza mentire. Se un difetto può essere riclassificato, se una percentuale può essere interpretata come tasso di superamento o se una firma può essere apposta da qualcuno che non ha verificato nulla, il criterio presenta una via di fuga e necessita di un'ulteriore clausola.

Chi dovrebbe scrivere il piano di test?

Chiunque guidi il testing, con i criteri di uscita concordati da qualcuno che non sia responsabile della data di rilascio. Questa separazione è il punto fondamentale, ed è il motivo per cui i piani scritti interamente all'interno di un team di delivery tendono ad avere criteri blandi.

Fai leggere specificamente i criteri di uscita al business owner, poiché uno di essi solitamente dipende dalla sua firma ed è bene che sappia in anticipo cosa confermerà di aver fatto personalmente.