Riassumere il tempo speso per i test dell'interfaccia utente

4

Lavoravo con un team su un software basato sul web. Abbiamo scritto ~ 70-80 test al selenio per il prodotto. Principalmente test di percorso felice con alcuni di regressione per bug segnalati dagli utenti.

Era la prima volta che la nostra azienda eseguiva test dell'interfaccia utente automatica end-to-end e sembra abbastanza utile. Abbiamo anche alcune storie di successo, come ottenere una regressione seria in una libreria che abbiamo usato (è stata sviluppata da un'altra squadra della compagnia).

Ad ogni modo, scrivere questi test richiede molto tempo, in parte perché non avevamo molta esperienza né con il Selenium né con il test automatico dell'interfaccia utente.

Dopo alcuni mesi di sviluppo, il mio team e il proprietario del prodotto hanno avuto l'idea che dovremmo fare statistiche su quanto tempo è stato necessario scrivere e mantenere questi test. (Solitamente abbiamo creato sottotask JIRA separati per i test del selenio in modo da ottenere un numero approssimativo.)

Ho paura che questo numero da solo possa fare una brutta impressione sul test. Come possiamo produrre un numero da abbinare a questo momento per mostrare i vantaggi dei test, così potremmo decidere se ne vale la pena (o meno)?

Possiamo scavare JIRA per i bug che sono stati catturati da questi test ma riassumere i loro tempi di lavoro registrati non sembra abbastanza buono. Correggere un bug catturato dai test automatici richiede meno tempo rispetto alla correzione di uno rilasciato dagli utenti e ci sono altri vantaggi, ad esempio, meno interruzioni per gli sviluppatori. Inoltre, catturare un bug durante uno sprint dà un feedback più veloce agli sviluppatori e di solito non abbiamo creato una sottoattività JIRA separata per questi.

È una buona idea riassumere questi valori temporali?

    
posta rxx 18.01.2015 - 02:57
fonte

1 risposta

4

Il numero di bug catturati o corretti ha una pessima reputazione come metrica del software (non è affatto una metrica). Basta Google e troverai alcune storie dell'orrore. Riassumere questi valori temporali in effetti non dirà molto. Quello che vuoi dire al proprietario del tuo prodotto insieme alle statistiche è il seguente:

  • Stavi lavorando con un nuovo strumento, una nuova metodologia, hai impostato una nuova configurazione per eseguire i test. Ciò significa che hai dedicato molto tempo a apprendimento , che è un investimento. A causa di questo, man mano che ottieni sempre più esperti, il tempo che passi a scrivere questi test probabilmente diminuirà nel tempo.
  • Presumo che tu e il tuo team abbiate una buona opinione su questi test e vi sentite molto più sicuri nel rilasciare il vostro prodotto in questo modo. Assicurati che il tuo PO lo capisca, tu sei l'esperto dopotutto. Sottolinea che un bug catturato prima della versione è più economico da correggere di un ordine di grandezza, quindi un bug catturato dopo il rilascio.
  • Se ho capito bene, stai usando la mischia. Se pensi di avere un buon modo per misurare il throughput dei team (nei punti degli utenti o in qualunque altro modo), puoi suggerire di fare statistiche su come cresce a lungo termine a causa dei test.

Considerazioni finali: affinché i test dell'interfaccia utente funzionino in modo efficace, dovresti avere ancora più test di unità e integrazione. Puoi leggere tutto ciò su pagina di Martin Fowler .

    
risposta data 18.01.2015 - 09:37
fonte

Leggi altre domande sui tag