I bug continuano a riapparire nel nostro software GUI durante lo sviluppo. Come dovrebbe essere affrontato?

Naviga le tue risposte
5

Abbiamo un prodotto software con molte funzioni di usabilità e lo stiamo costantemente modificando. Abbiamo problemi con cose come la persistente posizione di scorrimento che sembrano essere corrette, ma poi si rompono di nuovo quando rilasciamo. Abbiamo buoni tester, ma sembra che ci manchino cose del genere perché ci sono così tante funzionalità nell'applicazione che è difficile eseguire test di regressione completi.

In che modo è meglio risolvere questo problema? Mi piacerebbe avere i test dell'interfaccia utente automatizzati, ma quelli sono fragili. Mi piacerebbe che i nostri tester testassero ogni caratteristica ogni volta che implementiamo una nuova funzione, ma ciò richiederebbe un'eternità e sembrerebbe poco pratica. Volevo valutare come altri negozi di software fanno questo e come evitano i bug ricorrenti.

    
posta Brandon Montgomery 15.06.2011 - 23:48
fonte

4 risposte

9

Sfortunatamente per te, questo è esattamente il modo in cui altri negozi (quelli di successo, almeno) evitano i bug ricorrenti. Crei una serie di test di regressione, automatici o manuali, che coprono tutti i bug che hai corretto (o quanti più di loro puoi, almeno), e poi ti assicuri che l'intero set sia eseguito e passa prima di lasciare che una costruzione veda la luce del giorno. Se qualcuno fallisce, la compilazione fallisce e tu torni indietro e risolvi il problema, il riesegue l'intera suite di test. Ci vuole disciplina, ma aumenterà enormemente la qualità delle tue versioni.

Avere un buon controllo del codice sorgente e progettare il codice per rendere più facile il test aiuta davvero a semplificare questo processo. Inoltre, consiglierei di leggere su buoni processi per la gestione della build. Gestione delle versioni terminata rappresenta un ottimo punto di partenza.

    
risposta data 15.06.2011 - 23:55
fonte
2

Automatizza sotto il livello dell'interfaccia utente, quando possibile, per cogliere i tuoi bug di funzionalità. Sviluppa mantenendo il tuo livello di interfaccia utente il più sottile possibile. I pattern MVC / MVP potrebbero aiutare con questo. Quando possibile, prova la libreria di classi o l'API sottostante all'interfaccia utente anziché all'interfaccia utente stessa.

Tuttavia, quando si tratta di bug dell'interfaccia utente come il bug di scorrimento che hai menzionato, hai davvero bisogno di scrivere alcuni test dell'interfaccia utente. Ci sono cose che puoi fare per ridurre al minimo lo sforzo, tuttavia:

  • Utilizza gli ID per tutti gli elementi dell'interfaccia utente durante lo sviluppo del prodotto e registra ciascun ID in una singola variabile nel codice di test. Usa questa variabile ovunque nel codice di prova quando devi interagire con l'elemento dell'interfaccia utente. In questo modo, non è necessario aggiornare più righe di codice. In WatiN, puoi scrivere classi che ereditano dall'oggetto Page e utilizzare l'attributo FindBy per elencare il proprio ID una sola volta nel tuo codice.
  • Migliora l'interfaccia utente nelle prime fasi del processo di sviluppo. I fogli di stile o la grafica possono cambiare, ma il tuo controllo di base e gli elementi dell'interfaccia utente dovrebbero essere impostati in pietra al più presto. Il test più presto ottiene quegli ID e user story per l'utilizzo del sito Web e sa di poter fare affidamento su di essi, prima possono iniziare a scrivere test mantenibili. Ciò potrebbe richiedere modifiche al processo.
  • Automatizza solo quei test che coprono aree che non sono in costante flusso. Vai per la frutta a basso impatto sui test dell'interfaccia utente. Se non sei sicuro, continua a farlo manualmente ancora per un po '.
  • Automatizza in particolare quelle cose che "mai" si spezzano. Queste sono le cose che è più probabile che i tester manchino (perché non hanno probabilità di avere problemi) e le cose che sono più mantenibili da automatizzare. Ciò libererà i tester dal preoccuparsi di aree relativamente stabili del codice in modo che possano concentrarsi su quelle aree difficili da automatizzare che hanno maggiori probabilità di avere bug.
risposta data 16.06.2011 - 00:21
fonte
1

Utilizza test automatici per tutto ciò che puoi. Se ritieni che il test dell'interfaccia utente automatizzato sia fragile, ciò non significa che non puoi utilizzare i test automatici in qualsiasi punto del programma. Man mano che il programma cresce, anche i test lo faranno e avrai una mano più strong su ciò che sta accadendo e che sta accadendo correttamente. Tutto ciò che non supera i test automatici non viene testato dai tester. Questo dà loro più tempo per testare più difficile automatizzare le cose, poiché le semplici regressioni vengono catturate in anticipo.

    
risposta data 15.06.2011 - 23:57
fonte
1

L'unica cosa che si avvicina a trovare presto questo tipo di problema è il test dell'unità.

In questo caso avresti una serie di test unitari concentrati su questa area problematica e assicurati che questi test siano stati eseguiti prima di effettuare il check in qualsiasi modifica. Quindi, se i test falliscono, sapresti che le modifiche richiedono più lavoro.

Poiché il problema è nell'interfaccia utente che rende i test più difficili, ma devi chiedere a te stesso (e al capo) - cosa c'è di più costoso, far funzionare una serie di test unitari o dover continuare a rivedere questo codice ancora e ancora e ancora non sono sicuro di avere una soluzione stabile.

In assenza di test unitari devi solo eseguire i test manualmente e assicurarti che vengano eseguiti in anticipo e spesso.

    
risposta data 16.06.2011 - 00:00
fonte

Leggi altre domande sui tag

Se un altro team non ha svolto un compito richiesto, dovremmo menzionarlo in ogni Daily Scrum come Impediment fino a quando non lo fanno? Dove posso trovare un confronto autorevole delle lingue dei computer? [chiuso]