Piano di test

Compilarlo online è gratuito, non serve un account e si scarica come documento Word o PDF. Vedi tutti i modelli di IT e progetti

• Prodotto e release

  Ad esempio: App mobile TidyPlan 4.2.0

• Responsabile dei test

  Ad esempio: Anna Berg

• Versione del piano e data

  Ad esempio: 1.0, 3 marzo 2030

• Cosa devono dimostrare i test

  Ad esempio: Che le liste condivise funzionino fino a 6 persone contemporaneamente, che l'accesso e il caricamento delle foto non si blocchino più e che nulla di ciò che funzionava prima si sia rotto.

• In ambito

  Ad esempio: Liste condivise, accesso, caricamento delle foto, notifiche, i 20 percorsi utente principali.

• Fuori ambito (facoltativo)facoltativo

  Ad esempio: Pannello web di amministrazione, invariato dalla 4.1.0. Verificato solo con la suite di regressione.

• Tipi di test

  Una riga per ogni tipo di test.

  Ad esempio: Test unitari | Sviluppatori | A ogni modifica Test di integrazione | Sviluppatori | Ogni giorno Test manuali delle funzionalità | Tester | Per funzionalità Suite di regressione | Tester | Prima del rilascio Test di prestazioni | Responsabile dei test | Una volta, 500 utenti contemporaneamente Controllo di sicurezza | Responsabile della sicurezza | Una volta

• Ambienti e dispositivi

  Ad esempio: Server di test con una copia della configurazione in produzione, senza dati reali dei clienti. 6 telefoni: 3 Android, 3 iOS, il più vecchio supportato e il più recente.

• Dati di test (facoltativo)facoltativo

  Ad esempio: Account e liste inventati. Nessun dato personale reale.

• Calendario

  Una riga per ogni passaggio.

  Ad esempio: Piano di test approvato | 3 marzo Test delle funzionalità | dal 3 al 7 marzo Regressione | dall'8 al 10 marzo Decisione di rilascio | 11 marzo

• Come vengono gestiti i bug

  Ad esempio: Ogni bug viene registrato con passaggi, screenshot e dispositivo. Critico: blocca il rilascio, risolto in 1 giorno. Alto: risolto prima del rilascio. Medio e basso: pianificati.

• Regole di ingresso (quando può iniziare il test)

  Ad esempio: La build è sul server di test, i test unitari passano e le note di rilascio sono pronte.

• Regole di uscita (quando il test è concluso)

  Ad esempio: Tutti i test pianificati sono stati eseguiti. Nessun bug critico o alto aperto. Suite di regressione superata almeno al 98%. Il responsabile dei test firma il rapporto.

• Rischi (facoltativo)facoltativo

  Ad esempio: Solo 2 tester nell'ultima settimana. Mitigazione: gli sviluppatori partecipano ai test di regressione.

1. 11. Obiettivi
2. 22. Ambito
3. 33. Tipi di test
4. 44. Ambienti e dispositivi
5. 55. Dati di test
6. 66. Calendario
7. 77. Bug
8. 88. Regole di ingresso
9. 99. Regole di uscita
10. 1010. Rischi

1. 01

   Compila

   Inserisci i tuoi dati nel modulo. Il documento si compila mentre digiti; fai clic su qualsiasi spazio vuoto per passare al relativo campo.

2. 02

   Controlla

   Leggilo per intero. Gli spazi non compilati restano contrassegnati, così non invii nulla a metà.

3. 03

   Scarica

   Salvalo come documento Word per modificarlo ulteriormente, oppure come PDF per inviarlo o stamparlo.

Quali dati richiede questo modello?

Il modulo richiede 14 dati, a partire da Prodotto e release, Responsabile dei test, Versione del piano e data, Cosa devono dimostrare i test, In ambito. Altri 3 dati sono facoltativi.

Posso scaricare questo modello in Word o PDF?

Sì. Dopo aver compilato il modulo, salvalo come documento Word per continuare a modificarlo, oppure come PDF per inviarlo o stamparlo. È gratuito e non richiede un account.

Quello che scrivo viene inviato da qualche parte?

No. Quello che scrivi resta nel tuo browser mentre compili il documento. Viene inviato a nerix solo se scegli di aprire il modello nella chat.

Questi modelli per IT e progetti sono gratuiti?

Quasi tutti. Compilali e scaricali gratis in Word o PDF, senza account. Alcuni documenti più lunghi sono premium: gratuiti da compilare, a pagamento una sola volta per scaricarli e segnati con il loro prezzo.

Una politica di sicurezza ci rende sicuri?

Nessun documento lo fa da solo. Una politica aiuta quando corrisponde a ciò che le persone fanno davvero: tienila breve, spiegala al team e rivedila ogni anno.

Il project charter serve solo ai grandi progetti?

No. Anche un piccolo progetto ne trae vantaggio, perché una pagina che indica obiettivo, limiti e chi decide evita la maggior parte delle discussioni successive.

• Specifica di integrazione APIDefinisci come due sistemi si collegano: quali dati passano, come sono protetti, come vengono gestiti gli errori e chi ne è responsabile.IT e progetti
• Registro delle decisioni architetturaliRegistra una decisione tecnica con contesto, opzioni, motivi e conseguenze, così il team può ritrovarla in seguito.IT e progetti
• Informativa sull'uso di dispositivi personali (BYOD)Stabilisci le regole per usare telefoni e portatili personali per lavoro: sicurezza, privacy, supporto e uscita.IT e progetti
• Segnalazione di bugSegnala un problema software così che uno sviluppatore possa riprodurlo, valutarne l'impatto e risolverlo.IT e progetti
• Piano di gestione del cambiamentoPianifica come informare, formare e supportare le persone durante un grande cambiamento, e come saprai che ha funzionato.IT e progetti
• Richiesta di modificaChiedi una modifica a un progetto o a un sistema, mostra il suo impatto e registra se viene approvata.IT e progetti

Vedi tutti i modelli di IT e progetti