Progettazione dei test: una competenza QA essenziale

Una delle idee errate più diffuse nell'attuale panorama dei test è che i test in produzione richiedano soltanto tre competenze: esperienza nei processi, conoscenza degli strumenti di test automatizzati e capacità di gestione degli incidenti. Sono importanti, ma ciò che spicca per la sua assenza, non solo da questo elenco ma anche nella mente dei responsabili delle assunzioni, è qualcosa che si direbbe dovesse essere l'elemento più fondamentale:

La capacità di progettare un test pratico per gli ambienti di produzione.

Sarebbe comico, se non fosse così allarmante, che quasi nessuna organizzazione dia priorità alle competenze fondamentali di QA quando implementa strategie di test in produzione.

Che un test venga eseguito manualmente o tramite automazione in un sistema di produzione attivo, non è necessario sapere prima come progettarne uno che fornisca informazioni utili senza compromettere l'esperienza dell'utente?

Sarebbe comico, se non fosse così allarmante, che quasi nessuna organizzazione dia priorità alle competenze di progettazione dei test quando implementa strategie di test in produzione. Che un test venga eseguito manualmente in un ambiente controllato o automaticamente in un sistema di produzione attivo, non è necessario sapere prima come progettarne uno che fornisca informazioni utili senza compromettere l'esperienza dell'utente?

C'è un problema evidente nell'escludere le competenze di progettazione dei test dal proprio approccio ai test in produzione:

Non è forse essenziale sapere che la persona che implementa i test nell'ambiente di produzione comprende cosa costituisce un test significativo?

Dal momento che automatizzare test progettati male in produzione fornisce dati inaffidabili più rapidamente e crea rischi inutili? E il fatto di essere "agili" mentre si eseguono incompetentemente test in produzione non mi sembra un vero miglioramento, se non forse per lo Scrum Master.

L'importanza e la disciplina della progettazione dei test, soprattutto per gli scenari di test in produzione, aspettano da tempo di essere riscoperte. Considerate questo il mio contributo a tale impegno.

Cosa è essenziale per eseguire test efficaci in produzione?

Il primo passo per padroneggiare i test in produzione consiste nel fare alcune distinzioni essenziali che saranno senza dubbio già intuitivamente familiari alla maggior parte dei professionisti QA, ma che raramente vengono presentate in modo sistematico nei contesti di test in produzione.

Esploriamo questi concetti fondamentali che trasformeranno il vostro approccio ai test in produzione.

Funzionalità esplicite e implicite negli ambienti di produzione

Iniziamo dalla distinzione fondamentale tra funzionalità esplicite e implicite durante i test in produzione.

Le prime sono ciò che la maggior parte di noi considera una "funzionalità". Si riferiscono a caratteristiche e capacità formalmente specificate dal prodotto e la cui specifica formale guida la loro implementazione da parte dell'ingegneria. Durante i test in produzione, queste funzioni esplicite sono in genere al centro degli strumenti di monitoraggio e osservabilità.

Per questo motivo, testare funzionalità esplicite in produzione può sembrare semplice, ma anche in presenza di caratteristiche ben definite non è così, come vedremo più avanti. Almeno il livello di specificità delle funzionalità esplicite rende più facile costruirvi attorno un'impalcatura di test in produzione (o l'illusione di tale impalcatura).

La funzionalità implicita in un ambiente di produzione è qualcosa di completamente diverso.

Comprende comportamenti e risposte agli input degli utenti o dell'ambiente che non sono stati definiti formalmente né previsti. La mancata progettazione adeguata dei test per questa funzionalità implicita in produzione è di gran lunga la fonte della maggior parte dei bug critici scoperti dopo la distribuzione del prodotto (l'altra è rappresentata da test inadeguati in ambienti hardware/software/dispositivo marginali).

In altre parole:

Testare funzionalità implicite in produzione richiede notevole ingegno e immaginazione. È la parte veramente creativa delle strategie di test in produzione.

Testare funzionalità implicite negli ambienti di produzione richiede una certa dose di astuzia diabolica per diventare bravi, e purtroppo non è qualcosa che si possa insegnare attraverso i processi QA standard.

Nessuna quantità di metodologia agile o di framework per i test automatizzati vi insegnerà a testare efficacemente le funzionalità implicite in produzione, ma una corretta progettazione dei test può incoraggiarvi a farlo.

Come si definisce, dunque, una strategia di progettazione dei test per le funzionalità implicite nell'ambiente di produzione? Fortunatamente, è possibile farlo. Ma prima di addentrarci direttamente nella questione, esploriamo alcune ulteriori distinzioni rilevanti e fondamentali per eseguire test efficaci in produzione.

Test positivi e negativi

Conclusione principale: Quando si eseguono test in produzione, sia i test positivi sia quelli negativi richiedono considerazioni speciali che vanno oltre gli approcci QA tradizionali.

La maggior parte delle persone che lavorano nel QA comprende la differenza fondamentale tra questi due tipi di test:

• Test positivo in produzione: convalida del corretto funzionamento delle funzionalità negli ambienti di produzione
• Test negativo in produzione: verifica strategica della risposta del sistema a input imprevisti senza interrompere l'esperienza degli utenti reali

Perché i test in produzione sono diversi

Sebbene queste distinzioni siano concettualmente chiare, i test in produzione introducono sfide uniche:

• Rischi maggiori: i casi limite hanno conseguenze sui clienti reali e sulle operazioni aziendali
• Complessità del mondo reale: i comportamenti degli utenti raramente seguono schemi prevedibili
• Continuità aziendale: i test non devono interrompere le normali operazioni

Oltre le specifiche

Le specifiche raramente forniscono tutto ciò che serve per eseguire test efficaci in produzione:

Dipendere eccessivamente dalle specifiche, che provengano dal reparto di prodotto o da quello di ingegneria, limita il pensiero. Questo è particolarmente problematico quando si eseguono test in produzione, dove i modelli di utilizzo nel mondo reale spesso si discostano dalle specifiche.

Questo illustra quello che chiamo "l'errore empirico": aspettare che qualcosa ci dica esplicitamente cosa fare prima di poterlo comprendere.

La progettazione di test efficaci per gli ambienti di produzione richiede:

1. Parametrizzazione corretta delle funzionalità
2. Ragionamento logico su ciò che è possibile
3. Considerazione delle interazioni sia dell'utente sia dell'ambiente

Esempio del mondo reale: comportamenti imprevisti

Ai tempi del Cretaceo del software (ovvero negli anni '80), testai un software per la conversione dei documenti e scoprii funzionalità sorprendenti:

Mostra immagine

Esempio classico: in WordPerfect era possibile inserire un comando per l'interlinea a metà di un paragrafo, influenzando solo le righe successive e creando paragrafi con due valori di spaziatura diversi.

Equivalenti moderni durante i test in produzione:

• Combinazioni impreviste di autorizzazioni degli utenti nelle applicazioni cloud
• Sequenze impreviste di richieste API nelle architetture a microservizi
• Condizioni di competizione negli ambienti ad alta concorrenza

Ora analizziamo i tre parametri fondamentali che renderanno più efficace il tuo approccio ai test in produzione:

1. Test dell'ambito delle funzionalità

Definizione: identificare come gli utenti potrebbero distribuire le funzionalità in contesti o modi mai immaginati durante la progettazione.

Perché è importante per i test

Non tutti i vincoli vengono previsti durante lo sviluppo. Negli ambienti di produzione, questa svista può avere conseguenze gravi.

Oltre la semplice convalida

Quando esegui test in produzione, considera questi limiti:

Ricorda: convalidare una funzionalità in produzione non significa solo confermare che funzioni come previsto, ma verificare che non possa essere utilizzata in modi non previsti che potrebbero compromettere la stabilità o la sicurezza del sistema.

2. Test dell'interruzione dei flussi di lavoro nei sistemi in produzione

Attenzione: questo approccio presuppone che tu stia già testando flussi di lavoro definiti in produzione. In caso contrario, affronta prima questi aspetti fondamentali!

Oltre il "percorso felice"

Quando esegui test in produzione, esplora queste interruzioni critiche dei flussi di lavoro:

✅ Flussi di lavoro interrotti: il processo viene avviato ma non viene mai completato
✅ Operazioni annullate: l'utente annulla esplicitamente l'operazione a metà processo
✅ Processi riavviati: l'utente tenta di eseguire più volte la stessa azione
✅ Ritorno ai passaggi precedenti: l'utente torna ai passaggi precedenti con input diversi

Suggerimenti per l'implementazione dei test in produzione

Utilizza tecniche come i flag delle funzionalità per controllare in modo sicuro l'esposizione di questi test negli ambienti di produzione.

Applicazioni nel mondo reale

Consiglio: questi scenari vengono raramente riportati nelle specifiche, ma rappresentano il comportamento reale degli utenti in produzione.

3. Sequenzialità nei test in produzione

La sfida: nei sistemi di produzione con più processi concorrenti, la sequenza delle operazioni può causare errori imprevisti difficili da riprodurre negli ambienti di test.

Due modelli critici di sequenzialità

Condizioni antecedenti che contribuiscono al problema

Mostra immagine

• Definizione: eventi che devono verificarsi prima di un processo soggetto a errori
• Caratteristiche: possono manifestarsi solo dopo sequenze specifiche che richiedono giorni per verificarsi naturalmente
• Esempio in produzione: autorizzazioni dell'utente modificate → la cache scade → viene chiamata un'API specifica

Condizioni successive che contribuiscono al problema

• Definizione: errori che diventano evidenti solo attraverso interazioni successive
• Manifestazione: l'errore rimane nascosto fino a un'operazione successiva
• Esempio in produzione: si verifica un danneggiamento dei dati che rimane silente finché non viene generato un report

Perché è così difficile?

Definire l'ambito dei test di sequenzialità in produzione richiede:

1. Una conoscenza approfondita delle interazioni del sistema
2. La modellazione delle transizioni di stato per processi complessi
3. La comprensione delle combinazioni di stato previste e impreviste

"Come quei valori doppi di interlinea in un singolo paragrafo, questi stati imprevisti possono causare gravi problemi negli ambienti di produzione."

Strumenti essenziali per i test di sequenzialità in produzione

• Strumenti di ingegneria del caos per introdurre deliberatamente errori controllati
• Strumenti di osservabilità per monitorare le modifiche di stato nei diversi sistemi
• Tracciamento distribuito per seguire i percorsi delle richieste attraverso i microservizi

In sintesi: i problemi di sequenzialità rappresentano una delle fonti più ricche di bug gravi nei moderni sistemi di produzione. Date priorità a questo aspetto nella vostra strategia di test.

In sintesi

I flag delle funzionalità trasformano i test in produzione da pratica rischiosa a processo controllato e basato sui dati. Separando la distribuzione dal rilascio e offrendo funzionalità di ripristino immediato, creano una rete di sicurezza che consente ai team di convalidare il software in condizioni reali senza compromettere l'esperienza degli utenti o la stabilità del sistema.

Piattaforme di gestione delle funzionalità nei test in produzione

Le piattaforme di gestione delle funzionalità hanno trasformato i test in produzione da attività rischiosa a processo controllato e sistematico. Tuttavia, molte organizzazioni non riescono a sfruttare efficacemente questi strumenti nella propria strategia di progettazione dei test.

L'evoluzione della gestione del rischio in produzione

Gli approcci tradizionali ai test in produzione prevedevano decisioni binarie: una funzionalità era attiva per tutti oppure per nessuno. Le piattaforme di gestione delle funzionalità cambiano radicalmente questo paradigma:

• Controllo granulare: testare le funzionalità con segmenti specifici di utenti anziché con distribuzioni che prevedono solo tutti o nessuno
• Risoluzione immediata: disattivare le funzionalità problematiche senza distribuzioni del codice o ripristini
• Esposizione progressiva: aumentare gradualmente l'esposizione degli utenti in base ai dati sulle prestazioni in tempo reale

Oltre i semplici flag delle funzionalità

Sebbene l'uso di base dei flag delle funzionalità esista da anni, le moderne piattaforme di gestione delle funzionalità offrono capacità fondamentali che trasformano i test in produzione:

Se integrate correttamente nella strategia di progettazione dei test, le piattaforme di gestione delle funzionalità consentono:

1. Contenimento mirato del rischio - Limitare l'esposizione delle nuove funzionalità a segmenti specifici di utenti
2. Convalida con utenti reali - Testare con utenti effettivi anziché con dati di test sintetici
3. Risoluzione immediata - Affrontare i problemi senza distribuzioni di emergenza o ripristini

Integrazione con gli strumenti di osservabilità

La vera potenza delle piattaforme di gestione delle funzionalità emerge quando vengono integrate con i sistemi di osservabilità e monitoraggio:

Approccio tradizionale:

• Rilevamento dei problemi dopo il completamento della distribuzione
• Verifica manuale dei risultati dei test
• Analisi post-mortem dopo gli incidenti

Integrazione della gestione delle funzionalità:

• Correlazione dell'attivazione delle funzionalità con le metriche di sistema
• Monitoraggio automatizzato delle prestazioni per ogni flag delle funzionalità
• Informazioni in tempo reale sull'impatto delle funzionalità

Impatto nel mondo reale: trasformare i test in produzione

Le organizzazioni che implementano piattaforme di gestione delle funzionalità riportano vantaggi significativi:

• Riduzione della gravità degli incidenti: "Possiamo testare le funzionalità in produzione molto prima del lancio commerciale. E se una funzionalità causa problemi il giorno del lancio, possiamo semplicemente disattivarla con un interruttore di emergenza, senza dover effettuare rollback." — Chris Guidry, VP dell'ingegneria, O'Reilly Media.
• Cicli di rilascio accelerati: I team di IBM, TrueCar e altre aziende leader sfruttano la gestione delle funzionalità per i test in produzione, beneficiando di quelli che descrivono come "rilasci sicuri e privi di cerimonie".
• Maggiore copertura dei test: I flag delle funzionalità espongono casi limite impossibili da simulare in ambienti controllati.

Implementazione pratica nella progettazione dei test

Per integrare efficacemente le piattaforme di gestione delle funzionalità nella strategia di progettazione dei test:

1. Progettare punti di verifica allineati alle transizioni dei flag delle funzionalità
2. Creare scenari di fallback per ogni componente soggetto a flag delle funzionalità
3. Stabilire soglie di prestazione che attivino la disabilitazione automatica delle funzionalità
4. Definire casi di test specifici per segmento per convalidare il comportamento tra le diverse popolazioni di utenti
5. Documentare le dipendenze tra i flag per prevenire guasti a cascata

Le piattaforme di gestione delle funzionalità non sostituiscono una progettazione ponderata dei test, ma la potenziano. La qualità dei test in produzione dipende ancora fondamentalmente da quanto bene sono stati progettati i test.

Errori comuni da evitare

Anche con una gestione solida delle funzionalità, rimangono diverse sfide:

• Debito dei flag - Flag abbandonati o dimenticati che creano debito tecnico
• Monitoraggio insufficiente - Mancata correlazione tra lo stato dei flag e le prestazioni del sistema
• Eccessiva sicurezza - Riduzione prematura dei test pre-produzione
• Interdipendenze tra i flag - Creazione di relazioni complesse e difficili da risolvere

In sintesi

Le piattaforme di gestione delle funzionalità offrono potenti capacità per i test in produzione, ma devono essere integrate con attenzione nella strategia complessiva di progettazione dei test. Le organizzazioni che ottengono il massimo valore non si limitano a distribuire questi strumenti: ripensano fondamentalmente il funzionamento della progettazione dei test in un ambiente con flag delle funzionalità.

Quando viene implementata correttamente come parte di un approccio completo alla progettazione dei test, la gestione delle funzionalità trasforma i test in produzione da male necessario a vantaggio competitivo.

Strumenti per i test in produzione: sfide di implementazione

Sebbene i flag delle funzionalità e le piattaforme di gestione costituiscano la base dei test in produzione, l'ecosistema più ampio degli strumenti presenta una serie di proprie sfide di implementazione. La selezione e la configurazione degli strumenti giusti richiedono un'attenta valutazione delle capacità del team, dell'architettura del sistema e delle esigenze dell'organizzazione.

Strumenti di monitoraggio e osservabilità

L'efficacia dei test in produzione dipende da una visibilità completa sul comportamento del sistema:

• Monitoraggio delle prestazioni delle applicazioni (APM)
  Vantaggi: Fornisce informazioni dettagliate sulle prestazioni nell'intero stack applicativo.
  Sfide: Spesso richiede una strumentazione significativa e può generare una quantità eccessiva di dati, sovraccaricando i team più piccoli.
• Sistemi di gestione dei log
  Vantaggi: Essenziali per la risoluzione dei problemi e l'analisi forense durante i test in produzione.
  Sfide: Possono generare volumi di dati ingestibili senza strategie adeguate di filtraggio e indicizzazione.
• Tracciamento distribuito
  Vantaggi: Offre visibilità da un'estremità all'altra nelle architetture a microservizi.
  Sfide: La complessità dell'implementazione aumenta drasticamente negli ambienti eterogenei con diversi stack tecnologici.

Sistemi di gestione degli avvisi

Un sistema di avvisi adeguato è fondamentale quando si testano nuove funzionalità in produzione:

• Piattaforme di aggregazione degli avvisi
  Vantaggi: consolidano le notifiche provenienti da più sistemi di monitoraggio.
  Sfide: sono ottime per la gestione degli incidenti, ma possono essere fonte di disturbo se non vengono configurate attentamente per evitare l'affaticamento da avvisi.
• Sistemi di risposta agli incidenti
  Vantaggi: semplificano la comunicazione durante gli incidenti in produzione.
  Sfide: per essere efficaci richiedono procedure operative documentate e punti di integrazione ben definiti; possono creare un sovraccarico per le distribuzioni semplici.

Considerazioni sull'implementazione

Quando implementano strumenti per i test in produzione, i team dovrebbero valutare:

1. Requisiti di scalabilità - Lo strumento sarà in grado di gestire i volumi di traffico e la crescita dei dati?
2. Capacità di integrazione - Con quale facilità si connette all'insieme di strumenti esistente?
3. Consumo di risorse - Quale sovraccarico introduce lo strumento stesso?
4. Competenza del team - Disponete delle competenze necessarie per massimizzare il valore dello strumento?
5. Rapporto segnale-rumore - È possibile estrarre informazioni utili senza essere sommersi dai dati?

Errori comuni nell'implementazione

• Proliferazione degli strumenti - Accumulare troppe soluzioni sovrapposte
• Strumentazione incompleta - Tralasciare punti di monitoraggio critici
• Affaticamento da avvisi - Generare notifiche eccessive che i team finiscono per ignorare
• Contesto insufficiente - Non riuscire a correlare le metriche con l'impatto sugli utenti
• Silos di dati - Creare sistemi di monitoraggio isolati che non condividono informazioni

Trovare il giusto equilibrio

Le implementazioni dei test in produzione più efficaci raggiungono un equilibrio tra:

• Monitoraggio completo e complessità gestibile
• Informazioni dettagliate e sovraccarico di informazioni
• Risposte automatizzate e momenti decisionali umani

Quando implementate strumenti di test negli ambienti di produzione, iniziate in piccolo con obiettivi mirati, quindi ampliate gradualmente la copertura man mano che il team sviluppa competenze sia nell'uso degli strumenti sia nell'interpretazione dei dati risultanti.

Carico, complessità, latenza

Considerate i fattori macro di carico, complessità e latenza nella progettazione dei test. Questi possono influire sull'esecuzione o sul completamento di una richiesta, di un processo o di un evento. 

La rilevanza del carico del sistema dovrebbe essere ovvia. Il modo in cui vengono elaborate le richieste o le transazioni durante i periodi di stress del carico elevato del sistema può causare errori (in qualsiasi fase del processo di transazione).

Questo dovrebbe essere un elemento predefinito della pianificazione dei test. Come tutti sappiamo, il carico può anche essere generato dalla richiesta stessa, ad esempio da una query sui dati che attiva l'elaborazione e la trasmissione di enormi quantità di dati.

La complessità si riferisce qui principalmente alla complessità delle richieste inviate a un sistema. Questa complessità può consistere nel numero di condizioni specificate (e delle relative esclusioni ed eccezioni), nel numero di database (virtuali o meno) coinvolti nelle richieste o nella topologia di elaborazione del sistema stesso.

Nel contesto di questa discussione, uso la latenza per indicare l'introduzione di intervalli di tempo nel processo di richiesta, che non è il suo significato consueto. Mi riferisco qui alla latenza dell'utente, non alla latenza di risposta del sistema stesso. 

In altre parole, come si comporta la funzionalità o la capacità se l'utente arriva a un passaggio specifico del processo e poi rimane in pausa, senza fare nulla? Il sistema va in timeout (probabilmente dovrebbe)? Deve sollecitare l'utente? Deve rimanere in quello stato fino alla fine dei tempi? 

Le risposte a queste domande possono essere fornite nella specifica, ma il prodotto sottoposto a test potrebbe non comportarsi in quel modo, ed è per questo che eseguiamo i test.

Ruoli utente

Naturalmente, gli utenti finali possono interagire con i sistemi software ricoprendo ruoli diversi. Lo stesso utente può interagire con il sistema in ruoli diversi, a seconda delle proprie azioni. 

Tuttavia, anche i processi e i servizi possono avere ruoli diversi e privilegi associati. In entrambi i casi, assicurati che la progettazione e la pianificazione dei test, sia per le funzionalità che per le capacità, considerino e verifichino tutti i possibili stati dei ruoli.

Qual è il prossimo passo?

Cerchi altri consigli sulla progettazione dei test? E vuoi migliorare le tue competenze in materia di crescita e leadership nel settore SaaS?

Iscriviti alla nostra newsletter per ricevere gli ultimi approfondimenti da CTO e aspiranti leader tecnologici. 

Ti aiuteremo a crescere in modo più intelligente e a guidare con maggiore autorevolezza grazie a guide, risorse e strategie fornite dai migliori esperti!