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

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.

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.

È 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.

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?

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.

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.