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 documento 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 documento illustra la procedura per iniziare a implementare i test nel flusso di lavoro.
Implementare una cultura dei test nel team
Per introdurre correttamente i test nel team, è necessario che tutti condividano una mentalità comune e che considerino la qualità non come un peso, ma come un investimento. Come ogni altro cambiamento culturale, questo processo richiede tempo e coerenza.
Un aspetto 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 sensibilizza l'importanza di 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 a livello di team o persino di organizzazione, raccoglie e condivide le best practice e promuove l'impegno a tutti i livelli.
Un altro strumento utile può essere la rotazione del ruolo di assistenza del 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, designer 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à, è naturale capire che anche i test sono una funzionalità, perché sono i test a garantire la qualità del prodotto.
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 l'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 nel tuo ambiente di produzione utilizzi servizi di terze parti, può essere utile 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 flussi di lavoro 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 che i processi di test (e di sviluppo) sono efficaci.
- 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 metriche 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 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 di rilascio di Chrome e i criteri aziendali.
Canali di rilascio di Chrome
Esistono quattro canali di rilascio: stabile, beta, Dev e Canary.
Per saperne di più, consulta Canali di rilascio di Chrome.
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 che un team abbia i seguenti ruoli: gestione del prodotto, UX e UI, ingegneria, operazioni e assistenza.
Per un'organizzazione di questo tipo, puoi pensare alla seguente suddivisione dei canali:
- Gestione del prodotto: 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 disponibili nella versione stabile.
- Operazioni: potrebbe utilizzare il canale 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 sul canale da 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 di test 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 ricevere 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 così rapidamente come previsto 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 rilasciate 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 utilizzare 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 a 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 apportata all'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 passaggio 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, di conseguenza, i test sono una funzionalità.
In questo documento 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 e senza problemi.
Per indicazioni 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.