BDD - Specifiche per esempio

Secondo Gojko Adzic, l'autore di "Specification by Example", Specification by Example è un insieme di schemi di processo che facilitano il cambiamento nei prodotti software per garantire che il prodotto giusto sia consegnato in modo efficiente ".

La specifica per esempio è un approccio collaborativo per definire i requisiti e i test funzionali orientati al business per i prodotti software basati sull'acquisizione e l'illustrazione dei requisiti utilizzando esempi realistici invece di dichiarazioni astratte.

Specifica per esempio - Panoramica

L'obiettivo della specifica per esempio è concentrarsi sullo sviluppo e la fornitura di requisiti aziendali prioritari e verificabili. Sebbene il concetto di specifica per esempio sia di per sé relativamente nuovo, è semplicemente una riformulazione di pratiche esistenti.

Supporta un vocabolario molto specifico e conciso noto come linguaggio onnipresente che:

  • Abilita i requisiti eseguibili.

  • Viene utilizzato da tutti i membri del team.

  • È creato da un team interfunzionale.

  • Cattura la comprensione di tutti.

La specifica per esempio può essere utilizzata come input diretto nella creazione di test automatizzati che riflettono il dominio aziendale. Pertanto, il focus della specifica per esempio è sulla costruzione del prodotto giusto e sulla costruzione del prodotto giusto.

Scopo della specifica per esempio

Lo scopo principale della specifica per esempio è costruire il prodotto giusto. Si concentra sulla comprensione condivisa, stabilendo così un'unica fonte di verità. Consente l'automazione dei criteri di accettazione in modo che l'attenzione si concentri sulla prevenzione dei difetti piuttosto che sul rilevamento dei difetti. Promuove anche il test precoce per trovare i difetti in anticipo.

Uso di SbE

La specifica per esempio viene utilizzata per illustrare il comportamento del sistema previsto che descrive il valore aziendale. L'illustrazione è per mezzo di esempi concreti e di vita reale. Questi esempi vengono utilizzati per creare requisiti eseguibili che sono:

  • Testabile senza traduzione.

  • Catturato nella documentazione live.

Di seguito sono riportati i motivi per cui utilizziamo esempi per descrivere specifiche particolari:

  • Sono più facili da capire.

  • Sono più difficili da interpretare male.

Vantaggi di SbE

I vantaggi dell'utilizzo della specifica per esempio sono:

  • Maggiore qualità

  • Riduzione degli sprechi

  • Rischio ridotto di difetti di produzione

  • Sforzo mirato

  • Le modifiche possono essere apportate in modo più sicuro

  • Migliore coinvolgimento delle imprese

Applicazioni di SbE

Specifica per esempio trova applicazioni in -

  • O azienda complessa o organizzazione complessa.

  • Non funziona bene per problemi puramente tecnici.

  • Non funziona bene per i prodotti software focalizzati sull'interfaccia utente.

  • Può essere applicato anche a sistemi legacy.

SbE e test di accettazione

I vantaggi della specifica per esempio in termini di test di accettazione sono:

  • Una singola illustrazione viene utilizzata sia per i requisiti dettagliati che per i test

  • Lo stato di avanzamento del progetto è in termini di Test di accettazione -

    • Ogni test serve a testare un comportamento.

    • Un test sta passando per un comportamento o non lo è.

    • Un test di superamento rappresenta che il comportamento particolare è stato completato.

    • Se un progetto che richiede 100 comportamenti per essere completato ha 60 comportamenti completati, allora è finito al 60%.

  • I tester passano dalla correzione dei difetti alla prevenzione dei difetti e contribuiscono alla progettazione della soluzione.

  • L'automazione consente la comprensione immediata dell'impatto di una modifica dei requisiti sulla soluzione.

Specifica per esempio: cosa significa per ruoli diversi

L'obiettivo della specifica per esempio è promuovere la collaborazione di tutti i membri del team, incluso il cliente durante tutto il progetto per fornire valore aziendale. Tutti per una migliore comprensibilità usano lo stesso vocabolario.

Ruolo Uso di SbE
Analista di affari

  • I requisiti sono inequivocabili e senza lacune funzionali.

  • Sviluppatori, effettivamente leggono le specifiche.
Sviluppatore

  • Gli sviluppatori capiscono meglio cosa si sta sviluppando.

  • Il progresso dello sviluppo viene monitorato meglio contando le specifiche che sono state sviluppate correttamente.
Tester

  • I tester capiscono meglio ciò che viene testato.

  • I tester sono coinvolti sin dall'inizio e hanno un ruolo nella progettazione.

  • I tester lavorano per la prevenzione dei difetti piuttosto che per il rilevamento dei difetti.
Tutti

  • Il tempo si risparmia identificando gli errori dall'inizio.

  • Fin dall'inizio si produce un prodotto di qualità.

SbE - Una serie di modelli di processo

Come abbiamo visto all'inizio di questo capitolo, la specifica per esempio è definita come un insieme di schemi di processo che facilitano il cambiamento nei prodotti software per garantire che il prodotto giusto sia consegnato in modo efficiente.

I modelli di processo sono:

  • Specifica collaborativa

  • Illustrare le specifiche utilizzando esempi

  • Affinamento delle specifiche

  • Automatizzare gli esempi

  • Convalida frequentemente

  • Documentazione vivente

Specifica collaborativa

Gli obiettivi della specifica collaborativa sono:

  • Ottieni i vari ruoli in una squadra per avere una comprensione comune e un vocabolario condiviso.

  • Coinvolgi tutti nel progetto in modo che possano contribuire con le loro diverse prospettive su una caratteristica.

  • Garantire una comunicazione condivisa e la proprietà delle funzionalità.

Questi obiettivi vengono raggiunti in un seminario sulle specifiche noto anche come riunione dei Tre Amigos. I tre Amigos sono BA, QA e lo sviluppatore. Sebbene ci siano altri ruoli nel progetto, questi tre sarebbero responsabili e responsabili dalla definizione alla consegna delle caratteristiche.

During the meeting −

  • Il Business Analyst (BA) presenta i requisiti e i test per una nuova funzionalità.

  • I tre Amigo (BA, Developer e QA) discutono la nuova funzionalità e rivedono le specifiche.

  • Il QA e lo sviluppatore identificano anche i requisiti mancanti.

  • I tre Amigo

    • Utilizza un modello condiviso utilizzando un linguaggio onnipresente.

    • Usa il vocabolario del dominio (un glossario viene mantenuto se necessario).

    • Cerca differenze e conflitti.

  • Non saltare ai dettagli di implementazione a questo punto.

  • Raggiungi un consenso sul fatto che una caratteristica sia stata specificata sufficientemente.

  • Un senso condiviso dei requisiti e della proprietà dei test facilita le specifiche di qualità

  • I requisiti sono presentati come scenari, che forniscono requisiti espliciti e non ambigui. Uno scenario è un esempio del comportamento del sistema dal punto di vista degli utenti.

Illustrare le specifiche utilizzando esempi

Gli scenari vengono specificati utilizzando la struttura Dato-Quando-Allora per creare una specifica verificabile -

Given <qualche precondizione>

And <condizioni preliminari aggiuntive> Optional

When <si verifica un'azione / trigger>

Then <qualche condizione del post>

And <condizioni post aggiuntive> Optional

Questa specifica è un esempio di un comportamento del sistema. Rappresenta anche un criterio di accettazione del sistema.

Il team discute gli esempi e il feedback viene incorporato fino a quando non si concorda sul fatto che gli esempi coprono il comportamento previsto della funzionalità. Ciò garantisce una buona copertura del test.

Affinamento della specifica

Per perfezionare una specifica,

  • Sii preciso nello scrivere gli esempi. Se un esempio si rivela complesso, suddividilo in esempi più semplici.

  • Concentrati sulla prospettiva aziendale ed evita i dettagli tecnici.

  • Considera condizioni sia positive che negative.

  • Attenersi al vocabolario specifico del dominio.

  • Discuti gli esempi con il cliente.

    • Scegli le conversazioni per farlo.

    • Considera solo quegli esempi a cui il cliente è interessato. Ciò consente la produzione solo del codice richiesto ed evita di coprire ogni possibile combinazione, che potrebbe non essere richiesta

  • Per garantire che lo scenario venga superato, devono essere superati tutti i casi di test per quello scenario. Quindi, migliorare le specifiche per renderle testabili. I casi di test possono includere vari intervalli e valori di dati (boundary e corner case) nonché diverse regole aziendali che comportano modifiche nei dati.

  • Specificare regole di business aggiuntive come calcoli complessi, manipolazione / trasformazione dei dati, ecc.

  • Includere scenari non funzionali (ad esempio prestazioni, carico, usabilità, ecc.) Come Specifica per esempio

Esempi di automazione

Il livello di automazione deve essere mantenuto molto semplice: basta collegare le specifiche al sistema in prova. Puoi usare uno strumento per lo stesso.

Esegui l'automazione dei test utilizzando il linguaggio DSL (Domain Specific Language) e mostra una chiara connessione tra input e output. Concentrati sulle specifiche e non sullo script. Assicurati che i test siano precisi, facili da capire e verificabili.

Convalida frequentemente

Includere la convalida di esempio nella pipeline di sviluppo con ogni modifica (aggiunta / modifica). Esistono molte tecniche e strumenti che possono (e dovrebbero) essere adottati per garantire la qualità di un prodotto. Ruotano attorno a tre principi chiave:Test Early, Test Well e Test Often.

Eseguire i test frequentemente in modo da poter identificare i collegamenti deboli. Gli esempi che rappresentano i comportamenti aiutano a tenere traccia dei progressi e si dice che un comportamento sia completo solo dopo il superamento del test corrispondente.

Documentazione vivente

Mantieni le specifiche il più semplici e brevi possibile. Organizza le specifiche ed evolvile man mano che il lavoro procede. Rendi la documentazione accessibile a tutti i membri del team.

Specifica tramite passaggi di processo di esempio

L'illustrazione mostra le fasi del processo in Specifica per esempio.

Anti-modelli

Gli anti-pattern sono determinati modelli nello sviluppo del software che sono considerati una cattiva pratica di programmazione. Al contrario dei modelli di progettazione, che sono approcci comuni a problemi comuni, che sono stati formalizzati e sono generalmente considerati una buona pratica di sviluppo, gli anti-modelli sono l'opposto e non sono desiderabili

Gli anti-pattern danno origine a vari problemi.

Anti-pattern I problemi
Nessuna collaborazione

  • Molte ipotesi

  • Costruire cosa sbagliata

  • Testare cosa sbagliata

  • Ignaro quando il codice è finito
Ignaro quando il codice è finito

  • Difficile mantenere i test

  • Spec. Difficile da capire

  • Perdita di interesse da parte dei rappresentanti delle imprese
Esempi troppo dettagliati o troppo incentrati sull'interfaccia utente

  • Difficile mantenere i test

  • Specifiche difficili da capire

  • Perdita di interesse da parte dei rappresentanti delle imprese
Sottovalutare lo sforzo richiesto

  • Le squadre pensano di aver fallito e rimangono deluse presto

Soluzione ai problemi - Qualità

La qualità può essere garantita tenendo d'occhio gli anti-modelli. Per ridurre al minimo i problemi creati dagli anti-pattern, dovresti:

  • Riunisciti per specificare utilizzando esempi.

  • Pulisci e migliora gli esempi.

  • Scrivi un codice che soddisfi gli esempi

  • Automatizza gli esempi e distribuisci.

  • Ripeti l'approccio per ogni user story.

Risolvere i problemi dovuti agli anti-pattern significa aderire a -

  • Collaboration.

  • Concentrandosi su cosa.

  • Concentrandosi sul business.

  • Essere preparato.

Cerchiamo di capire cosa significano ognuna delle precedenti.

Collaborazione

In collaborazione -

  • Gli uomini d'affari, gli sviluppatori e i tester danno input dal loro punto di vista.

  • Esempi automatizzati dimostrano che il team ha costruito la cosa corretta.

  • Il processo è più prezioso dei test stessi.

Concentrandosi su cosa

Devi concentrarti sulla domanda: "cosa". Mentre ci si concentra su 'cosa' -

  • Non cercare di coprire tutti i casi possibili.

  • Non dimenticare di utilizzare diversi tipi di test.

  • Mantieni gli esempi il più semplici possibile.

  • Gli esempi dovrebbero essere facilmente comprensibili dagli utenti del sistema.

  • Gli strumenti non dovrebbero svolgere un ruolo importante nei seminari.

Concentrandosi sul business

Per concentrarsi sul business -

  • Mantieni le specifiche secondo l'intento aziendale.

  • Includere l'attività nella creazione e revisione delle specifiche.

  • Nascondi tutti i dettagli nel livello di automazione.

Essere preparato

Preparati per quanto segue:

  • I vantaggi non sono immediatamente evidenti, anche se le pratiche di squadra sono cambiate.

  • L'introduzione di SbE è impegnativo.

  • Richiede tempo e investimenti.

  • I test automatizzati non sono gratuiti.

Utensili

L'uso degli strumenti non è obbligatorio per la specifica mediante esempio, sebbene in pratica siano disponibili diversi strumenti. Ci sono casi che riescono a seguire la specifica per esempio anche senza utilizzare uno strumento.

I seguenti strumenti supportano la specifica per esempio:

  • Cucumber

  • SpecFlow

  • Fitnesse

  • Jbehave

  • Concordion

  • Behat

  • Jasmine

  • Relish

  • Speclog