TESTING SOSTENIBILE

Ti sei mai fatto queste domande?

Come organizzi l’attività di testing?
Come si decide cosa deve essere testato?
Come si decide se e come automatizzare i test?
Come si esegue il test manuale?
Quante risorse dovrebbero essere dedicate ai test?

Queste domande riguardano tutte il problema diffuso di concettualizzare e implementare un processo di test che sia sostenibile. In questo post esploreremo cosa potrebbe significare.

Background

Il test del software è al centro della maggior parte delle attività svolte da un team di sviluppo software:

influenza il modo in cui i requisiti sono progettati (ad esempio perché il tester aiuta a convalidarli,
influenza il modo cui il programma funziona specifica vivente di un modulo software,
influisce sulla progettazione del sistema software (ad esempio perché i test migliorano la modularità e la testabilità del sistema)
influenza il modo in cui il team valuta quando lo sviluppo di un blocco di lavoro è completato (come quando i criteri di soddisfazione per le storie degli utenti sono formulati come test di accettazione).

Esistono diversi driver per i test, il più importante è ovviamente la capacità di crescere prodotti software con maggiore qualità e di trovare rapidamente nuovi bug importanti. Tuttavia, ci sono molti altri driver per i test, come l’obiettivo di migliorare la produttività e l’efficacia del team di sviluppo e l’obiettivo di ridurre il tempo di ciclo di un incremento di prodotto.

Inoltre, l’adozione di un approccio agile o devops, si enfatizza e si basa su una continua attività di test.

Test sostenibili

La mia visione di “test sostenibili” è di un processo di test che:

supporta gli obiettivi aziendali per i quali il prodotto software viene sviluppato. Tra l’altro, i test dovrebbero informare gli stakeholder aziendali sui rischi di qualità ancora esistere, dovrebbero aiutare a identificare il prodotto, dovrebbero aiutare a convalidare il prodotto, dovrebbero aiutare a fornire una documentazione.
supporta il team di sviluppo. Ad esempio, i test dovrebbero aiutare a prevenire la regressione della qualità, dovrebbero aiutare a ridurre i tempi di debug, dovrebbero aiutare nella localizzazione dei difetti, dovrebbero aiutare a sviluppare un sistema più modulare e testabile, dovrebbero aiutare a comprendere le esigenze e specifiche.
può essere eseguito rapidamente e frequentemente. In questo modo il feedback può essere ricevuto quando è necessario. Ad esempio, come programmatore, trarrei grande vantaggio dai risultati di 500 test di unità e componenti eseguiti in meno di 1 minuto dall’IDE che utilizzo per la codifica. Se i test sono veloci, possono essere eseguiti frequentemente, attivati manualmente o incorporati in un motore di integrazione continua
deve essere economicamente sostenibile. Le risorse per i test dovrebbero essere commisurate al beneficio che ne deriva. Per metriche obiettivo obiettivo è necessaria un’adeguata definizione degli obiettivi e delle politiche della strategia, degli approcci, dell’architettura e delle metriche di verifica.

Problematiche più comuni

Quali sono i motivi per cui non si realizza un test sostenibile?

Nella mia esperienza, basata su discussioni e interviste con diversi team di sviluppo e management, ho trovato quattro ostacoli principali.

Scarsa definizione del processo di test. Spesso non esiste una politica di test esplicita (ad esempio, sul perché fare test di unità), nessuna strategia esplicita che delinei i modi in cui le politiche devono essere implementate, nessuna definizione di ruoli relativi ai test per le persone, nessun piano di test. In cambio, spesso vediamo che i test sono lasciati all’iniziativa di pochi individui intrepidi, senza alcun coordinamento che porti a comportamenti divergenti. Non esiste una valutazione economica, nessun monitoraggio del processo di test, nessun obiettivo specifico e nessun piano per raggiungerli. Durante le situazioni di emergenza, qualunque sia il processo di collaudo in corso viene sospeso. Ci sono anche miti sui test difficili da smantellare. Un mito è che il testing ritardi il rilascio del prodotto: vero, ma solo quando il testing è gestito male. In effetti, un processo di test adeguatamente definito riduce il tempo di ciclo perché supporta il team. Un altro mito è che i test non siano utili, a causa del presupposto che potrebbero esserci solo pochi bug, con effetti minori. La legge di Finagle dimostra che non è così. Un mito simile è che il cliente non è disposto a pagare un extra per lo sforzo di test, perché non ha effetti visibili per il cliente. In effetti, le attività di test non dovrebbero essere separate dalle attività di sviluppo e il test dovrebbe sempre essere considerato parte integrante dello sviluppo del software.
Mancanza di una soluzione appropriata per l’automazione dei test del software. L’automazione dei test è un ingrediente necessario di una ricetta di sviluppo software agile. Potrebbe dover coprire diversi livelli di test (come test di unità, test di sistema, test di accettazione, test di fumo), potrebbe essere governato da una politica su più fronti (come una politica che impone lo sviluppo di test automatizzati ogni volta che viene rilevato un nuovo bug). riportato, così come secondo Test Driven Development), si baserà su diversi framework di test. Gli ostacoli includono una scarsa verificabilità della base di codice esistente (infatti, è possibile applicare diversi modelli di automazione dei test per affrontare il problema, come “oggetto umile”). Una cattiva implementazione di un approccio di automazione dei test potrebbe portare il management a percepirlo come un’attività che non fornisce valore, come lo sviluppo di un secondo sistema software che deve essere mantenuto accanto al sistema primario, come un altro assorbitore di tempo di sviluppo. A volte, la scarsa qualità del sistema di test porta a una pesante manutenzione della stessa base di codice, che diventa difficile da estendere, modificare, refactoring, verificare. Un altro importante fattore di blocco è dovuto alla gestione che concede poco tempo agli sviluppatori per imparare ad applicare strumenti e pratiche note.
Il terzo ostacolo principale è dovuto a un flusso di lavoro di test non ottimale. Le persone perdono tempo nella progettazione di casi di test scadenti che forniscono scarso valore (mentre la conoscenza di alcune tecniche di progettazione di test di base e un approccio basato sul rischio alla definizione delle priorità potrebbe migliorare notevolmente la situazione); si potrebbe perdere tempo nell’esecuzione manuale di casi di test che potrebbero essere automatizzati; i bug sfuggono al laboratorio perché non vengono impiegate tecniche efficaci come i test esplorativi; tempo è sprecato nella creazione di rapporti di prova che forniscono poco valore. Il tempo viene sprecato a causa di un muro tra programmatori e tester e tra analisti e tester: i tester potrebbero lamentarsi erroneamente che senza specifiche adeguate non possono eseguire test, i programmatori possono fornire con noncuranza artefatti software di bassa qualità perché sanno che qualcun altro alla fine li catturerà i problemi.
Infine la cattiva gestione. In effetti, alcuni manager faticano a capire che i test richiedono persone qualificate. Le competenze necessarie includono la capacità di gestire il processo, progettare casi di test, eseguire test esplorativi, automatizzare i test e queste competenze sono tecniche e difficili quanto quelle richieste da uno sviluppatore tipico. Quindi, un buon tester dovrebbe essere apprezzato quanto un buon sviluppatore. E nutrito, mi affretterei a dire. Nello sforzo di rispettare un budget, i manager spesso presumono che riducendo lo sforzo di test e/o riducendo la qualità del processo di test, otterrebbero in output lo stesso tipo di prodotto e lo stesso tipo di processo di sviluppo. Come di solito accade quando si tagliano gli angoli, questo non è vero. I test economici non sono test economicamente fattibili.