10 volte - 100 volte più veloce
1.000 volte più approfondito
In media eseguiamo circa 1000 test per user story. Questa è una combinazione di test statici e dinamici. Questo è un livello di controllo non normale raggiunto con le revisioni manuali delle storie.
Voglio sapere di più? Leggi i dettagli sul tipo di test eseguito da ScopeMaster.
ScopeMaster fornisce analisi dei requisiti software che aiutano i team di distribuzione del software a consegnare progetti software più velocemente e con maggiore certezza.
Se può essere interpretato male, lo sarà
Se una user story può essere interpretata in modo diverso dai principali lettori (autore, utente, tester, sviluppatore), è probabile che uno di loro lavorerà per una comprensione errata, generando sprechi e rielaborazioni. È molto importante stroncare queste ambiguità sul nascere.
125 motivi per testare le storie degli utenti
Il rapporto tra le parole in una user story e il numero di token di codifica che in genere vediamo è 1:125. Una user story di 12 parole probabilmente finirebbe per diventare circa 1.500 token di codifica, circa 300 righe di codice. Pertanto, per ogni minuto trascorso a correggere una parola ambigua in una user story si risparmieranno probabilmente 125 minuti nella codifica. Ora è tempo ben speso!
Test di estrema sinistra
Il test delle storie degli utenti può sembrare un'idea strana, ma non lo è. In effetti è una delle cose più produttive che puoi fare su un progetto software. È l'epitome dei test di estrema sinistra. Se vuoi diventare un proprietario di prodotto di maggior successo, inizia a testare queste storie il prima possibile. Le storie degli utenti sono l'espressione dei requisiti relativi agli sforzi software agili. Come altri risultati finali dello sviluppo software, anche questi sono soggetti a errori. La sfida particolare con le storie degli utenti è che possono essere facilmente interpretate erroneamente, il che può portare a molto tempo e fatica sprecati. In effetti è più probabile che vengano interpretati male che no.
Come testare le storie degli utenti
Quindi come lo facciamo? Cominciamo dalle basi. Cos'è un requisito del software aziendale?:
Un vero requisito (o capacità) aziendale lo è “cosa deve essere fornito per fornire valore al business” (Robin Goldsmith). Le storie degli utenti sono i requisiti funzionali discreti che costituiscono tale capacità.
Cosa succede se non provi le tue storie utente?
User story inadeguate (o requisiti inadeguati) sono la causa principale dei 35% difetti di produzione (Accenture, 2021). Un problema relativo ai requisiti che non viene risolto fino alle fasi successive dello sviluppo/distribuzione può costare 75-1.000 volte di più da risolvere rispetto a quando viene risolto prima dell'inizio della codifica.
Necessità di disciplina, per ridurre l'ambiguità
Quando scriviamo codice, seguiamo discipline per migliorare la leggibilità, ridurre la complessità, aumentare il riutilizzo e molto altro ancora. (Per ulteriori informazioni su questo, leggi l'eccellente Codice completato, di Steve McConnell). Anche la scrittura delle storie degli utenti garantisce tale disciplina, soprattutto per ridurre al minimo l’ambiguità, l’incoerenza e la complessità. In effetti, una buona user story può essere piuttosto noiosa poiché non è ambigua. Preparati a modificare il modo in cui scrivi le storie degli utenti, adotta coerenza e disciplina per eliminare le ambiguità. Fortunatamente ScopeMaster ti aiuterà a imparare mentre procedi.
Strumenti correlati
Jsonlint è uno strumento online per testare la sintassi di un file json
Validatore HTML è uno strumento online per testare la sintassi HTML.
