ScopeMaster-dieci-test-per-grandi-storie-di-utente

Avvia il test delle storie degli utenti

Nella maggior parte delle attività software, le storie degli utenti sono un conciso promemoria delle conversazioni tra proprietario del prodotto, sviluppatore e tester. Sebbene le storie degli utenti siano molto brevi, il modulo viene comunemente utilizzato in modo improprio e ciò porta ad ambiguità, discussioni e rielaborazioni non necessarie. In questo articolo spieghiamo come testare le storie degli utenti in modo che tu possa garantire che le tue storie degli utenti siano di alta qualità e ridurranno le rielaborazioni e accorceranno le tempistiche.

Ho goduto di un notevole dibattito online sulla validità anche solo di pensare alla qualità delle storie degli utenti. Se accetti che storie utente chiare siano utili per un progetto, allora il concetto di test delle storie utente dovrebbe avere senso per te.

Impara questi dieci test per scrivere fantastiche storie utente.

1. Cancella

Le tue storie utente devono esserlo chiaro e inequivocabile. Il proprietario del prodotto, lo sviluppatore e il tester dovrebbero tutti avere una comprensione comune di ciò che deve essere fornito dal testo della storia. Mentre scrivi le tue storie, presumi che se possono essere potenzialmente fraintese, lo faranno. Inoltre, assicurati che le tue storie includano tutte le funzionalità necessarie (esclusa la navigazione).

Mancia: concentrarsi sull'intento funzionale della storia dell'utente, ad esempio "Come utente_registrato posso aggiornare il mio profilo"

Sfondo

Probabilmente verrà frainteso

Abbiamo analizzato oltre 100.000 storie di utenti e abbiamo scoperto che la lunghezza media della storia è di 12 parole. Matematicamente ci sono oltre 80 miliardi di permutazioni di 12 parole. Ciò significa che esistono quasi infiniti modi in cui i lettori possono interpretare erroneamente le storie degli utenti.

User story scadenti causano rielaborazioni eccessive (±125 volte)

Inoltre abbiamo stimato che, in media, ogni parola di una user story porta a 125 termini di codifica. Ciò significa che un errore (che può portare a un malinteso) porterà a notevoli rielaborazioni una volta iniziata la codifica.

L’aumento del lavoro a distanza significa che siamo più dipendenti dalla parola scritta. Trovare le parole giuste è importante.

Test di chiarezza automatizzato

La maggior parte delle storie degli utenti sono aperte a interpretazioni errate. ScopeMaster® esegue un'analisi linguistica dettagliata di ogni parola all'interno della storia dell'utente al fine di rilevare il/i significato/i funzionale/i. Il motore di analisi è progettato specificamente allo scopo di chiarire le ambiguità delle storie degli utenti del software (rileva i modelli di oggetto verbo soggetto all'interno del testo). Questo è il fondamento del modo in cui il motore di analisi esegue "il massimo dei test con spostamento a sinistra".

Il motore di analisi esegue inoltre centinaia di controlli linguistici per individuare frasi e termini ambigui che potrebbero portare a un'interpretazione errata della storia dell'utente. Questi test derivano dagli insegnamenti di alcuni dei maggiori esperti di requisiti a livello mondiale. (È un po' come se tutte le storie dei tuoi utenti venissero esaminate dagli esperti).

2. Conciso

Mantienili brevi. Non è necessario che le storie siano lunghe per trasmettere il significato funzionale essenziale. Potrebbero essere sufficienti una o più frasi brevi. Ricorda che i criteri di accettazione sono supplementari rispetto alla storia.

Mancia: evitare descrizioni sulla navigazione, dettagli di implementazione, criteri di accettazione e attributi dell'oggetto.

Mancia: evitare dettagli di implementazione.

Mancia: separare i criteri di accettazione dalla storia dell'utente principale.

Test di concisione automatizzato

ScopeMaster® esegue un'analisi dettagliata delle parole di ciascuna storia utente, evidenziando l'uso eccessivo di parole non necessarie.

Test dei requisiti statici

ScopeMaster® esegue centinaia di test su ogni storia dell'utente. È come SonarQube ma per le storie degli utenti.

Test della storia dell'utente - screenshot

3. Orientato all'utente

Una storia dovrebbe essere scritta dal punto di vista dell'utente. La tipica raccomandazione agile è il formato:

Come un Tipologia di utente voglio eseguire_qualcosa affinché motivo

In alcuni casi, il tipologia di utente potrebbe essere un altro pezzo di software, o forse anche un dispositivo che interagisce con il software, come un sensore.

Mancia: non scrivere mai le tue storie dal punto di vista dello sviluppatore.

Mancia: Evitare il termine generale utente, utilizza invece etichette complete e coerenti per il tipo o il ruolo dell'utente, ad esempio utente registrato O visitatore_non autenticato

Test di rilevamento utente automatizzato

L'analizzatore ScopeMaster® rileva gli utenti candidati all'interno di ciascuna storia. ScopeMaster evidenzierà le istanze di storie prive di un utente. Facoltativamente puoi istruire l'analizzatore quale è la parola "utente" all'interno della tua storia.

4. Testabile

Una storia può essere testabile se contiene chiare dichiarazioni di funzionalità. Utilizzare frasi che inferiscano lo spostamento, l'archiviazione e il recupero dei dati. Esempi di storie verificabili includono frasi come "aggiorna il profilo", “visualizza il rapporto sulle vendite“, "invia una email". Scrivere le tue storie in questo modo garantirà che l'intento funzionale principale sia chiaro. Ciò fornisce la base da cui è possibile generare scenari di test. L'intera suite di test dipenderà solitamente da criteri di accettazione dettagliati supplementari.

Mancia: i criteri di accettazione dettagliati sono supplementari rispetto alla storia utente principale, non incorporano criteri di accettazione nel testo della storia utente.

Generazione automatizzata di test

Come conseguenza della “conoscenza” dell'intento funzionale della tua user story, il motore ScopeMaster® propone scenari di test e casi di test essenziali che possono essere utilizzati come base per i test funzionali. I test generati da ScopeMaster sono allineati alla funzionalità della user story. Coprono sia i test positivi che quelli negativi. Possono essere considerati come i test minimi essenziali che devono essere eseguiti. Questo è un notevole risparmio di tempo per i professionisti dei test.

5. Misurabile

Mi riferisco qui alla misurabilità delle dimensioni, in particolare utilizzando il Punto funzione COSMIC (CFP) come base per il dimensionamento. È uno standard ISO maturo, di seconda generazione, adatto a tutti i tipi di lavoro software. Le storie degli utenti possono essere misurate solo se contengono espressioni chiare di tutti i movimenti di dati che saranno necessari e misurati. La misurabilità aiuta in modo significativo sia nella pianificazione che nella garanzia della qualità. La dimensione funzionale non è l’unico attributo misurabile di una user story, tuttavia è uno dei più importanti (perché è strettamente correlato allo sforzo per costruirla).

Mancia: La mancata misurazione delle dimensioni aggiunge incertezza al lavoro del software.

Mancia: Scopri la metodologia di dimensionamento COSMIC da questa guida.

Sfondo

L'unità di misura base è la Punto funzione COSMIC che è uno standard ISO per le dimensioni. Inizia il tuo percorso di apprendimento con questo aggiornamento, guida per il software di misurazione.

Una stima anticipata della CFP è molto utile poiché, man mano che i dettagli del requisito diventano noti, tale stima si avvicinerà a una misurazione più precisa.

Universalmente applicabile

Per coloro che si oppongono alla stima o alla misurazione delle dimensioni (funzionali) dei requisiti, considerare quanto segue. La dimensione minima di una user story è di 2-3 CFP. Il costo tipico per lo sviluppo di un CFP è $200 – $2000. Il tempo necessario per stimare la dimensione è di circa 10 minuti per CFP manualmente o 2 minuti con l'aiuto dell'automazione. Conoscere le dimensioni è incredibilmente prezioso per determinare quanto costerà il progetto, quanto tempo richiederà e altro ancora. Sia l’attività di “conoscere la taglia” che quella di “effettuare il dimensionamento” riducono l’incertezza e migliorano la qualità.

Stima automatizzata delle dimensioni

ScopeMaster è stato originariamente progettato con l'obiettivo primario di determinare la dimensione funzionale (punti funzione COSMIC e IFPUG) dai requisiti software. Le stime delle dimensioni di ScopeMaster sono state convalidate come tipicamente entro 15% di una dimensione determinata manualmente. Ciò non solo riduce il lavoro di esecuzione del dimensionamento, ma aiuta a introdurre il dimensionamento ingegneristico formale a coloro che attualmente non sono consapevoli dell'esistenza di tecniche così preziose.

6. Coerente

Usa parole coerenti per entrambi tipi_utente E tipi_oggetto attraverso una serie di storie utente. Una denominazione coerente ridurrà confusione, difetti, rilavorazioni e sprechi. I sistemi complessi e gli ambienti ricchi di gergo tendono ad avere la tendenza ad avere termini diversi da parte dei membri del team allo stesso utente o oggetto.

Controlli di coerenza automatizzati

Dopo aver analizzato il testo individuale di ciascuna storia, il motore ScopeMaster effettua riferimenti incrociati a tutte le storie degli utenti all'interno di un set (o backlog). Identifica ogni occorrenza di tipi di oggetto e li presenta in forma tabellare in modo che le incongruenze possano essere individuate facilmente e rapidamente.

7. Completa

I requisiti mancanti sono una delle principali cause di fallimento dei progetti software. La maggior parte dei progetti aumenta di dimensioni man mano che diventano evidenti ulteriori esigenze. Questo aumento della portata porta a più lavoro, più rielaborazioni, tempistiche più estese, superamenti del budget e in alcuni casi al fallimento del progetto. Sebbene l’approccio Agile scoraggi un eccessivo lavoro iniziale, è essenziale un po’ di lavoro esplorativo iniziale. Cerca attentamente i requisiti mancanti quando scrivi le tue storie utente.

Controllo automatizzato della completezza

Il motore di analisi ScopeMaster identifica tutte le occorrenze di un object_type in una serie di user story. Quindi esegue un'analisi CRUD. per identificare storie potenzialmente mancanti. ScopeMaster suggerisce anche quale potrebbe essere la storia mancante.

Ottenere una comprensione completa dell’intera portata di un progetto nelle prime fasi del suo ciclo di vita è estremamente prezioso per i project manager.

8. Unico

Tutti i requisiti dovrebbero essere unici. I requisiti duplicati sono un problema che tende a essere più diffuso nei progetti più grandi.

Controllo automatizzato dell'unicità

Il motore di analisi ScopeMaster identifica tutte le occorrenze di un object_type (e l'intento funzionale associato) in una serie di storie utente. Laddove sono presenti due storie che eseguono la stessa operazione CRUD su un oggetto, queste vengono evidenziate.

9. Prezioso

Tutte le storie degli utenti dovrebbero essere preziose per il "business". È opportuno mettere in discussione il valore e l'importanza di ciascuna storia utente, in modo che venga fornita solo la funzionalità più importante. Se non è possibile ricondurre una user story alla fornitura di un risultato aziendale misurabile, potrebbe non avere valore e forse dovrebbe essere eliminata. Il valore finanziario effettivo della storia può essere difficile da misurare, utilizzando la dimensione funzionale (CFP) come base per il valore (in particolare per la misurazione del valore guadagnato EVM).

10. Senza design

Le storie degli utenti non dovrebbero fare riferimento alla tecnologia utilizzata per fornirle. Questo livello di dettaglio può essere incluso come supplemento alla storia dell'utente per aiutare a fornire il contesto sul "come" dovrebbe essere consegnato. Ciò è particolarmente adatto per gli aspetti non funzionali di come verrà ottenuta la funzionalità.

Controllo automatizzato del linguaggio tecnico

Il motore di analisi ScopeMaster ricerca centinaia di frasi tecniche e altra terminologia inappropriata per le storie degli utenti.

Raccomandazione

Lascia che ScopeMaster testi le tue storie utente per te, basta importarle e premere il pulsante verde, la sua analisi linguistica intelligente valuterà la qualità e fornirà consigli per migliorare le tue storie utente.

Conclusione

Man mano che ci muoviamo verso il lavoro da remoto, aumenta la nostra dipendenza dalla parola scritta nello sviluppo del software. Dedica del tempo a pronunciare le parole giuste. Storie utente di buona qualità sono il fondamento di un software di qualità. Dovresti testare le storie degli utenti prima di iniziare a scrivere codice, per evitare perdite di tempo.

Ognuno di questi 10 test rappresenta un attributo di qualità di una buona user story. Puoi utilizzarlo come elenco di controllo da confrontare con ciascuna storia utente che scrivi. Testare le storie degli utenti pagherà dividendi significativi riducendo le rielaborazioni, riducendo lo spostamento dell'ambito, riducendo la volatilità dell'ambito. E se vuoi farlo più velocemente, prova ScopeMaster, fa il lavoro pesante di testare le storie degli utenti.

Storie utente agili

Molti Agilisti usano il file Lista di controllo INVESTIRE criteri per le storie degli utenti originariamente di Bill Wake:

IOndipendente
Nnegoziabile
Vutile
Estimabile
Scentro commerciale
Tstabile

Attenzione all'utilizzo di INVEST

L'autore originale sottolinea che INVEST è un sottoinsieme incompleto di attributi.
Non riconosce che le storie degli utenti possano essere interdipendenti.
Richiede che le storie siano orientate all'utente.
Non insiste sul fatto che le storie non siano ambigue.
Non riconosce i pericoli derivanti dal lavorare su una comprensione incompleta dell’ambito.
Non incoraggia l'analisi disciplinata (denominazione coerente, orientata all'utente, concisione)
Non richiede che le storie siano misurabili (sebbene si riferisca a Stimabile, questo è un criterio molto vago).

La creazione originale di INVEST menziona anche che le attività dovrebbero essere trattate diversamente e che dovrebbe essere applicato l'acronimo SMART:

Specifica
Misurabile
Realizzabile
Realistico
Limitato al tempo

Ho sempre ritenuto che i controlli SMART fossero efficaci e appropriati per le attività, ma non per le storie degli utenti.

Perché dovremmo scrivere storie utente migliori?

Come tutti i tipi di lavoro basato sulla conoscenza, la stesura delle storie degli utenti (o dei requisiti software) è soggetta a errori. Questi errori devono essere risolti prima che il software venga sviluppato, altrimenti richiedono molto tempo e sono troppo costosi da risolvere una volta. È più probabile che una user story scritta da una persona abbia il potenziale per essere interpretata erroneamente dai suoi lettori.