Quando si assume un approccio di sviluppo agile, è ovvio implementare le funzionalità solo quando necessario. La mia domanda è: può lo stesso essere applicato quando si tratta di test, cioè creando casi di test e solo test quando necessario, o è una cattiva idea?
My question is: can the same be applied when it comes to testing, i.e. creating test cases and only test when necessary, or is that a bad idea?
Non penso che necessario sia una buona scelta di parole qui, sia che tu stia parlando di test o funzioni. Molto spesso, le funzionalità non vengono aggiunte al software perché sono necessarie , vengono aggiunte perché sono utili o preziose o < em> desiderabile . Le funzionalità vengono aggiunte perché rendono il prodotto migliore con alcune metriche importanti per gli stakeholder.
Lo stesso vale per i test, e in misura ancora maggiore. I test sono separati dal prodotto testato, quindi non hanno alcun impatto diretto sulla sua funzionalità e non sono certamente necessari per il funzionamento del prodotto. I test sono solo strumenti che aiutano gli sviluppatori e le altre parti interessate a mantenere un livello costante di qualità. I test possono aiutare a garantire che il prodotto soddisfi i requisiti; possono rilevare i guasti; possono risparmiare tempo e denaro; ecc. In breve, i test sono spesso utili, preziosi e desiderabili, anche se in realtà non sono necessari .
L'idea con uno sviluppo agile è quella di costruire un prodotto minimo vitale e quindi di iterare su quello per migliorarlo in qualsiasi direzione le decisioni degli stakeholder siano più importanti. Puoi applicare la stessa filosofia ai test: inizia con un set di test di base che ti dà il massimo beneficio e poi migliora iterativamente nella direzione del massimo beneficio.
Spesso i test saranno sviluppati parallelamente a nuove funzionalità, perché i test possono essere uno strumento utile durante lo sviluppo. Ad esempio, un'idea importante nello sviluppo agile è avere una comprensione comune di cosa significhi per un compito fatto , ei test sono un modo per stabilire la definizione di fatto e per dimostrare che hai soddisfatto i requisiti. Ma i test possono anche essere sviluppati in seguito, magari per dimostrare un bug o per aumentare la fiducia che il prodotto si comporta in modo coerente.
Si prega di notare che sono prevenuto come tester.
Direi ALMENO stabilire un piano di test di base nelle prime fasi del processo di sviluppo è molto importante, e i tester dovrebbero essere coinvolti nella discussione di nuove funzionalità per essere più avanti nel gioco quando si tratta di implementare come queste funzionalità saranno aggiunto nel piano di test.
Quanto prima puoi iniziare a testare, tanto prima prendi gli errori che sembrano casi limite, ma alcune migliaia di righe di codice diventano in seguito dei mammut difficili da individuare. È più facile risolvere questi problemi quando sono isolati piuttosto che quando sono connessi ad altri metodi, oggetti o intere funzionalità.
Una risposta pragmatica:
Quando si sviluppano nuove funzionalità, TDD (sviluppo basato su test), può accelerare lo sviluppo:
Non tutti i metodi secondari, e non integrati pesantemente, ma come aspetti indipendenti facilmente combinabili. Altrimenti un altro approccio nella codifica, una piccola riprogettazione come richiesto dal codice non test effettivo richiederebbe dei test di riscrittura.
Quindi scrivi il codice non test.
Questo lascia alcuni metodi degli aspetti di basso livello non testati. Tuttavia ci sono buone possibilità che i casi d'uso di alto livello coprano già la verifica della funzionalità di questi aspetti.
Ultimo ma non meno importante: se si utilizzano build di integrazione con Jenkins, uno strumento di analisi del codice come SonarQube ammonirà una copertura di test mancante . Poi probabilmente si dovrebbe accettare arbitrariamente una copertura dell'85% come rapporto prestazioni / costi "ottimale", oppure lavorare in modo subottimale e fare una copertura del test totale .
Per ricapitolare:
Assolutamente. Esegui il test solo se necessario. Ma rallentare: il test è sempre necessario.
Scherzi a parte, il momento più recente nel quale è necessario testare il software è dopo aver pensato che una attività è terminata e prima di iniziare l'attività successiva. Perché questo è il punto in cui i bug appena introdotti provengono dalla funzionalità che è fresca nella tua mente, quindi il numero delle possibili cause è limitato e le cause sono più facili da esaminare.