Informazioni sullo strumento
La maggior parte dei team sa dire quanti test automatici ha. Meno team sanno dire se quei test sono un segnale di cui qualcuno si fida. Questa scorecard pone dodici domande su ciò che succede davvero oggi, due per ciascuna di sei aree: strategia e ambito, framework e qualità del codice, integrazione CI/CD, dati di test e ambienti, affidabilità e flakiness, reporting e ownership. Ogni risposta vale da 0 a 3 punti. Ogni area riceve un punteggio su 100 dalle sue due risposte, e il punteggio complessivo è la media delle sei aree, così un team con un framework bellissimo che gira solo su un portatile non può ottenere un buon punteggio. Il punteggio complessivo corrisponde a uno di quattro livelli: Ad hoc (sotto 35), Emerging (emergente, da 35 a 59), Established (consolidato, da 60 a 84) e Optimised (ottimizzato, 85 e oltre). Le aree più deboli sotto 80, fino a tre, tornano come prossimi passi concreti con link alle lezioni e agli strumenti che le trattano. Il punteggio segue una rubrica fissa, descritta nelle FAQ qui sotto. È uno spunto di discussione per una retrospettiva o una sessione di pianificazione, non un benchmark rispetto ad altre aziende: dietro non c’è alcun dataset di altri team, e non si pretende che ci sia.
Come si usa
- Rispondi a ogni domanda con l’opzione che descrive ciò che il tuo team fa oggi. Aspirazioni e piani contano come l’opzione in cui ti trovi adesso.
- Il punteggio si aggiorna appena hai risposto a tutte e dodici le domande. Le risposte vengono salvate in questo browser, così puoi riprenderle in seguito.
- Leggi l’elenco “Work on next” (su cosa lavorare): prima le aree più deboli, ciascuna con un passo concreto e link per approfondire.
- Usa “Copy share link” per inviare il risultato al team. Il link contiene le risposte, quindi chi lo apre vede gli stessi punteggi. “Copy summary” fornisce testo semplice per Slack, un ticket o un documento di retrospettiva.
Che cosa misurano le sei aree
- Strategia e ambito: se l’automazione si concentra di proposito sul rischio e se la maggior parte dei controlli si trova al livello più economico in grado di intercettare il bug (unit e API prima della UI).
- Framework e qualità del codice: se il codice di test è strutturato (page o component object, fixture, configurazione) e revisionato come il codice di produzione, e se i locator sopravvivono alle modifiche del markup.
- Integrazione CI/CD: se i test girano a ogni modifica senza che qualcuno debba ricordarsi di lanciarli, e quanto aspetta una pull request per avere la risposta.
- Dati di test e ambienti: se i test gestiscono i propri dati e possono girare in parallelo e in qualsiasi ordine, su un ambiente sempre identico.
- Affidabilità e flakiness: se una build rossa indica un problema reale. Sleep fissi e rilanci finché non diventa verde sono i colpevoli abituali.
- Reporting e ownership: se un fallimento si può diagnosticare dal report della CI e se è l’intero team, non solo il QA, a intervenire.
Come usare il risultato con un team
Chiedi a due o tre persone (un tester, uno sviluppatore, chi gestisce la pipeline) di compilarla separatamente, poi confrontate i link di condivisione. I punti in cui le risposte divergono sono di solito più utili del punteggio stesso: se una persona sceglie “on every pull request” e un’altra “nightly”, il team non è d’accordo su ciò che fa la pipeline.
Scegli un’area da “Work on next” per trimestre. Portare un’area da 33 a 67 vale più che distribuire lo sforzo su tutte e sei. Ripeti la scorecard a fine trimestre con le stesse persone.
Scorecard di maturità della test automation: domande frequenti
Come viene calcolato il punteggio?
Ogni risposta vale 0, 1, 2 o 3 punti, nell’ordine in cui sono elencate le opzioni. Ogni area ha due domande, quindi vale fino a 6 punti, mostrati come percentuale. Il punteggio complessivo è la media arrotondata delle percentuali delle sei aree. Livelli: Ad hoc sotto 35, Emerging 35–59, Established 60–84, Optimised 85 e oltre.
È un benchmark di settore?
No. La scorecard è una rubrica fissa basata su pratiche di test automation ampiamente condivise, non un confronto con altre aziende. Dietro non c’è alcun dataset di altri team, e SDETRole non raccoglie le tue risposte per crearne uno.
Dove vengono salvate le mie risposte?
Nel local storage del browser e, quando lo copi, nel frammento del link di condivisione (la parte dopo #). I browser non inviano il frammento ai server, quindi SDETRole non riceve mai le tue risposte.
Se apro il link di un collega, sovrascrive le mie risposte?
No. Un risultato condiviso viene mostrato senza essere salvato. Se cambi una risposta, inizi una tua copia a partire dalle sue risposte, e quella copia viene salvata nel tuo browser.
Non abbiamo ancora automazione. È comunque utile?
Sì. Rispondi onestamente e otterrai punteggi bassi nella maggior parte delle aree; l’elenco “Work on next” ti dirà da dove iniziare, che di solito è la strategia (cosa automatizzare per primo) e la CI (eseguire tutto automaticamente fin dal primo giorno).