Leadership nel Test: Il Testing Come Squadra

A volte può significare l’assenza totale di tester (dun-dun-duuu), con analisti di business e sviluppatori che si assumono la piena responsabilità del testing.

Lo shift-left non è una novità—gli esperti di testing predicano il mantra "testare presto, testare spesso" da molti anni. Già nel 1993, si suggeriva che tutti gli artefatti in un processo a fasi—sia documentali che software—potessero (e spesso dovessero) essere testati.

Lo Shift-Left riguarda soprattutto il portare il pensiero sul testing all’inizio del processo.

Sebbene il modello Waterfall fosse l’approccio di ciclo di vita dominante all’epoca, il numero o la durata delle fasi non è ciò che conta. Il principio sottostante era che le fonti di conoscenza che guidano la progettazione e lo sviluppo del software andrebbero sempre messe in discussione o testate. 

In un progetto a fasi, ciò potrebbe comportare revisioni formali. In un progetto Agile, il tester (o sviluppatore, o analista di business o utente) può proporre scenari che spingano l’autore di un requisito o di una storia a riflettere su esempi concreti e discuterli prima che venga scritto qualsiasi codice.

Questi sono i principali cambiamenti coinvolti nel fenomeno shift-left:

1. L’approccio Behavior Driven Development (BDD) ha consentito a sviluppatori, utenti/analisti di business, e tester di confrontarsi su ciò che potremmo chiamare storie di business. Il Test-Driven Development viene utilizzato da molti sviluppatori da oltre 15 anni. Oggi, il BDD sta venendo adottato sempre più spesso perché favorisce una migliore collaborazione nei team agili e introduce anche strumenti BDD utilizzabili dagli sviluppatori. È un approccio Test-First più semplice.
2. Il Continuous Delivery (CD) esiste da 5-10 anni e le sue radici sono nelle pratiche di costruzione e rilascio automatico adottate dalle grandi imprese online. Ora viene usato dalla maggior parte delle organizzazioni che hanno una presenza online.
3. Il CD ha sistematizzato e accelerato il processo di rilascio tramite l’automazione. Ma ha anche evidenziato i ritardi nella produzione, nel deploy e nel cambiamento infrastrutturale che prima erano nascosti da processi di build, test e rilascio lenti. DevOps è un cambiamento di mentalità culturale in cui gli sviluppatori collaborano molto più strettamente con il personale delle operations. Adesso compaiono nuovi strumenti quasi ogni giorno e i fornitori promuovono DevOps come la "prossima grande cosa". È una situazione molto pubblicizzata e dinamica.
4. SMAC, ovvero Social, Mobile, Analytics e Cloud, rappresenta un cambiamento nel modo in cui le organizzazioni gestiscono il business e il cambiamento dei sistemi nello spazio mobile. La sperimentazione in ambito di business, implementata attraverso cambiamenti dei sistemi in produzione, viene monitorata a livello dettagliato. I "Big" dati raccolti vengono processati e le decisioni aziendali sono prese in base alle analisi ottenute.

La continua sperimentazione sui sistemi in produzione consente l’innovazione aziendale "alla velocità del marketing". La sperimentazione è al cuore di quello che è stato il trend più importante degli anni 2010: la Trasformazione Digitale.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Company

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Il testing come attività, non come ruolo

Lo shift-left cambia il ruolo dei tester. La redistribuzione del testing, innescata dall’approccio shift-left, chiarisce che i tester non sono più i soli responsabili dei test, ovvero i tester non "possiedono" più il testing. 

Se ci pensate, in realtà non hanno mai davvero posseduto il testing, ma nei progetti c'era una comprensione tacita che, qualunque cosa facesse il resto del team, in particolare gli sviluppatori, nei test, i tester fornivano una rete di sicurezza. Se gli sviluppatori erano sotto pressione per il tempo e riducevano i test per consegnare, la rete di sicurezza era fornita dai tester.

Il testing è ora un'attività, non un ruolo.

Gli sviluppatori stanno adottando migliori pratiche di test e maggior visibilità sul proprio lavoro. Un buon testing a livello di componente o unità ha obiettivi specifici diversi dal testing di sistema (ad esempio). Pertanto, lo scopo (o quantità) del testing a livello di sistema può essere ridotto. 

La corretta distribuzione degli obiettivi di testing, e il testing orientato al raggiungimento di tali obiettivi, è lo scopo principale della strategia di test. Sfortunatamente, fino a poco tempo fa, gli sviluppatori non erano ritenuti effettivamente responsabili, quindi facevano affidamento su test di sistema tardivi per compensare.

Lo shift-left rende gli sviluppatori più responsabili.

In generale, la responsabilità del testing viene redistribuita e il ruolo del tester cambia. I tester potrebbero affidarsi meno a test tattici, ma il loro contributo strategico aumenta. I tester possono possedere la strategia di test, sfidare i requisiti, consultarsi con gli stakeholder e instaurare una relazione più stretta con gli sviluppatori per supportare un miglior testing da parte degli sviluppatori e l'automazione dei test.

Un nuovo ruolo

Lo shift-left implica che, ogni volta che è possibile fornire un feedback che aiuti il team a comprendere, mettere in discussione e migliorare obiettivi, requisiti, design o implementazione, quel feedback dovrebbe essere fornito. 

Utenti, analisti di business, sviluppatori e tutto il team software dovrebbero essere pronti a scambiarsi feedback in questo modo. Talvolta c'è resistenza, ma l’obiettivo generale è gestire un progetto migliore e più informato—tutto qui.

Il modo più semplice per riassumere questo comportamento è: 'coinvolgetevi presto'—il più presto possibile. Partecipate alle discussioni e collaborate su idee, requisiti e in tutte le fasi in cui l’esito di quella fase incide sul valore del risultato finale del progetto. 

Semplicemente, il tester mette alla prova le fonti di conoscenza, che si tratti di stakeholder, utenti, sviluppatori, storie di business, documenti o precedenti.

L’approccio più comune è mettere alla prova tramite esempio. In tutte le fasi, questi esempi possono essere considerati come test. Potrebbero essere scartati rapidamente dopo l’uso o codificati in test automatizzati o controlli manuali. Questi esempi potrebbero essere utilizzati tatticamente per evidenziare difetti nel ragionamento delle persone, oppure essere forniti agli sviluppatori, ad esempio, come idee o spunti per test degli sviluppatori. Potrebbero anche essere utilizzati come strumenti di coaching per mostrare a utenti o sviluppatori come creare test migliori.

Considerate il vostro progetto software come un processo di acquisizione della conoscenza. Questa conoscenza viene raccolta durante tutto il progetto e spesso evolve nel tempo. L’obiettivo dello shift-left è assicurare questa conoscenza tramite sfida e testing il più vicino possibile alla fonte, e garantire, dove possibile, che sia affidabile prima che venga fissata nel codice.

Lo shift-left porta la filosofia del test-first ancora oltre. L’agile ha sempre promosso la collaborazione e il feedback rapido—lo shift-left può essere visto come un approccio concertato di rapid feedback. Se il vostro team sta adottando una strategia shift-left per il testing, avere gli strumenti giusti può fare la differenza. Scoprite la nostra lista curata di strumenti per software testing per trovare quelli più adatti al vostro team.

Interventi di test in Agile

L’approccio shift-left è fondamentale per una strategia di test nei progetti agile. In un contesto agile, la strategia di test può essere vista come una serie di interventi di test. In tutti i progetti ci sono momenti critici in cui si presentano opportunità di raccogliere e fornire feedback. Il tester deve concentrarsi su questi momenti critici ed essere pronto a contribuire in quei momenti.

Nei vostri progetti, dovete individuare i momenti critici in cui è possibile intervenire e identificare le scelte che potete fare quando testate come team. Ad esempio, il tester dovrebbe scrivere test unitari per gli sviluppatori, fornire esempi per iniziare o fare coaching agli sviluppatori per migliorare la loro capacità di testing? Solo voi e il vostro nuovo team di software testing potete deciderlo.

Useremo un tipico processo Scrum per mostrare come gli interventi di test possano essere posizionati nell’approccio Scrum. Gli interventi si verificano sia a livello di progetto (o rilascio), sia a livello di sprint. Il diagramma seguente mostra una panoramica a livello di progetto e i cinque interventi chiave.

La challenge delle storie e la definizione delle storie sono i momenti in cui il tester valida una user story e i criteri di accettazione proposti per una storia, rispettivamente. I test di integrazione verificano che le nuove funzionalità si colleghino correttamente con le altre funzionalità e con il sistema nel suo complesso. I test di sistema e di utente (accettazione) vengono effettuati secondo necessità.

Un progetto di solito ha più sprint e i quattro interventi di sprint sono mostrati nel diagramma qui sotto. Il daily stand-up è un'opportunità per riportare i progressi, sollevare preoccupazioni, identificare rischi o discutere domande emerse e risposte ricevute durante lo sprint. 

La rifinitura delle storie e i contributi al testing degli sviluppatori sono attività quotidiane che avvengono come parte delle discussioni con utenti, analisti e sviluppatori. Il tester incorpora i test degli sviluppatori e i nuovi test di sistema in una raccolta crescente di test da automatizzare.

Nella tabella qui sotto, puoi vedere un riepilogo tabellare degli interventi dei tester. Il tuo processo potrebbe essere diverso o basato su Scrum con variazioni, ma la tabella identifica i tipi tipici di intervento in un processo Scrum standard. Potresti avere più o meno interventi attivi in momenti diversi all'interno del tuo processo unico.

Ti consiglio di individuare i momenti critici, proporre il tuo contributo e negoziare con il team. Offri più leadership e guida nei test piuttosto che proporti semplicemente per assumerti la responsabilità del lavoro di testing. Adottando questo approccio sarà molto più facile dimostrare il tuo valore al team, anche se il team potrebbe non avere bisogno di tanti tester.

Relazioni con gli sviluppatori

In alcune organizzazioni, la relazione tra sviluppatori può essere diffidente, piena di colpe e antagonista. Nel peggiore dei casi, la relazione è tossica: gli sviluppatori non testano quasi mai e i tester sono considerati come servitori degli sviluppatori. I tester adottano quelli che possono essere definiti comportamenti co-dipendenti e si comportano come vittime. È proprio questa situazione che l’approccio shift-left punta a evitare.

Esistono molte metafore usate per descrivere una buona relazione tra sviluppatore e tester. Useremo il modello pilota-navigatore per illustrare come può funzionare una relazione comparabile tra sviluppatore e tester. Ma prima, vediamo una situazione disfunzionale.

Il navigatore non sale sull’aereo, ma saluta il pilota mentre decolla. Il navigatore viaggia in autobus, separatamente e più lentamente. Alla fine, il navigatore arriva a destinazione, ma dopo un po’ si scopre che l’aereo ha volato nella direzione sbagliata ed è finito contro una montagna.

Sicuramente il navigatore avrebbe dovuto essere a bordo dell’aereo, no? Immagina come piloti e navigatori lavorano insieme nella realtà.

• Il pilota non può pilotare l’aereo senza il navigatore. Il navigatore non può pilotare l’aereo.
• Pilota e navigatore concordano il piano di volo prima della partenza.
• Il pilota decolla e pilota l’aereo.
• Il navigatore tiene traccia del percorso e lo confronta con il piano di volo e/o la destinazione finale, tenendo conto degli eventi avversi, in particolare il meteo.
• Il navigatore cerca deviazioni, traccia una nuova rotta e avvisa il pilota che adegua il tragitto dell’aereo.
• E così via.

Il rapporto tra pilota e navigatore è simile a quello tra programmatore e tester. Separare sviluppatori e tester in team distinti che lavorano in sequenza non ha senso nemmeno in questo caso. Eppure, è ciò che abbiamo fatto convenzionalmente negli ultimi trent’anni circa, soprattutto nei progetti più grandi e a lungo termine.

Lo shift-left ridistribuisce la riflessione sui test e di fatto la anticipa. I tester agiscono come partner a pieno titolo per gli sviluppatori, proprio come fanno i navigatori con i piloti:

• Tester e sviluppatore raccolgono insieme le informazioni sui requisiti.
• Tipicamente, il tester mette in discussione i requisiti con esempi (idee di test potenziali o reali).
• Lo sviluppatore pensa all’implementazione, usando gli esempi per orientare il proprio design.
• Tester, sviluppatore, stakeholder, utenti e analisti concordano una comprensione condivisa di un requisito affidabile.
• Il tester è in comunicazione costante con lo sviluppatore, discutendo modifiche ai requisiti, rischi di fallimento e come i test possono mostrare il corretto funzionamento delle funzionalità o rivelare guasti.
• Il tester analizza come la funzionalità su cui si sta lavorando si integrerà sia a livello tecnico che di percorso utente e come l’integrazione può essere testata.
• Il tester guarda oltre la singola funzionalità su cui lavora lo sviluppatore per identificare futuri rischi, sfide, cambiamenti e incertezze.
• E così via.

La relazione ideale tra sviluppatore e tester appena descritta non si verifica automaticamente. Va costruita dal team. Puoi considerare ognuna delle attività sopra come interventi, ma questi non sono sempre confortevoli per tutte le parti. Dai a questo approccio la migliore possibilità di successo discutendo ciascun tipo di intervento con i tuoi collaboratori fin dall’inizio, cioè quando sai che lavorerai a stretto contatto con loro.

Gli interventi, come le buone user story, sono inneschi per le conversazioni.

Ogni tipo di intervento richiede il consenso di entrambe le parti che si tratti di un’azione valida da intraprendere. Per sentirsi a proprio agio, ciascuno deve poter avere fiducia che dall’altra parte ci sia una buona ragione per fare domande, sollevare problemi e mettere in discussione requisiti o comprensione nelle daily, nelle pianificazioni o nelle retrospettive.

Le sfide dei team distribuiti e in outsourcing

Nelle discussioni precedenti si è dato tacitamente per scontato che tutti lavorino nello stesso team e nello stesso luogo. Quando il carico di lavoro di un team di test del software viene esternalizzato e/o delocalizzato, entrano in gioco diversi fattori negativi. La tabella mostra tre fattori tipici da considerare.

Alcune aziende rafforzano i team di test software già esistenti per aumentare la capacità in progetti più grandi, oppure preferiscono assumere aziende specializzate di testing invece di affidarsi a collaboratori o al personale interno per le attività di test. In altre situazioni, tutto lo sviluppo e/o il testing possono essere affidati ai fornitori. In tutti i casi, l’azienda cliente deve gestire i suoi fornitori. Questo non significa che sia sufficiente scrivere un contratto restrittivo con dure clausole penali.

Quando le cose vanno male, vuoi risposte rapide e collaborazione dal tuo fornitore; non vuoi che si nasconda dietro le clausole legali del contratto.

I segreti del successo sono:

• Se non gestisci il tuo fornitore, sarà lui a gestire te (se non siete partner alla pari e lasci al fornitore la definizione dei termini, il fornitore avrà tutto il potere).
• L’obiettivo è definire una buona relazione lavorativa. Questa deve essere stabilita a tutti i livelli, stakeholder, manager e operatori.
• I contratti devono essere redatti in modo da individuare tutte le responsabilità di entrambe le parti, con misure, soglie, pagamenti a scaglioni e criteri di accettazione opportunamente definiti per incoraggiare i comportamenti positivi (da entrambe le parti).
• Gli accordi dovrebbero favorire la trasparenza e la condivisione dell’obiettivo comune del successo del progetto.

Spunti di riflessione

E infine, alcune domande per stimolare la riflessione. 

Che rapporto hai come tester con i tuoi sviluppatori? Oppure, se sei uno sviluppatore che sta leggendo, che rapporto hai con i tester? Chiedi magari ai tuoi colleghi di sviluppo o test come descriverebbero il vostro rapporto. Confronta le risposte!

Perché i team di test del software siano produttivi, devono comunicare e collaborare.