Piani di Test e il modo migliore per scrivere li

Question

Stiamo cercando di capire il modo migliore per scrivere i test in nostro piano di test.In particolare, durante la scrittura di un test che è pensato per essere utilizzato da chiunque, anche a personale di QA, in caso di passaggi nella prova di essere molto specifici o di più ampio respiro, dando il tester più spazio di manovra nel modo in cui il compito può essere realizzato.Come un esempio molto semplice, se si sta testando l'apertura di un documento in un documento di elaborazione testi, in caso di test di lettura:

1. Utilizzando il mouse, aprire il menu file
2. Scegliere "Apri File..." dal menu file
3. Nella finestra di dialogo apri file che viene visualizzata, accedere a x e fare doppio clic sul documento chiamato y

O

1. Visualizzare la finestra di dialogo apri file
2. Aprire il file y

Ora mi rendo conto che una risposta è probabilmente andando a essere "dipende da quello che stai cercando di test", ma sto cercando di rispondere a una domanda più generale qui:Se il test passaggi sono troppo specifici rischiamo di una) rendendo il processo di test di laborioso e noioso e soprattutto b) non abbiamo il rischio di mancanza di qualcosa, perché abbiamo scritto giù troppo specifico un percorso per raggiungere un obiettivo.In alternativa, se la facciamo ampio facciamo dipendere troppo dai capricci del tester al momento e perdere cruciale sperimentazione di percorsi che sono più comuni per i clienti/clienti?

Answer 1

La mia prima domanda sarebbe, perché non è il vostro dipartimento di QA scrivere i piani di test?In genere, gli sviluppatori di software QA con un funzionale spec di come il software dovrebbe funzionare e quindi QA crea piani di test basato su quello.

Detto questo, vorrei suggerire di essere molto specifico con il fasi, in quanto si sono dettagli come le cose sono dovrebbe per lavorare.E ' quindi il lavoro del tester per assicurarsi che i vostri passi specifici per ottenere i risultati desiderati, ed è anche il loro lavoro a deviare dal piano e cercare di rompere le cose.

Se ci sono più modi per raggiungere un obiettivo, è necessario descrivere ogni percorso per arrivarci.

Answer 2

Io non sono un tester, ma a mio parere, è di vitale importanza, di un documento di "UI percorso" che il test deve adottare al fine di evitare qualsiasi confusione.

Ho lavorato con innumerevoli difetti che io non riuscivo a riprodurre semplicemente perché non avevo accesso alla funzione dalla stessa interfaccia grafica di percorso come il tester era.ad es.Fare Clic destro menu vs Barra degli strumenti o funzioni che possono essere svolte dalle varie finestre di dialogo, etc.ecc.

Answer 3

Sembra che la tua QA personale è davvero QC (Quality Control) se non sono responsabile per la scrittura di test.Se essi sono responsabili per la scrittura di test, il test sarà utile, ma le specifiche sono chiare sarebbe una fonte migliore per loro di scrivere i test stessi.Anche se sarebbe meglio avere come parte del processo di revisione per le specifiche in modo che si può chiedere per i dettagli, che permetterà loro di scrivere i test.

Se siete veramente in una posizione in cui vi sono prove di scrittura per le altre persone, ci sono alcune considerazioni.Si vuole una dolorosa livello di dettaglio se :

• le persone che eseguono i test non sono in grado di venire a farti delle domande
• le persone che eseguono il test non si ha familiarità con il prodotto

È possibile evitare alcuni dettagli, se queste non sono vere.Tuttavia, dipende ancora :)

Tutto questo viene detto, ciò che è stato scritto non quello che è generalmente considerato un 'piano di test'.Un Test di Piano descrive il tipo di test da eseguire (funzionali, di regressione, di sicurezza, etc.), quali sono le caratteristiche per essere testato, forse anche quali sono i test per essere scritto, che farà il test, quando gruppi di test sono in programma inoltre, la pianificazione di attività di tipo.

Quanto descritto sopra è solo una serie di test.

Answer 4

La prima è la funzione di test.Prova con la procedura dettagliata contenente UI rotta c'è, eventualmente, percorsi più di uno alla destinazione.Prova tutti i percorsi.Quest'ultimo suona più come test di usabilità.Dovrebbe essere fatto troppo, ma non solo dal vostro tester, ma anche da persone esterne.

Answer 5

Proviamo a distinguere il Piano di Test e Suite di Test :)

Suite di Test consiste in una serie di prove di sé

Piano di Test è [parte di] Suite di Test + risorse disponibili (persone, hardware, tempo, ...).

E ' OK per entrambe le varianti (dettagliato e "ruvido") descritto nella documentazione di prova, basta posizionare dettagliate e "ruvido" prove a diversi documenti e definire le priorità di questi documenti.

Quindi, quando si hanno abbastanza tempo per testare il prodotto completamente, si prende tutti i documenti, per esempio, la categoria A e test di prodotto, in conformità con questi documenti.Se non avete tempo, ma hanno bisogno di una veloce conclusione circa la qualità, si prende categoria B documenti e di passare i controlli descritti.

il lato buono:è possibile selezionare la modalità di test del prodotto

lato negativo:hai bisogno di "duplicare" i documenti

Answer 6

E ' perfettamente bene a voler esatte, dettagliate, procedura per riprodurre il comportamento quando qualcuno trova un problema.Ma se scrivete i vostri piani di test, in modo tale rischio i seguenti problemi:

1) Inattentional cecità - Ho visto gente l'esecuzione di una mappa procedurale script di test, doverosamente, a piedi attraverso e la registrazione di ogni passo meticolosamente, e MANCA del tutto l'errore clamoroso di fronte a loro.Perché "non era nel copione".La loro attenzione si è così concentrati su tutti quelli schizzinoso test passaggi che hanno letteralmente potrebbe non vedere i problemi di fronte a loro.

2) Ti verrà a mancare TUTTI quei bug che sono solo un passo fuori della vostra altamente dettagliate, molto specifico percorso.Quando i clienti di ottenere il vostro prodotto, non seguire il dettagliato piano di test.Essi potranno spostarsi all'interno della app in una varietà di modi.Possono cambiare le loro menti.Avranno i nomi più lunghi o più brevi, di quanto si pensava probabile o possibile.Essi si arriva a metà strada attraverso una transazione e di abbandonarla.Essi vagano.Non aderire ad un percorso.E ogni volta che qualcuno ripete la prova, di perdere quei bug di nuovo.

3) vi permetterà di trascorrere un tempo incredibilmente lungo cercando di ottenere "chiunque può seguire questo" script di test scritti.Credetemi, ho passato anni cercando di perfezionare questo, e non è umanamente possibile.Peggio ancora, la quantità di tempo che si rifiuti cercando di fare questo potrebbe essere speso molto più proficuamente in qualche altro modo, in modo che il vostro prodotto è peggio.

4) Vi ritroverete con un sacco di ripetizioni, e sarà difficile dire qual è il punto del tuo test è senza leggere il tutto.Non sarà facile per scorrere velocemente il test per vedere che cosa i casi di utilizzo si può avere perso.

Mantenere i vostri piani di test ampia e consentire alle persone di fare il test per esercitare il proprio giudizio.Se si dispone di informazioni su specifici scenari di utilizzo che deve essere testato, o su come l'utente di destinazione il gruppo si desidera utilizzare, quindi dare a questo per i tester e con i piani di test - magari in forma di utenti, forse in forma di casi d'uso.Se avete bisogno di cose specifiche spuntato fuori, considerare l'utilizzo di una lista di controllo.(Per ulteriori informazioni, vedere Cem Kaner'eccellente presentazione www.kaner.com/pdfs/ValueOfChecklists.pdf).

In alternativa, scrivere i tuoi programmi di test breve esplorativo charter.Si potrebbe, per esempio, dare indicazioni, quali:"Callcentre utenti utilizzando postazioni di lavoro con il mouse collegato.Esplorare il processo di raccolta di un ticket per conto di un cliente, assicurando che è possibile completare tutte le attività utilizzando le scorciatoie da tastiera solo." Questo è molto più probabile che a causare il vostro tester di trovare difetti che dire "la Scheda in campo 1.Immettere "Reclamo sulla qualità della linea".Scheda campo 2.Selezionare "chiamata" dal menu a discesa.Scheda in ....campo 68."

Answer 7

c'è pro e contro per trattare il tester come hanno nessuna conoscenza del sistema o computer in generale.

se si scrive le cose nel dettaglio (ad es."dal menu file, selezionare "Apri"...") che il vantaggio è che si possono usare gli appaltatori che arent familiarità con il sistema. ma ci vuole più tempo per scrivere come questo

se si salta un sacco di dettagli (ad es."aprire un file di documento..."), rispetto a chi utilizza il vostro piano di test è più probabile rimanere bloccati, e di interrompere per un chiarimento. ma è molto più veloce a scrivere

può essere una falsa economia a pensare che è più veloce se si fa il vivace versione, se è finito per spendere più tempo a spiegare il sistema di qa persona

ho un articolo in cui vado più in profondità su questo argomento: La scrittura di un Sistema Piano di Test

in questo articolo, mi favorire l'approccio più specifico.ma ho sviluppato un 'metà' tra questi due approcci ultimamente (chiamato CARATTERISTICA di un piano di test), ma im non in un punto in cui la sua abbastanza matura per la condivisione di sicurezza

-- LM