Immagina che il software più importante della tua azienda smetta improvvisamente di funzionare. Cosa succederebbe? Gli ordini potrebbero andare persi, le scadenze potrebbero non essere rispettate, ma i clienti si lamenterebbero sicuramente.
Questo scenario da incubo è evitabile: implementando un processo di test continuo e rigoroso, che rileva i problemi prima che causino il caos. Tuttavia, implementare un processo di questo tipo nella tua organizzazione è più facile a dirsi che a farsi.
Questo articolo ti mostrerà tutto ciò che devi tenere in considerazione quando inizi a eseguire test nella tua azienda e come puoi trarre vantaggio dai test a lungo termine.
Best practice per i test per i team di prodotto
La prima parte di questo articolo illustra la procedura per iniziare a implementare i test nel tuo flusso di lavoro.
Implementare una cultura dei test nel team
Per introdurre correttamente i test nel tuo team, è necessario che tutti condividano una mentalità comune e considerino la qualità non come un peso, ma come un investimento. Come ogni altro cambiamento culturale, questo processo richiede tempo e coerenza.
Una cosa che può contribuire a plasmare questa cultura sono le riunioni regolari per discutere dei difetti, del loro impatto, della loro origine e di cosa è stato necessario fare per correggerli. In questo modo si crea consapevolezza del motivo per cui è bene prevenire questi difetti in primo luogo.
Avere una persona dedicata nel team che supervisiona e guida l'impegno può aumentare notevolmente le probabilità di successo. Qualcuno che definisce le linee guida del team o persino dell'intera organizzazione, raccoglie le best practice, le condivide e promuove l'impegno a tutti i livelli.
Un altro strumento utile può essere quello di ruotare il ruolo di assistenza del tuo prodotto. Ottenere informazioni di prima mano e non filtrate dai clienti e conoscere i problemi quotidiani che riscontrano con il tuo prodotto può essere un'esperienza preziosa per product manager, progettisti e sviluppatori.
L'obiettivo è che tutti i membri del team comprendano che la qualità è una funzionalità, importante quanto qualsiasi altra funzionalità che crei per il tuo prodotto. Una volta che tutti hanno adottato questa mentalità, è una progressione naturale capire che anche i test sono una funzionalità, perché sono i test a garantire la qualità spedita.
Una procedura di test passo passo
Una volta raggiunto l'allineamento tra i diversi team coinvolti nello sviluppo del prodotto, puoi formalizzare ulteriormente l'esistenza e l'utilizzo dei test.
Inserire i test nella "Definizione di completamento"
Aggiungendo i test come requisito di una funzionalità, dichiari che una funzionalità non è pronta per la spedizione finché non viene testata correttamente e automaticamente.
Eseguire i test regolarmente
Una volta implementati, i test automatici possono essere la tua salvaguardia in ogni fase del processo di sviluppo. Non richiedono alcun intervento umano e possono essere eseguiti in ogni fase critica della pipeline di sviluppo. Ad esempio:
- Su ogni commit.
- Su ogni richiesta di pull.
- Dopo ogni release completa o modifica dell'ambiente.
Se ti affidi a servizi di terze parti nel tuo ambiente di produzione, può persino avere senso eseguire i test in produzione per assicurarti che le API di terze parti si comportino come previsto.
Definire e raccogliere le metriche
La definizione di un insieme di metriche è importante per misurare l'efficacia dei test e l'impatto dei workflow di test sulla tua attività. Ecco alcuni esempi di metriche che puoi utilizzare:
- Release al mese: un numero maggiore di release al mese può indicare un processo di sviluppo più agile. I test automatici svolgono un ruolo chiave in questo caso, in quanto garantiscono che le release possano procedere con sicurezza.
- Segnalazioni di bug: una tendenza alla diminuzione delle segnalazioni di bug può essere un segnale positivo dell'efficacia dei processi di test (e di sviluppo).
- Copertura dei test: sebbene non sia mai una metrica esatta, la copertura può essere un buon indicatore della profondità con cui stai testando i casi d'uso critici.
Tieni presente che queste metriche sono influenzate anche da altri fattori che potrebbero distorcerle. Ad esempio, il numero di release potrebbe diminuire durante le festività, mentre le segnalazioni di bug aumentano. Quindi non fare affidamento solo su alcune e assicurati di incrociarle con altri dati a disposizione del tuo team.
Se implementi correttamente questi passaggi con il tuo team, la salute del tuo prodotto ne trarrà sicuramente vantaggio a lungo termine. Ma c'è ancora molto altro che puoi fare.
Best practice per i test per gli amministratori di sistema
I team di prodotto non possono lavorare da soli. Si affidano all'hardware, agli strumenti e all'infrastruttura gestiti dagli amministratori di sistema. Sebbene in genere gli amministratori di sistema non contribuiscano direttamente allo sviluppo del prodotto, possono comunque influenzare positivamente il flusso di lavoro di sviluppo. Ad esempio, gestendo attivamente la versione del browser utilizzata da determinati gruppi di utenti dell'azienda.
Questa seconda parte dell'articolo spiega come funziona, utilizzando i canali e i criteri aziendali di Chrome.
Canali di rilascio di Chrome
Per impostazione predefinita, Chrome si aggiorna automaticamente per garantire che ogni utente utilizzi la versione più recente, stabile e sicura di Chrome, incluse tutte le funzionalità più recenti: la versione di Chrome rilasciata sul canale stabile.
In qualità di azienda che sviluppa un prodotto basato sul web, potresti voler utilizzare un browser prima del canale stabile, per dare ai tuoi team di prodotto il tempo di adattare il tuo prodotto alle modifiche della piattaforma web.
Per questo caso d'uso, Chrome offre un totale di quattro canali di rilascio, destinati a diversi gruppi di utenti.
Nel caso di Chrome, puoi utilizzare diversi canali di rilascio per anticipare le modifiche future del browser e testare le funzionalità più recenti prima che siano disponibili a livello generale:
- Canale stabile: è qui che si trova la maggior parte degli utenti. Il canale stabile si aggiorna automaticamente quando viene rilasciata una nuova versione di Chrome, cosa che avviene mensilmente.
- Canale beta: questa versione diventerà stabile tra quattro e sei settimane, offrendoti la possibilità di visualizzare in anteprima e testare una release stabile imminente e prepararti per essa.
- Canale Dev: questo canale riceve una nuova versione di Chrome una volta alla settimana e include tutte le correzioni più recenti che verranno spostate nella versione beta. Come suggerisce il nome del canale, è in fase di sviluppo e potrebbe quindi interrompersi in modo imprevisto, ma include anche le funzionalità più recenti, a volte molto prima che vengano incluse nella versione stabile. Questo rende il canale Dev uno strumento ideale per la prototipazione e lo sviluppo all'avanguardia.
- Canale Canary: il canale più sperimentale, contenente tutte le funzionalità più recenti, ma senza molti test. Viene rilasciato almeno una volta al giorno.
Se vuoi saperne di più sui canali di Chrome, guarda l'episodio di Chrome Concepts pertinente .
Utilizzare i canali in un'organizzazione esemplare
La struttura dei team di prodotto varia da un'organizzazione all'altra, poiché non esiste un approccio unico allo sviluppo software. Ad esempio, supponiamo di avere un team con i seguenti ruoli: gestione dei prodotti, UX e UI, ingegneria, operazioni e assistenza.
Per un'organizzazione di questo tipo, puoi pensare alla seguente suddivisione dei canali:
- Gestione dei prodotti: in genere i PM possono utilizzare il canale stabile, in modo da utilizzare la stessa versione della maggior parte degli utenti. Occasionalmente potrebbero utilizzare il canale beta o Dev se stanno lavorando a una funzionalità che richiede un'API non ancora lanciata.
- Ingegneria e UX: alcune parti di questi team possono utilizzare il canale Dev, per avere accesso alle funzionalità più recenti, come le transizioni di visualizzazione, anche prima che siano incluse nella versione stabile.
- Operazioni: potrebbe utilizzare la versione beta, per prevedere interruzioni che influiranno sugli utenti in futuro.
- Assistenza: può rimanere sul canale stabile, per assicurarsi di interagire con il prodotto con lo stesso browser della maggior parte dei clienti.
Utilizzare i criteri aziendali per gestire i canali
Anziché fornire linee guida e lasciare la decisione su quale canale utilizzare, Chrome offre anche strumenti aziendali e di amministrazione per gestire attivamente il canale che ogni utente finirà per utilizzare. Questo è utile perché aumenta immediatamente la superficie di test da pochi singoli a un insieme deterministico di utenti, il che aiuta a identificare le interruzioni il prima possibile e in modo tracciabile.
Se vuoi utilizzare questo livello di controllo, ecco la configurazione che ti consigliamo:
- Dipendenti (utenti dell'app): per ridurre al minimo il rischio di interruzioni, la maggior parte dei dipendenti dovrebbe utilizzare il canale stabile, che è stato completamente testato dal team del testing di Chrome. Inoltre, una piccola percentuale di utenti (dal 5 al 10%) può utilizzare il canale beta. Questo canale offre un'anteprima di 4-6 settimane della versione stabile e può aiutare gli amministratori a scoprire potenziali problemi con una release, dando più tempo per risolvere i problemi prima che la release venga implementata per tutti gli altri utenti.
- Reparto IT: i membri del reparto IT, inclusi gli amministratori di sistema possono utilizzare il canale beta o Dev per ottenere un'anteprima di 4-6 o 9-12 settimane delle funzionalità che verranno incluse nella versione stabile di Chrome.
Canali di rilascio a lungo termine
Lo sviluppo del prodotto potrebbe non procedere alla velocità prevista e la cadenza di rilascio di Chrome di un mese potrebbe essere troppo elevata. Per questo caso d'uso, Chrome fornisce un canale stabile esteso che consente di ricevere aggiornamenti delle funzionalità con minore frequenza, ma di continuare a ricevere correzioni per la sicurezza. Questo canale viene aggiornato ogni otto settimane.
Il seguente diagramma mostra come le diverse versioni principali procedono attraverso i diversi canali di rilascio di Chrome:
- Sia la versione stabile sia quella stabile estesa vengono spedite con le stesse versioni per le prime quattro settimane, dopodiché le due versioni divergono.
- Non esiste un canale beta esteso; al contrario, il ciclo beta standard di quattro settimane viene utilizzato per stabilizzare sia la versione stabile sia quella stabile estesa. Le aziende che scelgono di attivare la versione stabile estesa di otto settimane devono continuare a utilizzare il canale beta come fanno oggi per identificare in modo proattivo i problemi che potrebbero influire sui loro ambienti.
L'importanza continua dei canali Dev e beta per gli utenti della versione stabile estesa
Sebbene il canale stabile stia accelerando verso un ciclo di rilascio di due settimane e la tua organizzazione stia adottando il ciclo stabile esteso di otto settimane per avere più tempo per i test, è comunque fondamentale utilizzare i canali Dev e beta. Non esistono canali "Dev o beta estesi" separati; i canali Dev e beta standard vengono utilizzati per stabilizzare sia le release stabili sia quelle stabili estese.
Continuando a utilizzare i canali Dev e beta, le aziende mantengono la possibilità di identificare in modo proattivo i problemi che potrebbero influire sui loro ambienti. I canali Dev e beta forniscono un'anteprima di quattro settimane della prossima release stabile. Per gli utenti della versione stabile estesa, questa finestra di anteprima è essenziale per scoprire e risolvere potenziali interruzioni con largo anticipo rispetto all'aggiornamento delle funzionalità di otto settimane.
I canali Dev e beta fungono essenzialmente da sistema di allerta precoce principale per qualsiasi modifica in arrivo nell'ambiente stabile esteso di otto settimane, garantendo che le app aziendali rimangano compatibili. Gli amministratori di sistema possono continuare ad assegnare un gruppo di utenti piccolo e deterministico (ad esempio, il 5-10% degli utenti dell'app) ai canali Dev e beta per massimizzare questo vantaggio.
Conclusione
I test sono una parte fondamentale delle aziende di sviluppo software per garantire la qualità dei loro prodotti e anche un passo importante per gli amministratori di sistema, per consentire ai dipendenti di un'organizzazione di accedere a software di alta qualità ed evitare di interrompere i processi aziendali.
Per avere successo nell'implementazione di un flusso di lavoro di test all'interno della tua organizzazione, è importante che tutti condividano la mentalità comune secondo cui la qualità e quindi i test sono una funzionalità.
In questo articolo abbiamo esaminato diversi modi per integrare le best practice per i test nella tua organizzazione. Per una revisione approfondita degli strumenti di test esistenti , consulta il nostro articolo Strumenti di Chrome per test automatici senza problemi.
Per indicazioni pratiche sui test, dall'inizio alla fine, consulta anche il nostro recente corso Learn Testing e le best practice per l'automazione dei test su web.dev.