2010-04-14 9 views
8

Abbiamo un sacco di sviluppatori e solo poche persone di controllo qualità. Gli sviluppatori sono stati coinvolti in qa durante il processo di sviluppo scrivendo test automatici, ma le nostre pratiche di QA sono principalmente manuali.Come posso decidere cosa testare manualmente e cosa fidarsi dei test automatici?

Quello che mi piacerebbe è se le nostre pratiche di sviluppo fossero BDD e TDD e siamo cresciuti una robusta suite di test. La domanda è: mentre creiamo una suite di test, come possiamo decidere cosa possiamo fidarci dei test e cosa dovremmo continuare a testare manualmente?

risposta

7

La prima linea di divisione è - qual è sostanzialmente più facile per testare manualmente, e ciò che è sostanzialmente più facile per testare in modo automatico?

Questi sono, ovviamente, abbastanza facili da capire, e probabilmente rimarrai con un grosso mucchio di guck nel mezzo.

Il mio prossimo setaccio sarebbe: i problemi dell'interfaccia utente sono tra i più difficili da testare in modo automatico, sebbene alcuni progetti rendano più semplice. Quindi lascio per un po 'di tempo ai responsabili del controllo qualità e concentriamo i test automatici su piccole unità di codice back-end, espandendoli lentamente a test di integrazione più ampi su più unità e/o più livelli dell'applicazione.

+0

+1 per il commento sull'automazione dell'interfaccia utente. È difficile mantenere un buon framework di test dell'interfaccia utente. –

+0

Siamo un negozio .NET e usiamo NUnit per i test unitari e Cucumber con Watir per i test di accettazione che esercitano l'interfaccia utente. Quello che abbiamo scoperto è che i nostri test Cucumber sono fragili e non li usiamo per i processi in stile BDD che sono stati progettati per supportare. Pensi che sarebbe meglio utilizzare i test di stile BDD per testare il codice del livello di servizio, invece dell'interfaccia utente? – bhazzard

+0

Il codice del livello di servizio, almeno nel 2010, sarà più semplice da testare in modo automatizzato rispetto al codice a livello di interfaccia utente. E puoi e dovresti fare BDD in stile Cucumber e testare il codice del livello di servizio (anche se ammetto di non aver mai usato Cucumber - voglio davvero avere l'opportunità di farlo comunque!). –

6

Il mio consiglio è di automatizzare tutto ciò che è possibile automatizzare. Lascia che gli umani facciano quello che sono bravi, come rispondere alla domanda "Questo è look giusto?" oppure "È utilizzabile?". Per tutto il resto, automatizza.

+0

Questo è un po 'quello che volevo sentire. Ma non sono sicuro che la nostra gente del QA (o anche me stesso) comprerebbe che possiamo fidarci della suite automatizzata. – bhazzard

+1

Ovviamente non puoi mai testare al 100% la suite automatizzata, ma ho lavorato con un sacco di tester umani che non mi fido al 100% ... –

+1

@Jim Kiley: sei molto corretto. Il vantaggio del test automatico è che ti viene ragionevolmente assicurato che ogni volta viene eseguito esattamente lo stesso. Con gli umani, specialmente gli umani che sono costretti a eseguire ripetutamente lo stesso test manuale, è facile fare errori. Il test manuale può essere sconvolgente. –

4

+1 a Jim per la raccomandazione del test manuale degli elementi dell'interfaccia utente; è relativamente facile usare uno strumento di automazione dell'interfaccia utente per creare test, ma ci vuole un sacco di pensiero e di anticipazione per progettare un framework di test che sia abbastanza robusto e completo da minimizzare la manutenzione dei test.

Se è necessario dare la priorità, un paio di tecniche che ho usato per identfiy aree non UI che potrebbero trarre beneficio più da ulteriori test sono:

  1. Guarda le segnalazioni di bug per le versioni precedenti, in particolare la bug segnalati dai clienti se si ha accesso ad essi. Alcune aree funzionali specifiche spesso rappresentano la maggior parte degli errori.
  2. Utilizzare uno strumento di copertura del codice quando si eseguono i test automatici esistenti e prendere nota delle aree con copertura ridotta o nulla.
5

Dai un'occhiata all'articolo di Mike Cohn su Test Automation Pyramid. In particolare, considera quale parte dell'interfaccia utente deve davvero essere testata in questo modo. I casi ad angolo, ad esempio, sono spesso meglio testati attraverso il livello di servizio.

+1

Che cos'è uno strumento efficace da usare per testare il livello di servizio? Dovremmo usare un tradizionale framework di test XUnit o un altro framework basato su Gherkin in stile BDD (ad es. Cucumber o SpecFlow)? – bhazzard

1

Non farà male testare qualsiasi nuova funzionalità manualmente per assicurarsi che funzioni ai requisiti e quindi aggiungerla alla suite di automazione per la regressione. (O è troppo tradizionale?)

4

Manuale di test in grado di effettuare le seguenti operazioni, a differenza di test automatizzati:

  • test GUI test
  • Usabilità
  • test esplorativo
  • Utilizzare variazioni durante l'esecuzione di test
  • trovare nuovi, non di regressione bug
  • L'occhio umano può notare tutti i problemi. Un test automatico verifica solo alcune cose.

test automatici in grado di effettuare le seguenti operazioni, a differenza di test manuali:

  • stress/test di carico
  • È anche possibile utilizzare una suite di test automatizzato per testare le prestazioni
  • test di configurazione (IMHO questo è il massimo vantaggio). Una volta scritto, puoi eseguire lo stesso test in un ambiente diverso con impostazioni diverse e scoprire dipendenze nascoste che non hai mai pensato.
  • È possibile eseguire lo stesso test su migliaia di dati di input. In caso di test manuale, è necessario selezionare il set minimo di dati di input utilizzando tecniche diverse.

Inoltre, fare un errore in un autotest è più facile e più probabile che si commetta un errore durante il test manuale. Ti consiglio di automatizzare le funzionalità più preziose, ma comunque esegui i test (almeno per sanità mentale) manualmente prima di un'importante release.

+0

Più 1 per una risposta dettagliata. – bhazzard

Problemi correlati