Chi dovrebbe scrivere il piano di test?

Faccio parte del team di sviluppo interno della mia azienda e sviluppiamo i siti Web della nostra azienda in base alle esigenze del team di marketing. Prima di rilasciare il sito a loro per i test di accettazione, ci è stato chiesto di fornire loro un piano di test da seguire.

Tuttavia, il team di sviluppo ritiene che, poiché i requisiti provengono dai richiedenti, avrebbero la migliore conoscenza di cosa testare, cosa cercare, come dovrebbero comportarsi le cose ecc. E quindi non è richiesto un piano di test. Siamo sempre in una discussione su questo, e gli sviluppatori trovano una perdita di tempo per scrivere cose come: -

1. Fare clic sul pulsante A .
2. Digitare XYZ nel campo del modulo e cliccare il pulsante B .
3. Si dovrebbe vedere il comportamento C .

che dobbiamo ripetere per ogni requisito / funzione richiesta. Questo sta sostanzialmente riformulando ciò che è già nel documento dei requisiti.

Ci stiamo muovendo verso l'utilizzo di un approccio Agile per la gestione dei nostri progetti e questo è richiesto anche alla fine di ogni iterazione.

A parte i test di unità e integrazione, chi dovrebbe essere colui che deve elaborare il piano di test di accettazione dell'utente finale? Dovrebbero essere i richiedenti o gli sviluppatori?

Molte grazie in anticipo.

Saluti
CK

Il piano di test NON deve essere scritto dagli sviluppatori. Parte del piano di test è 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 devono essere scritti dalle persone che faranno il QA o dagli analisti aziendali. Se gli sviluppatori devono scrivere i piani, non assegnare mai a qualcuno di scrivere il piano per la parte del programma che sta per scrivere.

Si noti che questo è diverso dalla progettazione di unit test che devono essere scritti dallo sviluppatore in quanto 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 nel modo previsto e dovrebbe essere fatto da qualcuno che non sa come l'applicazione è stata tecnicamente progettata per funzionare per 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 - è sorprendente come pensare a come testare la funzionalità concentra la mente e migliora le specifiche.

Una risposta Scrum: se desideri definire la "Definizione del 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 gruppo

Chi è il team? Qualsiasi persona impegnata nella realizzazione del 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 trasferendo ad Agile, noterai che la creazione di un piano di test avviene in parallelo allo sviluppo. Entrambi iniziano dalla stessa storia e attraverso la comunicazione finiscono per essere sincronizzati e consegnati allo stesso tempo. Non devi dichiarare "conclusa" la tua storia prima di aver superato 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 in modo agile, presumo che tu abbia qualche analisi), e quindi dovrebbero essere la scrittura di quali percorsi nell'applicazione dovrebbero essere seguiti a scopo di test.

Dipende totalmente da come stai lavorando, ma secondo me gli sviluppatori non dovrebbero scrivere documenti funzionali su come testare l'applicazione, quali dati usare per testarla, ecc.

Ecco un'idea che potrebbe rendere felici entrambi i gruppi e adattarsi bene al passaggio verso un approccio Agile:

Automatizza i controlli di accettazione degli utenti e esegui lo screencast.

http://pragprog.com/magazines/2009-12/automating-screencasts

Sembra che parte del problema che stai riscontrando sia che i piani di test che stai scrivendo sono molto ripetitivi e puramente confermativi. Ad essere sincero, non chiamerei affatto ciò che stai scrivendo test - se sta solo confermando i requisiti, sta verificando . L'automazione e lo screencasting ti permetteranno di impacchettare regolarmente una demo ordinata per i tuoi clienti (potresti anche inviarli in un breve giorno) - avranno maggiori probabilità di fare clic su una demo e guardarla piuttosto che aprire un piano di test e inizia a lavorarci su, quindi spero che otterrai un feedback più rapido (molto importante se ti stai muovendo verso un approccio più agile). Sarai in grado di riutilizzare i componenti in modo da ridurre il carico di lavoro per te,

Fornisce anche un modo per eseguire effettivamente i requisiti: hai trovato le specifiche eseguibili di Gojko Adzic? Dai un'occhiata qui: http://gojko.net/2010/08/04/lets-change-the-tune/ Se stai pensando a questo come un modo per ottenere i requisiti in un modulo eseguibile da provare ai tuoi clienti , poi improvvisamente sembra molto meno inutile.

Ora, indossando il mio cappello da tester, sono onorato di sottolineare che se la cosa screencast decolla, libererà te / i tuoi stakeholder per fare alcuni test adeguati - cioè provare casi limite e test che effettivamente sfidano l'app , piuttosto che confermare i requisiti. Ti suggerirei di fornire gli screencast insieme a brevi domande o suggerimenti per le aree su cui desideri più feedback, ad esempio:

1) Ecco il nostro nuovo modulo di registrazione - guarda questo screencast per vedere come funziona!

Su cosa vorremmo ricevere un feedback: abbiamo aggiunto molti controlli extra su questo modulo per assicurarci che i clienti non siano in grado di inserire i dati sbagliati - ci piacerebbe davvero che tu guardassi i messaggi di errore che ricevono i clienti quando mettere la cosa sbagliata e dirci se i nostri clienti li troveranno facili da capire.
Vorremmo anche sapere se in alcuni casi siamo stati troppo severi: se hai dati sui clienti particolarmente insoliti (forse un nome davvero lungo o molto breve o qualcuno con caratteri insoliti nel loro nome, o qualcos'altro a cui non abbiamo pensato, o forse il loro indirizzo non ha un nome di strada o qualcosa di strano?), forse potresti passare qualche minuto a provarli?

Cioè tu presenti un bel screencast e poi chiedi un feedback, inquadrandolo senza essere troppo specifico, inducili a pensare a potenziali problemi piuttosto che a confermare. Falli pensare , invece di fare semplicemente clic alla cieca attraverso un piano di test. Fondamentalmente stai scrivendo una carta di prova esplorativa per loro. (Se guardi i quadranti dei test Agile , questi sarebbero i test nel quadrante 3).

Prendi il rinnovamento della tua casa come esempio. Accetteresti una lista di controllo compilata dal tuo appaltatore che ti chiede di verificare cosa ha fatto per te? O verresti con la tua lista di controllo e verificare se l'appaltatore ha fatto ciò che hai specificato?

La risposta è chiara: il richiedente deve verificare se ciò che ha richiesto viene eseguito in base alle specifiche. Dovrebbe uscire con la sua lista di controllo e testare l'app. contro questo elenco.

Lo sviluppatore, tuttavia, dovrebbe avere la propria lista di controllo e assicurarsi che vengano eseguiti test interni adeguati e che i bug vengano eliminati prima di gestire l'app. oltre 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 componenti di applicazioni. La suite di test dovrebbe quindi essere scritta per combinare questi casi di test unitari per eseguire test di regressione integrati e successivamente.

Il piano di test di accettazione dell'utente finale viene solitamente redatto dai clienti o da un socio dell'azienda presso la società che rappresenta il cliente. Dovrebbe rappresentare le funzionalità richieste dal cliente e integra i test di integrazione del QA. Né il controllo qualità né lo sviluppo possono pianificare in modo efficace i test di accettazione dell'utente, poiché uno degli obiettivi principali dei test di accettazione dell'utente è garantire che ciò che il QA e lo sviluppo ritenevano il cliente fosse effettivamente accurato.