Chi dovrebbe scrivere il piano di test?

Il piano di test NON dovrebbe essere scritto dagli sviluppatori. Parte di ciò che il piano di test deve fare è verificare se lo sviluppatore ha interpretato correttamente il requisito. Uno sviluppatore non può scrivere in modo efficace un piano di test sul codice che sta per scrivere. I piani di test dovrebbero essere scritti dalle persone che faranno il controllo qualità o dagli analisti aziendali. Se gli sviluppatori devono scrivere i piani, non assegnare mai qualcuno a scrivere il piano per la parte del programma che sta per scrivere.

Si noti che questo è diverso dal progettare i test unitari che devono essere scritti dallo sviluppatore come dovrebbe testare il codice che ha scritto per vedere se fa quello che si aspetta. Ma i piani di test devono verificare se l'applicazione funziona come previsto e ciò deve essere fatto da qualcuno che non sa come l'applicazione è stata tecnicamente progettata per funzionare al fine di essere efficace.

Il team addetto al controllo qualità dovrebbe scrivere ed eseguire il piano di test.

Idealmente il piano di test dovrebbe essere scritto in parallelo con le specifiche funzionali - è incredibile come pensare a come testare la funzionalità concentra la mente e migliora le specifiche.

Una risposta Scrum: Se desideri definire la definizione di fatto, noterai che avere un piano di test diventa rapidamente uno degli elementi. In quale altro modo puoi descrivere la storia da fare, se non è stata testata.

Chi è quindi responsabile della creazione del piano di test? Il team

Chi è il team? Qualsiasi persona impegnata a realizzare il prodotto dovrebbe essere un membro del team.

Quindi nel tuo caso potresti includere (o assumere) la persona che può scrivere i piani di test nel tuo 'team di sviluppo'. Se ti stai spostando su Agile, noterai che la creazione di un piano di test avviene in parallelo allo sviluppo. Entrambi partono dalla stessa storia, e attraverso la comunicazione finiscono per essere sincronizzati e consegnati allo stesso tempo. Non dovresti dichiarare la tua storia "fatta" prima di aver passato i casi di test che gli Stakeholder considerano critici.

Trovo che i piani di test funzionali dovrebbero essere scritti da analisti funzionali / aziendali. Scrivono l'analisi funzionale (anche se stai lavorando agile, presumo che tu abbia qualche analisi), e quindi dovrebbero essere da scrivere quali percorsi nell'applicazione dovrebbero essere seguiti a scopo di test.

Dipende totalmente da come stai lavorando, ma a mio parere gli sviluppatori non dovrebbero scrivere documenti funzionali su come testare l'applicazione, quali dati utilizzare per testarlo, ecc.

Ecco un'idea che potrebbe rendere felici entrambi i gruppi, e si adattano bene allo spostamento verso un approccio Agile:

Automatizza i controlli di accettazione degli utenti e li screencast.

link

Sembra che parte del problema che stai riscontrando è che i piani di test che stai scrivendo sono molto ripetitivi e puramente di conferma. Per essere onesti, non chiamerei affatto quello che stai scrivendo test - se è solo confermando i requisiti, è controllo. Automatizzando questo e screencasting, potrai creare una demo completa per i tuoi clienti regolarmente (potresti persino inviarli più di un giorno al giorno) - sarà più facile fare clic su una demo e guardarla piuttosto che aprire un piano di test e iniziare a lavorarci, quindi spero che riceverai un feedback più veloce (molto importante se ti stai spostando verso un approccio più agile). Sarai in grado di riutilizzare i componenti in modo da ridurre il carico di lavoro per te, e gli sviluppatori di solito amano scrivere codice molto più della scrittura di documenti.

Fornisce anche un modo per eseguire effettivamente i requisiti: hai trovato le specifiche eseguibili di Gojko Adzic? Dai un'occhiata qui: link Se stai pensando a questo come un modo per ottenere i requisiti in un modulo eseguibile da dimostrare ai tuoi clienti, allora improvvisamente sembra molto meno inutile.

Ora, mettendo il mio cappello di prova su, sono onorato di sottolineare che se la cosa dello screencast decolla, libererà voi / i vostri stakeholder fino a fare alcuni test appropriati - cioè provare casi limite e test che effettivamente sfidare l'app, anziché limitarsi a confermare i requisiti. Ti suggerisco di fornire gli screencast insieme a brevi domande o suggerimenti per le aree su cui desideri ricevere più feedback, ad esempio:

1) Here's our new registration form - watch this screencast to see how it works!

What we'd like feedback on: We've added a lot of extra checking on this form to make sure customers aren't able to enter the wrong data - we'd really like you to look at the error messages customers get when they put in the wrong thing and tell us whether our customers will find them easy to understand.
We'd also like to know whether we've been too strict in some cases - if you've got any particularly unusual customer data (maybe a really long name, or a really short one, or someone with unusual characters in their name, or something else we didn't think of, or maybe their address doesn't have a street name or something weird like that?) then perhaps you could spend a few minutes trying those out?

vale a dire. fai un bel screencast e poi chiedi feedback, inquadrandolo senza essere too specifico, falli pensare a potenziali problemi invece di confermare. Prendili pensando , invece di cliccare ciecamente attraverso un piano di test. In pratica stai scrivendo un charter test sperimentale per loro. (Se si guardano i Agile Testing Quadranti , questi sarebbero test nel Quadrante 3).

Ristrutturare la tua casa come esempio. Accetteresti una checklist fatta dal tuo appaltatore che ti chiederà di verificare cosa ha fatto per te? O verrai con la tua lista di controllo e controllerai se l'appaltatore ha fatto ciò che hai specificato?

La risposta è chiara: il richiedente deve verificare se quello che ha richiesto è fatto secondo le specifiche. Lui / lei dovrebbe uscire con la propria checklist e testare l'app. contro questo elenco.

Lo sviluppatore, tuttavia, dovrebbe avere una propria lista di controllo e assicurarsi che i test interni siano eseguiti correttamente e che i bug siano stati risolti prima di gestire l'app. finito per UAT. Idealmente, lo sviluppatore dovrebbe automatizzare la maggior parte di questi test sotto forma di script di test. Ricorda TDD? Idealmente, gli script di test (in questo caso, casi di test unitari) dovrebbero essere scritti per testare i componenti delle applicazioni. La suite di test dovrebbe quindi essere scritta per combinare questi casi di test unitario per eseguire test di regressione integrati e successivi.

Il piano di test di accettazione dell'utente finale viene solitamente scritto dai clienti o da un socio in affari presso la società che rappresenta il cliente. Si suppone che rappresenti le caratteristiche richieste dal cliente e integra i test di integrazione del QA. Né QA né Sviluppo possono effettivamente pianificare i test di accettazione degli utenti, in quanto uno degli obiettivi principali dei test di accettazione degli utenti è quello di garantire che il QA e lo Sviluppo ritenessero che il cliente volesse sia effettivamente accurato.