Questo boondsteading dei test dell'interfaccia utente automatizzati è ottimo a breve termine se gestisci un dipartimento QA. Il tuo staff apparirà super impegnato mentre scrive e riscrive costantemente gli script UI automatizzati. Puoi aggiungere un'altra riga su un rapporto per vantarti di quanta copertura di test fai.
Nel tempo, il tuo reparto diventa un collo di bottiglia molto evidente che mina la produttività. Gli sviluppatori non possono superare i test automatici perché il QA non li ha aggiornati per funzionare con la nuova interfaccia utente. Ciò rende gli sviluppatori esitanti nell'introdurre eventuali modifiche all'interfaccia utente.
Nel frattempo, la tua attività (o il tuo cliente) non sta rendendo le scadenze di rilascio della produzione. Il programma scivola mentre il QA si sta affannando per aggiornare gli script UI automatici contro la nuova interfaccia utente.
Quindi, a questo punto, una riflessione è in ordine.
La vendita di test dell'interfaccia utente automatizzata è che in qualche modo libera il personale addetto al controllo qualità dallo sforzo di test richiesto per esaminare l'intera interfaccia utente di un'applicazione.
Ciò che hai effettivamente fatto, tuttavia, è sostituito dai noiosi passaggi del test degli utenti con il noioso processo di scripting di quei passaggi su una macchina.
Il costo iniziale sarebbe valsa la pena solo se i passaggi sono invarianti o se la tua applicazione è molto semplice. Non ci vuole scienza per determinare che la maggior parte dello sviluppo dell'interfaccia utente è tutt'altro che invariabile. Se la tua applicazione è semplice, lo sforzo di test è minimo.
Ho visto due società diverse provare e implementare questo, e si è sempre conclusa con teste rotte e cause legali.