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"

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 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 

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.

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.

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.

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.

8. Unico

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

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à.

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.

Requisiti La qualità in sintesi

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.