Stiamo spendendo più tempo per implementare il test funzionale dell'attuazione del sistema stesso, è normale?

12

Fondamentalmente, abbiamo tre progetti principali, due dei quali sono servizi web e l'altro è un'applicazione web. Mentre sono soddisfatto di coprire il più possibile i nostri servizi Web con test funzionali (tutti e tre i progetti hanno i loro test unitari adeguati), i test funzionali per l'applicazione web richiedono molto tempo per essere implementati. Per molto intendo due volte, o qualche volta di più, il tempo necessario per implementare la funzionalità testata con il test dell'unità incluso.

La politica del gestore è quella di testare ogni singola funzionalità che aggiungiamo, anche se non è business critical (cioè una nuova C.R.U.D).

Sono d'accordo con la verifica di tutte le funzionalità dei servizi Web, perché è difficile testarle manualmente, inoltre, questi test sono eseguiti rapidamente e non richiedono molto per l'implementazione.

Quindi, qual è il valore nel passare più tempo a scrivere test funzionali, piuttosto che scrivere codice di sistema, test di unità e aggiustamenti di QA? È normale? Non dovremmo scrivere test funzionali solo per funzionalità critiche e lasciare che il QA faccia test di regressione su nessuna funzionalità critica?

Nota: non stiamo sviluppando software medico o software NASA o nulla di così importante.

    
posta Pablo Lascano 04.02.2013 - 22:48
fonte

6 risposte

16

I test funzionali sono molto importanti. Sì, hanno bisogno di tempo per scrivere, ma se stai scrivendo i test funzionali giusti, ne varrà la pena.

Ci sono alcuni buoni motivi per eseguire test funzionali automatici su un'applicazione.

  • Quando una nuova funzione viene aggiunta al tuo sito web, ti consente di sapere subito se le modifiche apportate a tale nuova funzionalità interrompono qualsiasi altra funzionalità sul tuo sito.
  • È una conoscenza documentata di come l'applicazione viene eseguita e lavora insieme per soddisfare i requisiti aziendali.
  • Quando è il momento di aggiornare una libreria di terze parti, puoi aggiornarla ed eseguire la tua suite di test funzionale per vedere se qualcosa si rompe. Invece di dover esaminare tutte le pagine da soli, puoi fare in modo che un computer lo faccia per te e fornirti un elenco di tutti i test che sono falliti.
  • Carica test! Puoi simulare migliaia di utenti simultanei che colpiscono contemporaneamente il tuo sito e puoi vedere dove il tuo sito rallenta e cede alla pressione. Puoi vedere come si comporta il tuo sito molto prima che arrivi una chiamata a tarda notte che il sito sia andato in crash.
  • I test funzionali richiedono tempo per essere eseguiti manualmente. Sì, ci vuole molto tempo per scrivere i casi, ma se dovessi sederti con un raccoglitore con 500 pagine di test che dovevi completare prima di poter spedire il prodotto avresti voluto avere i test automatici!
  • Testare rapidamente i documenti obsoleti. Quando viene aggiunta una nuova funzione, è necessario assicurarsi di aggiornare il documento di test principale. Se qualcuno salta alcuni test tutti voi a improvvisamente ottenere bug che si insinuano in pagine "fatte e testate". io attualmente lavoro in un ambiente come quello, e posso assicurarti è un incubo.

Alla fine, sì, ci vuole tempo per scrivere questi casi, ma dovresti essere orgoglioso di scriverli. È il tuo modo di dimostrare, oltre l'ombra del dubbio, che il tuo codice funziona e funziona con tutte le altre funzionalità là fuori. Quando il QA arriva da te e dice che c'è un bug, lo correggi e poi lo aggiungi alla tua suite di test per dimostrare che è fisso e assicurarti che non accada mai più.

È la tua rete di sicurezza. Quando qualcuno entra e dirotta un proc memorizzato e fa una piccola modifica in modo che funzioni con il loro codice, vedrai che ha rotto altre 3 funzionalità nel processo. Lo prenderai quella notte e non la notte prima della scadenza!

Come scrivere test funzionali solo per funzioni critiche del sistema. Questo non ti darà l'intera immagine e permetterà agli insetti di entrare di soppiatto. Tutto ciò che serve è aggiungere una piccola funzionalità che non è critica per il sistema, ma interagisce indirettamente con una funzione critica di sistema e si ha la possibilità di introdurre un bug.

    
risposta data 05.02.2013 - 01:29
fonte
7

Più di 2 volte ... sembra un po 'troppo per me. Potresti voler analizzare i motivi di ciò, potrebbero includere:

  • supporto degli strumenti non validi per la creazione e il mantenimento dei test

  • I contratti
  • dei servizi web non sono sufficientemente descritti nella progettazione. Gli sviluppatori devono elaborare i contratti durante il test, che di solito è un processo di allineamento che richiede tempo.

Parla con i tuoi sviluppatori.

Supponendo che tu stia sviluppando in sprint, avendo questi test funzionali se solo parte dello sprint. Non è fatto senza questi test. Se non ce l'hai, il tuo tempo per i test di integrazione dopo la fase di sviluppo potrebbe raddoppiare.

    
risposta data 04.02.2013 - 23:53
fonte
3

È necessario dedicare più tempo all'implementazione del test funzionale dell'implementazione normale del sistema?

Assolutamente. Scrivere davvero buoni test probabilmente impiegherà la maggior parte del tempo in molti (buoni) negozi.
Quindi un rapporto 2-1 va bene. Gli sviluppatori meno esperti spesso non prendono tutto il tempo necessario per i test.

    
risposta data 05.02.2013 - 03:28
fonte
1

Questo riguarda la qualità.

Se hai bisogno di ottenere il mercato, svilupperai la tua app il più rapidamente possibile. Puoi anche non avere test automatici =) ma darai la tua app al tuo uditorio prima dei tuoi concorrenti.

Ma se sai che il tuo uditorio non se ne andrà, farai qualsiasi cosa tu non possa deluderli. Ogni bug ticket farà crollare la tua reputazione. Immagina che un bug eliminerà il 50 percento della tua reputazione, il prossimo - un altro 25 percento e così via. Quindi possono esserci troppi test?

    
risposta data 04.02.2013 - 23:25
fonte
1

C'è la legge dei rendimenti decrescenti. Supponendo di scrivere per primi i test per il codice più rischioso, il valore generato da ulteriori test diminuisce nel tempo.

I test unitari sono codice, quindi contengono bug (proprio come tutti gli altri codici). La correzione di questi bug richiede tempo.

Nella mia esperienza, i test unitari contengono molti più bug rispetto al sistema che stanno testando e il loro fissaggio è un onere continuo.

    
risposta data 17.06.2016 - 16:22
fonte
0

Se per "è normale" chiedi se è comune, no, certamente non lo è. Molti team di sviluppo hanno pratiche di test scadenti (io appartengo a uno) e anche libri di qualità che ho letto consiglio di dedicare più o meno tempo a codificare la funzionalità rispetto ai test. Se normalmente si chiede se è sano, dipende, ma due volte più test del necessario è meglio di nessun test.

Non deve essere critico . Quando testate una funzionalità, provate qualcosa di utile per gli utenti finali, ed è vostra responsabilità sapere (e non indovinare) che funzioni sempre correttamente. Se hai bisogno di due volte di più per quell'obiettivo, allora dovrebbe essere fatto in questo modo - se possibile.

È anche possibile che la tua politica sia visivamente troppo rigida nei test automatici, ma è difficile dirlo senza conoscere la qualità a cui mirano, le loro risorse e cos'altro potrebbero essere assegnati.

    
risposta data 17.06.2016 - 19:03
fonte

Leggi altre domande sui tag