Stiamo impiegando più tempo a implementare test funzionali che a implementare il 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 propri test unitari), i test funzionali per l'applicazione web impiegano molto tempo per essere implementati dagli sviluppatori. Intendo due volte, o talvolta più, il tempo necessario per implementare la funzionalità testata con unit test incluso.

La politica del gestore è di testare ogni singola funzionalità che aggiungiamo, anche se non è critica per l'azienda (ovvero un nuovo CRUD).

Sono d'accordo con il test di tutte le funzionalità dei servizi Web, poiché è difficile testarle manualmente e, inoltre, questi test vengono eseguiti rapidamente e non richiedono molto da implementare.

Quindi, qual è il valore nel dedicare più tempo a scrivere test funzionali, che a scrivere codice di sistema, test unitari e fissare tweet QA? È normale? Non dovremmo scrivere test funzionali solo per funzionalità critiche e lasciare che il QA esegua test di regressione su nessuna funzionalità critica?

Nota: non stiamo sviluppando software medico o software NASA o niente di così critico.

project-management testing functional-testing

— Pablo Lascano
fonte

14

Non abbiamo test. Dedichiamo molto tempo a sistemare le cose dopo il fatto. "Puoi pagarmi ora, oppure puoi pagarmi più tardi." È più tardi e non è carino.

— MetalMikester

3

Sì, parte del quadro è sicuramente che una suite di test ben gestita riduce il tempo necessario per l'implementazione effettiva.

— Michael Borgwardt,

possibile duplicato di Uno sviluppatore dovrebbe fungere anche da tester?

— moscerino

Possibile duplicato di È normale dedicare più tempo, se non di più, alla scrittura dei test rispetto al codice reale?

— moscerino

16

I test funzionali sono molto importanti. Sì, impiegano del tempo per scrivere ma se stai scrivendo i giusti test funzionali, ne varranno la pena.

Esistono alcuni buoni motivi per eseguire test funzionali automatizzati su un'applicazione.

Quando una nuova funzionalità viene aggiunta al tuo sito Web, ti viene subito comunicato se le modifiche apportate per quella nuova funzionalità interrompono qualsiasi altra funzionalità del tuo sito.
È una conoscenza documentata di come l'applicazione viene eseguita e lavora insieme per raggiungere i requisiti aziendali.
Quando è il momento di aggiornare una libreria di terze parti, puoi aggiornarla ed eseguire la tua suite di test funzionali per vedere se qualcosa non funziona. Invece di dover passare da solo ogni pagina, puoi avere un computer che lo fa per te e darti un elenco di tutti i test che si sono interrotti.
Test di carico! Puoi simulare migliaia di utenti simultanei che colpiscono tutti il tuo sito contemporaneamente e puoi vedere dove il tuo sito rallenta e si blocca sotto la pressione. Puoi vedere come il tuo sito web si comporta molto prima di ricevere una chiamata a tarda notte che il sito si è bloccato.
I test funzionali richiedono tempo per essere eseguiti manualmente. Sì, ci vuole molto per scrivere i casi, ma se dovessi sederti con un raccoglitore con 500 pagine di test che devi completare prima di poter spedire il prodotto, vorresti avere i test automatizzati!
I documenti di prova si aggiornano rapidamente. Quando viene aggiunta una nuova funzionalità, è necessario assicurarsi di aggiornare il documento di prova principale. Se qualcuno salta alcuni test all'improvviso ricevi dei bug che si insinuano in pagine che vengono "fatte e testate". Attualmente lavoro in un ambiente del genere, e posso assicurarti che è un incubo.

Alla fine, sì, ci vuole tempo per scrivere questi casi, ma dovresti essere orgoglioso di scriverli. È il tuo modo di dimostrare, oltre ogni dubbio che il tuo codice funziona e funziona con tutte le altre funzionalità disponibili. Quando il QA viene da te e ti dice che c'è un bug, lo risolvi e poi lo aggiungi alla tua suite di test per mostrare che è stato corretto e assicurarti che non accada mai più.

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

Per quanto riguarda la scrittura di test funzionali solo per le funzioni critiche del sistema. Questo non ti darà l'intera immagine e consentirà ai bug di intrufolarsi. Basta aggiungere una piccola funzione che non è critica per il sistema, ma interagisce indirettamente con una funzione critica del sistema e si ha il potenziale per introdurre un bug.

— Tyanna
fonte

grazie per la tua risposta. Sono consapevole dell'importanza e dei vantaggi dei test funzionali, le mie preoccupazioni riguardano il rapporto costi-benefici del test ALL. Abbiamo sviluppato test funzionali negli ultimi tre anni, ma ora in questo progetto, ritengo che il costo dell'implementazione del test ALL sia molto più che trovare un bug nella produzione, aumentare un ticket e risolverlo ... Mi chiedo se esistono alcune circostanze in cui NON è meglio fare un test funzionale (in termini di costi-benefici) che non farlo, e mi chiedo se siamo in tali circostanze, dove è meglio scegliere saggiamente cosa testare.

— Pablo Lascano,

@donsenior ~ se ritieni che ci voglia troppo tempo per testarlo, guarda gli strumenti che stai utilizzando. Li stai usando correttamente? Stai usando anche strumenti per risparmiare tempo? La scrittura dei test richiede più tempo rispetto alla scrittura del codice b / c che si ha più codice da scrivere. Questa è la natura del test. Se inizi a scegliere e scegliere per cosa scrivere i test, arriverai al punto in cui nessuno scriverà i test o quei test saranno sciatti.

— Tyanna,

la mia idea di scegliere cosa testare, non è una scelta casuale, ma scegliere la funzionalità aziendale più critica (e questa non sarebbe una decisione degli sviluppatori, ma del manager). E penso proprio il contrario, gli sviluppatori tendono a scrivere test sciatti ora perché devono testare tutti, anche quella funzionalità che richiede cinque minuti per testare il QA e due giorni per automatizzare gli sviluppatori. Sono d'accordo che forse gli strumenti che stiamo usando non sono i migliori per testare la nostra app Web (fitnesse e java). Temo che ci stiamo avvicinando al punto di scrivere e mantenere il test funzionale più del sistema

— Pablo Lascano,

@donsenior ~ Certo, sono necessari 5 minuti di QA per testare un caso, ma un computer impiega meno di un secondo per testarlo. Dovresti chiedere "Perché ci vogliono 2 giorni per scrivere qualcosa che richiede 5 minuti per testare manualmente"? Ancora una volta, guarda i tuoi strumenti. Forse anche il QA dovrebbe scrivere alcuni casi di test? Il problema non è scrivere casi di test per il tuo sistema, è come vengono scritti quei casi di test.

— Tyanna,

bene questo test richiede molto più di un secondo per essere eseguito (ricordate che si tratta di test funzionali, non di unit test). Ma non è un problema, corrono di notte. Penso che tu abbia ragione nel dire che anche il QA dovrebbe scrivere alcuni casi di test, ma purtroppo non è una decisione che posso prendere. Grazie mille per le tue risposte, ho contrassegnato questo come accettato!

— Pablo Lascano,

7

Più di 2 volte ... mi sembra un po 'troppo. Potresti voler analizzare le ragioni di ciò, potrebbero includere:

cattivo supporto degli strumenti per la creazione e la manutenzione dei test
i contratti dei servizi web non sono sufficientemente descritti nella progettazione. Gli sviluppatori devono elaborare i contratti durante i test, che di solito è un processo di allineamento che richiede tempo.

Parla con i tuoi sviluppatori.

Supponendo che tu stia sviluppando negli sprint, avendo questi test funzionali se solo una parte dello sprint. Non è stato fatto senza questi test. Se non lo hai, il tempo per i test di integrazione dopo la fase di sviluppo potrebbe raddoppiare.

— Andreas Huppert
fonte

Sono d'accordo, forse non stiamo usando lo strumento giusto per testare l'app Web. Nessun problema durante il test dei nostri servizi Web. Ad ogni modo, oltre al giusto o sbagliato di come implementiamo i test, sono preoccupato per i costi. Penso che a questo punto, sia meglio (in termini di costi / benefici) lasciare alcuni test per il dipartimento di controllo qualità e correggere i bug anche se si trovano in produzione.

— Pablo Lascano,

Hai lasciato fuori le lezioni mal progettate come possibile ragione per impiegare troppo tempo a testare. Questo è di gran lunga il motivo più comune che vedo quando le persone prendono per sempre il test del loro codice.

— Dunk

4

Trascorrere più tempo nell'implementazione del test funzionale rispetto all'implementazione del sistema stesso è normale?

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

— Michael Durrant
fonte

2

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

I test unitari sono in codice, quindi conterranno 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 risolverli è un onere continuo.

1

Si tratta di qualità.

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

Ma se sai che il tuo auditory non andrà via, farai tutto il possibile per non deluderli. Ogni ticket bug ridurrà la tua reputazione. Immagina che un bug rimuoverà il 50 percento della tua reputazione, il successivo - un altro 25 percento e così uno. Quindi possono esserci troppi test?

— Nikita U.
fonte

beh non sono proprio sicuro se a questo punto stiamo effettivamente riducendo i biglietti. Forse abbiamo ridotto (ma non molto) i ticket QA, ma la percentuale di bug rilevati da questo test non è abbastanza grande (dal mio punto di vista) per giustificare tale costo di avere 2/3 di ingegneri software che sviluppano test funzionali.

— Pablo Lascano,

0

Se con "è normale" chiedi se è comune, no, certamente non lo è. Molti team di sviluppo hanno pratiche di test scadenti (io appartengo a uno) e persino libri di qualità che ho letto consigli di dedicare più o meno tempo alla codifica della funzionalità rispetto ai test. Se normalmente chiedi se è salutare, dipende, ma due volte più test del necessario è meglio di nessun test.

Non deve essere critico . Quando si verifica una funzionalità, si verifica qualcosa di utile per gli utenti finali ed è responsabilità dell'utente 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 severa nei confronti dei test automatizzati, ma è difficile dirlo senza conoscere la qualità a cui mirano, le loro risorse e cos'altro potrebbero indirizzarlo.

— Arthur Havlicek
fonte