Menu

Come i tester sono coinvolti nelle tecniche TDD, BDD e ATDD

how testers are involved tdd

Prova Il Nostro Strumento Per Eliminare I Problemi

Panoramica delle tecniche TDD, BDD e ATDD:

TDD, BDD e ATDD sono i termini che hanno rivoluzionato il mondo dei tester in Agile e hanno anche guadagnato slancio. Cambiamento nella mentalità dei tester richiede anche l'apprendimento di nuove abilità e, cosa più importante, il cambiamento dell'atteggiamento e del modo di lavorare.

A differenza del lavoro isolato, i tester devono collaborare e lavorare insieme ai programmatori, il che significa

  • Condivisione dei casi di test
  • Partecipare alla scrittura dei criteri di accettazione delle storie
  • Fornire feedback continuo agli stakeholder
  • Collaborare per risolvere i difetti in tempo.
  • Fornire suggerimenti e input per migliorare la qualità dei risultati finali
  • Automazione

Tester coinvolti in Agile

Prima di passare alla discussione sul coinvolgimento di un tester in queste pratiche, proviamo prima a comprendere i concetti alla base di questi termini:

Cosa imparerai:

Sviluppo basato su test

Considera l'approccio tradizionale dello sviluppo del software in cui il codice viene prima scritto e poi testato. Lo sviluppo basato su test o TDD è un approccio che è l'esatto INVERSO dello sviluppo tradizionale. In questo approccio, prima viene eseguito il test e quindi viene scritto il codice.

Confuso?!!

Come possiamo testare un software che deve ancora essere sviluppato?

Sì!! Questo è lo sviluppo basato sui test o TDD.

TDD funziona in piccoli incrementi dove:

  • Il test viene scritto per primo
  • Il test viene eseguito, il che fallirà (per ovvi motivi)
  • Il codice viene scritto (o modificato) solo per far passare il test case
  • Il test viene eseguito di nuovo
  • Se il test ha esito positivo, passare al test successivo ELSE riscrivere / modificare il codice per eseguire il test

Vorrei provare a spiegarlo attraverso un diagramma di flusso:

Diagramma di flusso TDD

Ora, dobbiamo capire il fatto che TDD non parla dei test che fanno i tester. Piuttosto questo approccio parla effettivamente dei test che fanno i programmatori.

Sì!! Hai indovinato bene !! È l'unità di test.

Il test che viene scritto per primo non è il test che scrivono i tester, ma è lo unit test che scrivono i programmatori. Quindi, riformulerei i passaggi come:

  • Il test UNIT viene scritto per primo
  • Viene eseguito il test UNIT, che fallirà (per ovvi motivi)
  • Il codice viene scritto (o refactored) solo per far passare il test
  • Il test UNIT viene eseguito di nuovo
  • Se il test viene superato, passare al test successivo ELSE riscrive / modifica il codice per eseguire il test

Ora, la domanda che sorge qui è: se TDD è il lavoro di un programmatore, qual è il ruolo del tester in questo approccio?

Ebbene, detto che TDD è un lavoro di programmatore, non significa che i tester non ne siano coinvolti. I tester possono collaborare condividendo gli scenari di test costituiti da:

Quello che voglio dire è che i tester dovrebbero partecipare alla definizione degli scenari di unit test e collaborare con i programmatori per implementarli. I tester dovrebbero fornire il loro feedback sui risultati del test.

Se vogliamo implementare il TDD, i tester devono aggiornare i loro set di abilità. Devono essere più tecnici e concentrarsi sul miglioramento delle loro capacità analitiche e logiche.

I tester dovrebbero anche sforzarsi di comprendere il gergo tecnico utilizzato dai programmatori e, se possibile, devono avere una visione a volo d'uccello del codice. In modo simile, i programmatori devono entrare nei panni del tester e cercare di escogitare scenari più sofisticati che renderanno l'unità di test più robusta e solida.

Sia i programmatori che i tester devono mettersi a vicenda nei panni, a differenza del vecchio approccio tradizionale in cui i programmatori non davano molto peso ai test unitari perché si affidavano ai tester per trovare bug e difetti, ei tester non volevano sbizzarrirsi ad apprendere le cose tecniche perché pensano che il loro lavoro finisca dopo aver trovato i difetti.

Sviluppo guidato dal comportamento

Behavior Driven Development o BDD è un'estensione di Test Driven Development.

BDD, come suggerisce il nome, illustra i metodi di sviluppo di una funzionalità in base al suo comportamento. Il comportamento è sostanzialmente spiegato in termini di esempi in un linguaggio molto semplice che può essere compreso da tutti i membri del team che sono responsabili dello sviluppo.

Alcune delle caratteristiche principali di BDD sono le seguenti:

  • Il linguaggio utilizzato per definire il comportamento è molto semplice e in un unico formato in cui può essere compreso da tutti - sia tecnici che non tecnici coinvolti nell'implementazione
  • Fornisce una piattaforma che consente ai tre amici (programmatore, tester e PO / BA) di collaborare e comprendere il requisito. Determina un modello comune per documentarlo
  • Questa tecnica / approccio discute il comportamento finale del sistema o come il sistema dovrebbe comportarsi e NON parla di come il sistema dovrebbe essere progettato o implementato
  • Sottolinea entrambi gli aspetti della qualità:
    • Soddisfa il requisito
    • Adatto per l'uso

Perché BDD?

Bene, sappiamo che riparare un difetto / bug nella fase successiva di qualsiasi ciclo di sviluppo è piuttosto costoso. La riparazione dei difetti di produzione non influisce solo sul codice ma anche sul design e sui suoi requisiti. Quando facciamo il RCA (analisi delle cause alla radice) di qualsiasi difetto, il più delle volte, concludiamo che il difetto in realtà si riduce a requisiti mal compresi.

Fondamentalmente questo accade perché ognuno ha attitudini diverse per comprendere i requisiti. Pertanto, le persone tecniche e non tecniche possono interpretare lo stesso requisito in modo diverso, il che può portare a una consegna difettosa. Pertanto, è fondamentale che tutti i membri del team di sviluppo comprendano lo STESSO requisito e lo interpretino nello STESSO modo.

Dobbiamo assicurarci che tutti gli sforzi di sviluppo siano diretti e focalizzati verso il soddisfacimento dei requisiti. Al fine di evitare qualsiasi tipo di difetto 'requisito - mancato', l'intero team di sviluppo deve allinearli per comprendere il requisito idoneo all'uso.

L'approccio BDD consente al team di sviluppo di farlo: -

  • Definizione di un approccio standard per definire il requisito in inglese semplice
  • Fornitura di esempi di definizione che spieghino i requisiti
  • Fornire un'interfaccia / piattaforma che consenta ai tecnici (programmatori / tester) e non tecnici (PO / BA / Cliente) di collaborare e riunirsi ed essere sulla stessa pagina per comprendere e implementare i requisiti

Come implementare BDD?

Ci sono molti strumenti disponibili sul mercato per l'implementazione di BDD. Ne nomino alcuni qui:

  • Cetriolo
  • Fitness
  • Concordion
  • JBehave
  • Flusso delle specifiche

Esempio:

Proviamo a capire BDD con un esempio. Per il mio caso, sto usando Gherkin (Cetriolo):

Considera un semplice caso in cui vogliamo consentire solo agli utenti autenticati di accedere al sito XYZ.

Il file Gherkin (file delle caratteristiche) sarebbe il seguente:

Caratteristica: Test del portale di registrazione

Schema dello scenario: Utente valido registrato

Dato: Il cliente apre il portale di registrazione

Quando: l'utente inserisce il nome utente come '' e la password come ''

Poi: il cliente dovrebbe essere in grado di visualizzare il modulo.

Esempi :

| utente | password |

| user1 | pwd1 |

| user2 | pwd2 |

Possiamo vedere come un particolare requisito viene documentato utilizzando un inglese semplice. I tre amigo possono lavorare insieme per progettare i file delle caratteristiche e i dati di test specifici possono essere documentati nella sezione di esempio. BDD fornisce un mezzo per riunire programmatori, tester e aziende su un tavolo e stabilire una comprensione comune delle funzionalità da implementare.

L'approccio BDD consente di risparmiare fatica e costi e controlla se ci sono difetti dopo l'implementazione della produzione poiché la collaborazione dei clienti e degli sviluppatori è stata durante tutto il ciclo di sviluppo della funzionalità.

I team di sviluppo possono utilizzare questi file di funzionalità e convertirli in programmi eseguibili per testare una funzionalità particolare.

Come?

Bene, devi imparare Cucumber / Fitnesse per questo !!

Sviluppo guidato dal test di accettazione

L'Acceptance Test Driven Development o ATDD è una tecnica in cui l'intero team collabora per definire i criteri di accettazione di un'epica / storia prima che l'implementazione abbia effettivamente inizio. Questi test di accettazione sono supportati da esempi appropriati e altre informazioni necessarie.

Il più delle volte, BDD e ATDD sono usati in modo intercambiabile. L'approccio ATDD può anche essere implementato utilizzando il formato dato-quando-allora, proprio come il modo in cui scriviamo le caratteristiche nell'approccio BDD.

Proviamo rapidamente a riassumere le differenze tra i 3 approcci:

  • TDD è più tecnico ed è scritto nella stessa lingua in cui è implementata la funzionalità. Se la funzionalità è implementata in Java, scriviamo JUnit casi test . Mentre BDD & ATDD è scritto in una semplice lingua inglese
  • L'approccio TDD si concentra sull'implementazione di una funzionalità. Mentre BDD si concentra sul comportamento della funzione e ATDD si concentra sull'acquisizione dei requisiti
  • Per implementare TDD abbiamo bisogno di conoscenze tecniche. Mentre BDD e ATDD non richiedono alcuna conoscenza tecnica. La bellezza di BDD / ATDD sta nel fatto che sia i tecnici, sia i non tecnici, possono partecipare allo sviluppo della funzione
  • Poiché il TDD è evoluto, offre spazio per un buon design e si concentra sull'aspetto della qualità 'Requisiti di soddisfazione'; mentre BDD / ATDD si concentrano su 2ndaspetto della qualità che è 'Idoneo all'uso'

Tutte queste tecniche parlano fondamentalmente dell'approccio 'test-First', a differenza dell'approccio 'test-last' utilizzato nelle metodologie di sviluppo tradizionali.

Poiché i test vengono scritti per primi, i tester svolgono un ruolo molto importante. Non solo i tester devono avere un vasto dominio e conoscenze aziendali, ma devono anche possedere buone capacità tecniche in modo da poter aggiungere valore al brainstorming durante le discussioni dei 3 amigos.

Con concetti come CI (Continuous Integration) e CD (Continuous Delivery), i tester devono collaborare bene con i programmatori e contribuire allo stesso modo all'area di sviluppo e operazioni.

quale strato del modello osi viene utilizzato per cose come segnali, bit, cavi e connettori?

Permettetemi di riassumere questa discussione con la famosa piramide di test in Agile:

Prova la piramide in Agile

Lo strato più basso di questa piramide è costituito dallo strato di test unitario. Questo strato è lo strato di fondazione; quindi è imperiale che questo strato sia solido come una roccia. La maggior parte dei test dovrebbe essere inserita in questo livello. Questo livello più basso si concentra solo su TDD.

Nel Agile world, si pone l'accento sul rendere questo strato della piramide più forte e robusto e si sottolinea che la maggior parte dei test viene eseguita a questo livello.

Gli strumenti utilizzati in questo livello di una piramide sono tutti gli strumenti di Xunit.

Lo strato intermedio della piramide è il livello di servizio, che spiega i test del livello di servizio. Questo livello funge da ponte tra l'interfaccia utente dell'applicazione e l'unità / componente di livello inferiore. Questo livello comprende principalmente le API che accettano richieste dall'interfaccia utente e restituiscono la risposta. L'approccio BDD e TTDD è attivo in questo strato della piramide.

Gli strumenti utilizzati nello strato intermedio della piramide sono: Fitnesse, Cucumber e Robot Framework .

Il livello più in alto della piramide è l'interfaccia utente effettiva, che mostra che questo livello dovrebbe contenere il minor numero di test, o dovrei dire, lo sforzo di test in questo particolare livello dovrebbe essere minimo. La maggior parte dei test della funzione dovrebbero essere stati completati quando raggiungiamo il livello superiore della piramide.

Gli strumenti utilizzati nel livello superiore sono: Selenio , QTP e RFT.

Poiché lavoriamo in piccoli incrementi in Mischia (chiamati Sprint), l'implementazione manuale di tutti questi approcci non è fattibile. Questi approcci richiedono un intervento automatizzato. L'automazione, in questo caso, è molto critica.

In effetti, questi approcci vengono effettivamente eseguiti attraverso l'automazione. Alla fine di ogni sprint, vengono aggiunte nuove funzionalità, quindi diventa importante che la funzionalità implementata in precedenza funzioni come previsto; quindi, Automazione diventa l'EROE qui.

Conclusione

Entro la fine dell'articolo, devi aver appreso come i tester sono coinvolti nelle tecniche TDD, BDD e ATDD.

Nella terza parte della serie, concentrerò la mia discussione sull'automazione in un mondo Agile.

Circa l'autore: Questo articolo è dell'autore STH Shilpa. Negli ultimi 10 anni lavora nel campo del test del software in domini come la pubblicità su Internet, gli investimenti bancari e le telecomunicazioni.

Continua a guardare questo spazio per molti altri aggiornamenti.

Lettura consigliata

^