Immagina che il software più importante della tua azienda si rompa improvvisamente, cosa accadrà? Gli ordini potrebbero andare persi, mancare delle scadenze, ma i clienti si lamenteranno certamente.
Questo scenario da incubo è evitabile: implementa un processo di test continuo e rigoroso, che individua i problemi prima che provochino 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 considerare quando inizi a eseguire test nella tua azienda e come puoi trarre vantaggio dai test nel lungo termine.
Test delle best practice per i team di prodotto
La prima parte di questo articolo illustra la procedura per iniziare a implementare i test nel flusso di lavoro.
Implementa una cultura di test nel tuo team
Introdurre con successo i test nel team è necessario che tutti condividano una mentalità comune e che la qualità non sia un onere, ma un investimento. Questo è un processo che, come ogni altro cambiamento culturale, richiede tempo e coerenza.
Una cosa che può contribuire a plasmare questa cultura sono le riunioni periodiche per discutere dei difetti, dell'impatto che hanno avuto, della loro provenienza e cosa serviva per risolverli. In questo modo, è più facile capire perché è opportuno prevenire questi difetti.
Avere una persona dedicata nel team che supervisiona e gestisce l'impegno può aumentare notevolmente le probabilità di successo. Qualcuno che definisce linee guida per i team (o anche a livello di organizzazione), raccoglie le best practice e le condivide e sostiene lo sforzo a tutti i livelli.
Un altro strumento utile può essere quello di ruotare il ruolo di assistenza del prodotto. Ottenere informazioni direttamente dai clienti senza filtri e conoscere i problemi quotidiani che devono affrontare con il tuo prodotto può essere un'esperienza preziosa per product manager, designer e sviluppatori.
L'obiettivo è fare in modo che tutti i membri del team comprendano che la qualità è una funzionalità, importante quanto qualsiasi altra funzionalità che crei per il 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à della spedizione.
Una procedura di test dettagliata
Una volta raggiunto un allineamento tra i diversi team coinvolti nello sviluppo del prodotto, puoi formalizzare ulteriormente l'esistenza e l'utilizzo dei test.
Inclusione dei test nella "Definizione di completamento"
Aggiungendo dei test come requisito di una funzionalità, dichiari che una funzionalità non è pronta per essere spedibile finché non viene testata correttamente e automaticamente
Esegui test regolarmente
Una volta implementati, i test automatici possono essere la tua protezione in ogni fase del processo di sviluppo. Non richiedono l'intervento umano e possono essere eseguite in ogni passaggio critico della pipeline di sviluppo. Ad esempio:
- Per ogni commit.
- A ogni richiesta di pull.
- Dopo ogni release completa o modifica dell'ambiente.
Se utilizzi servizi di terze parti nel tuo ambiente di produzione, può avere senso eseguire i tuoi test sulla produzione, in modo che le API di terze parti funzionino come previsto.
Definisci e raccogli 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 più elevato di release al mese può indicare un processo di sviluppo più agile. I test automatici svolgono un ruolo chiave in questo senso, garantendo che le release possano procedere con sicurezza.
- Segnalazioni di bug: una tendenza decrescente nelle segnalazioni di bug può essere un segno positivo dell'efficacia dei tuoi test (e dei processi di sviluppo).
- Copertura dei test: sebbene non sia mai una metrica esatta, la copertura può essere un buon indicatore dell'intensità dei test sui 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 potrebbero aumentare. Quindi non affidarti solo a pochi dati e assicurati di incrociarli con altri dati a disposizione del tuo team.
Se implementi correttamente questi passaggi con il tuo team, l'integrità del tuo prodotto trarrà sicuramente un vantaggio a lungo termine. Ma c'è ancora molto altro che puoi fare.
Best practice per i test per amministratori di sistema
I team di prodotto non possono lavorare in modo autonomo. Si affidano all'hardware, agli strumenti e all'infrastruttura gestiti dagli amministratori di sistema. Sebbene gli amministratori di sistema di solito non contribuiscano direttamente allo sviluppo del prodotto, possono comunque influenzare il flusso di lavoro di sviluppo in modo definitivo. Ad esempio, gestendo attivamente la versione del browser utilizzata da determinati gruppi di utenti nell'azienda.
Questa seconda parte dell'articolo spiega come funziona, usando i canali e le norme aziendali di Chrome.
Canali di rilascio di Chrome
Per impostazione predefinita, Chrome si aggiorna automaticamente per garantire che ogni utente esegua la versione più recente, stabile e sicura di Chrome, inclusa tutte le funzionalità più recenti, la versione di Chrome rilasciata sul canale stabile.
In qualità di azienda che sviluppa un prodotto basato sul Web, ti consigliamo di utilizzare un browser in anticipo rispetto al canale stabile, per dare ai team di prodotto il tempo di adattare il prodotto ai cambiamenti apportati alla 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 future modifiche del browser e testare le funzionalità più recenti prima che siano disponibili su larga scala:
- Canale stabile: è qui che si trova la maggior parte degli utenti. Il canale stabile si aggiorna automaticamente ogni volta che viene pubblicata una nuova release di Chrome e avviene mensilmente.
- Canale beta: questa versione diventerà stabile entro 4-6 settimane, dandoti la possibilità di visualizzare in anteprima e testare una release stabile imminente e prepararti.
- Canale Dev. Questo canale riceve una nuova versione di Chrome una volta alla settimana e include tutte le correzioni più recenti che passeranno alla versione beta. Come suggerisce il nome del canale, è in fase di sviluppo e potrebbe quindi non funzionare inaspettatamente, ma include anche le funzionalità più recenti, a volte molto prima che diventino stabili. Questo rende il canale dev un ottimo strumento per la prototipazione e lo sviluppo all'avanguardia.
- Canale Canary: il canale più sperimentale, contenente tutte le funzionalità più recenti, ma senza molti test. Pubblicate almeno ogni giorno.
Per scoprire di più sui canali di Chrome, dai un'occhiata all'episodio pertinente di Chrome Concepts.
Utilizzare i canali in un'organizzazione esemplare
La struttura dei team di prodotto varia da un'organizzazione all'altra, in quanto non esiste un approccio unico allo sviluppo del software. Ad esempio, supponiamo che un team con i seguenti ruoli: gestione del prodotto, UX e UI, progettazione, operazioni e assistenza.
Per un'organizzazione come questa, puoi pensare alla seguente suddivisione del canale:
- Gestione dei prodotti: in genere, i PM possono essere sul canale stabile, in modo da utilizzare la stessa versione della maggior parte degli utenti. A volte 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 trovarsi sul canale dev per consentire l'accesso alle funzionalità più recenti, come Visualizza transizioni, anche prima che diventino instabili.
- Operazioni: potrebbero essere in versione beta, per prevedere un'interruzione che avrà un impatto sugli utenti successivamente.
- Assistenza: possono rimanere sul canale stabile per assicurarsi che interagiscano con il prodotto con lo stesso browser della maggior parte dei clienti.
Utilizza 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 viene utilizzato da ogni utente. Questo è utile perché aumenta immediatamente la superficie di test da pochi individui a un insieme deterministico di utenti, il che aiuta a identificare l'interruzione il prima possibile e in modo tracciabile.
Se vuoi utilizzare questo livello di controllo, ecco la configurazione che ti consigliamo:
- Dipendenti (utenti delle app): per ridurre al minimo il rischio di interruzioni, la maggior parte dei dipendenti deve utilizzare il canale stabile, che è stato testato completamente dal team di test di Chrome. Inoltre, una piccola percentuale di utenti (dal 5 al 10%) può utilizzare il canale beta. Questo canale dispone di un'anteprima di 4-6 settimane del canale stabile e può aiutare gli amministratori a scoprire possibili problemi con una release, lasciando più tempo per risolvere i problemi prima che la release venga implementata per tutti.
- Reparto IT: i membri del reparto IT, inclusi gli amministratori di sistema, possono essere sul canale beta o dev per avere 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 avvenire così rapidamente come previsto e la frequenza di rilascio di un mese di Chrome potrebbe essere troppo elevata. Per questo caso d'uso, Chrome fornisce un canale stabile esteso che consente di ricevere aggiornamenti delle funzionalità meno frequentemente, ma continuare a ricevere correzioni di sicurezza. Questo canale viene aggiornato ogni otto settimane.
Il seguente diagramma mostra come procedono le diverse tappe nei diversi canali di rilascio di Chrome:
- Sia la versione stabile che quella stabile estesa vengono rilasciate le stesse versioni per le prime quattro settimane, dopodiché le due divergono.
- Non esiste un canale beta esteso; al contrario, viene utilizzato il ciclo beta standard di quattro settimane per stabilizzare le versioni stabile ed estesa. Le aziende che scelgono di attivare la versione stabile estesa di otto settimane devono continuare a gestire il canale beta come fanno attualmente, al fine di identificare proattivamente i problemi che potrebbero influire sui loro ambienti.
Conclusione
I test sono una parte cruciale delle aziende di sviluppo software per garantire la qualità dei loro prodotti, nonché 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 riuscire a implementare un flusso di lavoro di test all'interno della tua organizzazione, è importante che tutti condividano la convinzione che la qualità è una funzionalità.
In questo articolo abbiamo esaminato diversi modi per integrare le best practice di test nella tua organizzazione. Per un'analisi approfondita degli strumenti di test esistenti, consulta il nostro articolo Strumenti di Chrome per test automatici e senza problemi.
Per indicazioni pratiche sui test, dall'inizio alla fine, consulta anche il nostro recente corso di apprendimento dei test e le best practice per l'automazione dei test su web.dev.