Per essere onesti, anche un modello di piano di test che era stato utilizzato con successo da altri team agili potrebbe non funzionare bene per il tuo team, ma vedere ciò che fanno gli altri è utile per avere idee su diversi approcci.
Ho anche pensato allo stesso problema da un po 'di tempo. Il mio approccio finora è stato pragmatico: stavo lavorando in una piccola squadra, e inizialmente ero l'unico tester per 6 sviluppatori. La creazione di documentazione invece di test sarebbe stata una scelta molto scarsa. Creare documentazione invece di test, in modo che gli sviluppatori possano eseguire i test: un'altra scelta molto scarsa, IMHO.
Al momento, aggiungerò una pagina al nostro wiki per ogni storia, e questo terrà una serie di idee di prova, utilizzate come base per le sessioni di test esplorativi. Se necessario, aggiungerò anche le informazioni di installazione lì. Preferirei tenerlo separato, in modo da mantenerlo come una risorsa che può essere aggiornata più facilmente, ma al momento si passa alla stessa pagina. (In genere non mi piace mescolare il "come" e il "cosa", rende più difficile vedere "cosa" stai facendo se devi estrarlo dalle pagine di "come"). Non abbiamo un modello per quelle pagine - non credo che ne abbiamo ancora avuto bisogno. Quando lo faremo, ne aggiungerò uno e poi lo modificherò mentre impariamo di più. Al momento, per me è utile dare una panoramica di quali aree vedremo durante i test e, essendo sul wiki, chiunque può aggiungere elementi se sentono che manca qualcosa.
Ho preso in considerazione l'idea di creare un dashboard per i test a bassa tecnologia, ma al momento credo che la nostra lavagna sia sufficiente per vedere come stanno andando le storie a questo punto - anche se con il crescere del team, potremmo voler rivedere quello .
Volevi anche sapere che cosa stanno facendo gli altri tester Agile - qui ci sono alcuni post del blog che ritengo possano essere utili:
Mi piace molto la descrizione di Marlena Compton su come usa un wiki per testare su Atlassian: link
Ancora una volta, un approccio leggero, mantenendo gli obiettivi del test legati alla storia. Usa un dashboard di test per una visualizzazione di alto livello di quali funzionalità sono presenti in una versione. La funzione si collega a una pagina di obiettivi di test, che sono ordinati sotto intestazioni diverse: funzione, dominio, stress, dati, flusso e attestazioni. Ciò fornisce una vista "a colpo d'occhio" di quali aree / tipi di test hai pianificato e puoi vedere immediatamente se un'area ha molti meno test. Questo potrebbe essere un approccio che potresti trovare utile.
Trish Khoo ha anche alcune cose interessanti da dire sull'uso di una wiki, più sul livello di strutturazione dei singoli test (si sono trasferiti a utilizzare un formato "Given, When, Then" in stile Gherkin per i loro test):
link
Il post sul blog di Elizabeth Hendrickson sui sistemi di gestione dei test specializzati è un po 'fuori tema, ma potresti trovare alcuni punti utili sollevati:
link