Chi scrive i test automatizzati dell'interfaccia utente?Sviluppatori o tester?

StackOverflow https://stackoverflow.com/questions/1297195

Domanda

Siamo nelle fasi iniziali di un progetto di grandi dimensioni e abbiamo deciso che una qualche forma di test automatizzato dell'interfaccia utente sarà probabilmente utile per noi, ma non abbiamo ancora capito esattamente come funzionerà...

L'obiettivo principale è automatizzare l'installazione di base e l'esecuzione dell'app, nel caso in cui uno sviluppatore causi un grave guasto (per esempio:l'app non verrà installata, la rete non si connetterà, la finestra non verrà visualizzata, ecc.) i tester non devono perdere tempo (e infastidirti) installazione e configurazione di una build danneggiata

Un obiettivo secondario è aiutare i tester quando affrontano attività ripetitive.

La mia domanda è:Chi dovrebbe creare questo tipo di test?Il presupposto implicito nel nostro team è che lo faranno i tester, ma tutto quello che ho letto in rete sembra sempre implicare che saranno gli sviluppatori a crearli, come una sorta di "unit test esteso".

Alcuni pensieri:

  • Gli sviluppatori sembrano essere in una posizione molto migliore per farlo, dato che conoscono gli ID di controllo, le classi, ecc. E hanno un quadro molto migliore di come funziona l'app

  • I tester hanno il vantaggio di NON sapere come funziona l'app e quindi possono produrre test che potrebbero essere molto più utili

  • Ho scritto alcuni script iniziali utilizzando IronRuby E Bianco.Ha funzionato davvero bene ed è abbastanza potente da fare letteralmente qualsiasi cosa, ma poi devi essere in grado di scrivere codice per scrivere i test dell'interfaccia utente

  • Tutti gli strumenti di test automatizzati dell'interfaccia utente che abbiamo provato (TestComplete, ecc.) sembrano essere incredibilmente complessi e fragili e, sebbene i tester possano usarli, impiegano circa 100 volte più tempo e si imbattono costantemente in "complessità accidentale" causato dagli strumenti di test dell'interfaccia utente.

  • I nostri tester non sanno programmare e, sebbene siano molto intelligenti, tutto ciò che ho ottenuto sono stati sguardi divertenti quando ho suggerito che i tester potrebbero potenzialmente scrivere semplici script Ruby (anche se detti script sono circa 100 volte più facili da leggere e scrivere rispetto al caos disordinato di pulsanti e griglie dati che sembrano essere lo standard per gli strumenti di test automatizzati dell'interfaccia utente).

Apprezzerei davvero qualsiasi feedback da parte di altri che hanno provato l'automazione dell'interfaccia utente in un team di sviluppatori e tester.Chi ha fatto cosa e ha funzionato bene?Grazie in anticipo!

Modificare: L'applicazione in questione è un'applicazione "rich client" C# WPF che si connette a un server utilizzando WCF

È stato utile?

Soluzione

Idealmente dovrebbe davvero essere QA che finiscono per scrivere i test. Il problema con l'utilizzo di una soluzione programmatica è la curva di apprendimento necessari per avere la gente QA fino a velocità con l'utilizzo dello strumento. Gli sviluppatori possono certamente aiutare con questo curva di apprendimento e aiutare il processo di mentoring, ma ci vuole ancora tempo ed è un freno allo sviluppo.

L'alternativa è quella di utilizzare un semplice strumento di interfaccia grafica che sostiene una lingua (e gli script di dati) e consente QA di creare script visivamente, approfondendo i dettagli più fini del linguaggio solo quando realmente necessario - lo sviluppo può anche arrivare qui anche coinvolto.

I tentativi di maggior successo che ho visto sono stati definitivamente con quest'ultima, ma la configurazione di questo è la parte più difficile. Selenio ha funzionato bene per semplici applicazioni web e fili semplici attraverso l'applicazione. JMeter anche (per le conversazioni web script per i servizi web) ha funzionato bene ... Un'altra opzione che è quello della casa costruita nel test harness - un semplice strumento sopra la parte superiore di un linguaggio di scripting (Groovy, Python, Ruby) che permette a QA inserire i dati di prova nell'applicazione sia tramite una GUI o tramite file di dati. I file di dati possono essere semplici file di proprietà, o nei casi più complessi strutturati (qualcosa come YAML o anche Excel) file di dati. In questo modo si può costruire i test di fumo di base per iniziare, e poi ampliata che in vari test di scenario guidato.

Infine ... Penso ricche applicazioni client sono il modo più difficile per testare in questo modo, ma dipende dalla natura del linguaggio e gli strumenti a vostra disposizione ...

Altri suggerimenti

Nella mia esperienza, i tester che possono codice passare posti di lavoro per un aumento di paga come sviluppatori.

Sono d'accordo con voi sugli strumenti di test automatizzati interfaccia utente. Ogni luogo che ho lavorato che era abbastanza ricco da permettersi WinRunner o LoadRunner non poteva permettersi il personale ad usarla. I prezzi potrebbero essere cambiati, ma allora, questi erano in alta 5 cifre per cartellini dei prezzi 6 cifre basse (si pensi al prezzo di una casa di avviamento). I prodotti erano difficili da usare, ed erano di solito conservati disinstallati in un armadietto chiuso a chiave, perché tutti avevano paura di finire nei guai per romperle.

Ho lavorato più di 7 anni come sviluppatore di applicazioni prima che finalmente passato a test e automazione dei test. Il test è molto più impegnativo di codifica, e qualsiasi sviluppatore di automazione che vuole avere successo deve padroneggiare le abilità di test.

Qualche tempo fa ho messo i miei pensieri su matrici di abilità in un paio di post di blog.

Se interessati da discutere:

http://automation-beyond.com/ 2009/05/28 / qa-automazione-skill-matrici /

Grazie.

Credo che avere gli sviluppatori scrivono i test saranno dei più uso. In questo modo, è possibile ottenere "rottura controllo" in tutto il ciclo dev, non solo alla fine. Se notturno automatizzato costruisce, si può prendere e correggere gli errori quando sono piccoli, prima che crescano in enormi, insetti, medi mangia-uomini.

E i tester che propongono le prove, e gli sviluppatori in realtà scriverlo?

Credo che in un primo momento dipende in gran parte gli strumenti utilizzati.

La nostra azienda utilizza attualmente Selenio (Siamo un negozio di Java).

Il Selenio IDE (che registra le azioni in Firefox) funziona bene, ma gli sviluppatori hanno bisogno di correggere gli errori manualmente fa contro i nostri webapps, quindi non è davvero appropriato per QA per scrivere test con.

Una cosa che ho provato in passato (con un certo successo), è stato quello di scrivere funzioni di libreria come wrapper per le funzioni di selenio. Leggono come parole povere: 

selenium.clickButton("Button Text")

... ma dietro le quinte per verificare il corretto layout e tag sul tasto, ha un ID etc.

Purtroppo questo ha richiesto un sacco di set up per consentire una facile scrittura dei test.

Recentemente sono venuto a conoscenza di uno strumento chiamato Twist (da ThoughtWorks, costruita su il motore Eclipse), che è un wrapper per Selenio, permettendo semplici test in stile inglese da scrivere. Spero di essere in grado di fornire questo per i tester, che possono scrivere affermazioni semplici in un inglese!

Si crea automaticamente stub per le nuove affermazioni troppo, così i tester potrebbero scrivere i test, e passarle agli sviluppatori se hanno bisogno di un nuovo codice.

Ho scoperto che l'opzione più ragionevole è avere abbastanza specifiche in modo che gli addetti al QA possano interrompere il test, fondamentalmente capire cosa vogliono testare su ogni "schermo" o su ciascun componente, e interromperli.Gli stub dovrebbero avere un nome tale da essere molto descrittivi di ciò che stanno testando.Ciò offre anche un modo per cristallizzare i requisiti funzionali.In effetti, soddisfare i requisiti in questo modo è particolarmente semplice e aiuta le persone non tecniche a lavorare davvero nelle acque fangose ​​del proprio processo.

Gli stub possono essere compilati tramite una combinazione di addetti al QA/sviluppo.Ciò ti consente di formare in modo ECONOMICO gli addetti al controllo qualità su come scrivere i test e in genere lo bevono perché aumenta la loro sicurezza sul lavoro.

Penso che dipende in gran parte dal livello di abilità del vostro team di test, gli strumenti disponibili, e la cultura del team rispetto a come gli sviluppatori e tester interagiscono tra loro. La mia situazione attuale è che abbiamo una squadra di prova relativamente tecnica. Tutti i tester sono tenuti ad avere capacità di sviluppo. Nel nostro caso, i tester scrivono UI Automation. Se la tua squadra di prova non ha tali competenze non saranno impostare per il successo. In tal caso, può essere meglio per gli sviluppatori di scrivere voi automazione interfaccia utente.

Altri fattori da considerare:

Quali altre attività di test sono sul piatto dei tester? Chi sono i vostri clienti e quali sono le loro aspettative relative alla qualità? Qual è il livello di abilità del team di sviluppo e quale è la loro volontà di assumere il lavoro di automazione dei test?

-Ron

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top