L'obiettivo dei team Agile e DevOps è di fornire in modo sostenibile nuove funzioni di qualità. Tuttavia, le metodologie di test tradizionali semplicemente non si prestano a un framework Agile o DevOps. Il ritmo di sviluppo richiede un nuovo approccio per garantire la qualità in ogni build. In Atlassian, testiamo in modo Agile. Dai un'occhiata dettagliata al nostro approccio ai test con Penny Wyatt, Senior QA Team Lead di Jira Software.

Proprio come avviene con una carta di credito, il debito iniziale è piccolo, ma presto cresce a dismisura, indebolendo il team in termini di agilità critica. Per contrastare la crescita incontrollata del debito tecnico, in Atlassian consentiamo (anzi: ci aspettiamo) che i nostri sviluppatori siano dei grandi sostenitori della qualità. Siamo convinti che gli sviluppatori apportino competenze chiave che aiutano a promuovere la qualità nel prodotto:

• Gli sviluppatori sono bravi a risolvere i problemi del codice.

• Gli sviluppatori che scrivono i propri test sono più inclini a correggerli in caso di insuccesso.

• Gli sviluppatori che comprendono i requisiti delle funzioni e le loro implicazioni di test generalmente scrivono codice migliore.

Riteniamo che ogni storia utente nel backlog richieda sia codice delle funzioni che codice di test automatizzato. Sebbene alcuni team assegnino agli sviluppatori il codice delle funzioni mentre il team di test esegue test automatizzati, riteniamo più efficace che un singolo ingegnere fornisca il set completo.

Questo modello non implica il fatto che gli sviluppatori lavorino da soli. È importante che il team includa anche ingegneri del controllo di qualità. Il controllo di qualità offre una prospettiva importante allo sviluppo di una funzione e gli ingegneri competenti sanno dove di solito si nascondono i bug e possono fornire agli sviluppatori dei consigli su probabili gotcha.

Nei nostri team di sviluppo, i membri del team di controllo di qualità collaborano con gli sviluppatori per condurre test esplorativi, una pratica preziosa per evitare bug più gravi durante lo sviluppo. Per questo motivo, analogamente alla revisione del codice, la conoscenza relativa ai test viene trasferita all'interno del team di sviluppo. Quando gli sviluppatori diventano tester migliori, viene fornito un codice migliore sin dall'inizio.

Ma i test esplorativi non sono test manuali? La risposta è no, quanto meno non nello stesso senso dei test di regressione manuali. I test esplorativi costituiscono un approccio verso i test basato sul rischio e il pensiero critico, e consentono alla persona che li esegue di utilizzare la propria conoscenza dei rischi, dei dettagli dell'implementazione e delle esigenze dei clienti. Conoscere questi aspetti in una fase tempestiva del processo di test consente allo sviluppatore o all'ingegnere del controllo di qualità di individuare i problemi in modo rapido e completo, senza che siano necessari casi di test con script, piani di test dettagliati o requisiti. Riteniamo che sia molto più efficace dei test manuali tradizionali, perché possiamo riportare le informazioni dalle sessioni di test esplorative al codice originale e ai test automatizzati. I test esplorativi sono anche utili in termini di esperienza di utilizzo della funzione e a tale riguardo offrono informazioni diverse rispetto a quelle fornite dai test con script.

Il mantenimento della qualità implica una combinazione di test esplorativi e automatizzati. Man mano che vengono sviluppate nuove funzioni, i test esplorativi assicurano che il nuovo codice soddisfi lo standard di qualità in un senso più ampio rispetto ai soli test automatizzati. Ciò include la facilità d'uso, un design visivo piacevole e l'utilità generale della funzione oltre alle solide protezioni contro le regressioni fornite dai test automatizzati.

Vorrei concludere con un aneddoto personale che sintetizza efficacemente la mia esperienza con i test Agile. Ricordo di aver gestito, all'inizio della mia carriera, un team di ingegneri che manifestava una forte resistenza alla scrittura di test automatizzati perché, a loro avviso, si tratta di un'attività riservata al controllo di qualità. Dopo aver condotto diverse iterazioni di codice con bug e ascoltato tutti i motivi per i quali i test automatizzati avrebbero rallentato il team, mi sono impuntato, pretendendo che tutto il nuovo codice venisse comprovato da test automatizzati.

Dopo una singola iterazione, il codice ha iniziato a migliorare. E lo sviluppatore che era più fermamente contrario alla scrittura di test alla fine è stata la persona che è entrata in azione quando un test non è riuscito! Nelle successive iterazioni, i test automatizzati sono cresciuti, sono stati adattati ai vari browser e hanno migliorato la nostra cultura di sviluppo. Certo, approntare una funzione ha richiesto più tempo. Tuttavia, i bug e le rilavorazioni sono diminuiti in modo significativo, facendoci risparmiare alla fine enormi quantità di tempo.

Cambiare raramente è facile. Tuttavia, analogamente alla maggior parte delle cose che vale la pena provare, se ti metti all'opera e crei nuovi schemi per te stesso, l'unica domanda che alla fine ti rimarrà è la seguente: "Perché non l'abbiamo fatto prima?"