Menu

Hoe de testers worden betrokken bij TDD-, BDD- en ATDD-technieken

  • Hoofd
  • Agile Testen
  • Hoe de testers worden betrokken bij TDD-, BDD- en ATDD-technieken

how testers are involved tdd

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Overzicht van TDD-, BDD- en ATDD-technieken:

TDD, BDD en ATDD zijn de termen die de wereld van testers in Agile radicaal hebben veranderd en ook in een stroomversnelling zijn gekomen. Verandering in de mentaliteit van testers vereist ook het aanleren van nieuwe vaardigheden en, nog belangrijker, het veranderen van de houding en de manier van werken.

In tegenstelling tot geïsoleerd werken, moeten testers samenwerken en samenwerken met de programmeurs, wat betekent

  • Het delen van de testcases
  • Deelnemen aan het schrijven van de acceptatiecriteria van de verhalen
  • Continu feedback geven aan de belanghebbenden
  • Samenwerken om de gebreken op tijd op te lossen.
  • Geef suggesties en input om de kwaliteit van de te leveren producten te verbeteren
  • Automatisering

Testers die betrokken zijn bij Agile

Voordat ik inga op de bespreking van de betrokkenheid van een tester bij deze praktijken, proberen we eerst de concepten achter deze termen te begrijpen:

Wat je leert:

Test gedreven ontwikkeling

Overweeg de traditionele benadering van softwareontwikkeling, waarbij de code eerst wordt geschreven en vervolgens wordt getest. Testgestuurde ontwikkeling of TDD is een benadering die exact het omgekeerde is van traditionele ontwikkeling. Bij deze benadering wordt eerst getest en vervolgens wordt de code geschreven.

Verward?!!

Hoe kunnen we een stuk software testen dat nog moet worden ontwikkeld?

Ja!! Dat is testgestuurde ontwikkeling of TDD.

TDD werkt in kleine stappen waarbij:

  • De test wordt eerst geschreven
  • De test wordt uitgevoerd - die zal mislukken (om voor de hand liggende redenen)
  • De code is geschreven (of opnieuw ontworpen) om de testcase te laten slagen
  • De test wordt opnieuw uitgevoerd
  • Als de test slaagt, ga dan verder met de volgende test. ELSE herschrijf / wijzig de code om de test te laten slagen

Laat me proberen het uit te leggen aan de hand van een stroomschema:

TDD-stroomdiagram

Nu moeten we begrijpen dat TDD het niet heeft over de tests die testers doen. Deze benadering spreekt eerder over het testen dat de programmeurs doen.

Ja!! Je raadt het goed !! Het is het testen van eenheden.

De test die als eerste wordt geschreven, is niet de test die de testers schrijven, maar de unit-test die de programmeurs schrijven. Dus ik zou de stappen anders formuleren als:

  • De UNIT-test wordt eerst geschreven
  • De UNIT-test wordt uitgevoerd - die zal mislukken (om voor de hand liggende redenen)
  • De code is geschreven (of opnieuw ingesteld) om de test te laten slagen
  • De UNIT-test wordt opnieuw uitgevoerd
  • Als de test slaagt, ga dan verder met de volgende test. ELSE herschrijf / wijzig de code om de test te laten slagen

De vraag die hier rijst is: als TDD de taak van een programmeur is, wat is dan de rol van de tester in deze benadering?

Dat gezegd hebbende, TDD is de taak van een programmeur, maar dat betekent niet dat de testers er niet bij betrokken zijn. Testers kunnen samenwerken door de testscenario's te delen, bestaande uit:

Wat ik wil zeggen is: testers moeten deelnemen aan het definiëren van de unit-testscenario's en samenwerken met de programmeurs om hetzelfde te implementeren. Testers moeten feedback geven over de testresultaten.

Als we TDD willen implementeren, moeten testers hun vaardigheden upgraden. Ze moeten technischer zijn en zich richten op het verbeteren van hun analytische en logische vaardigheden.

Testers moeten ook moeite doen om het technische jargon dat de programmeurs gebruiken te begrijpen, en, indien mogelijk, de code in vogelvlucht kunnen bekijken. Op een vergelijkbare manier moeten de programmeurs in de schoenen van de tester stappen en proberen geavanceerdere scenario's te bedenken die het testen van de unit robuuster en solide maken.

Zowel programmeurs als testers moeten in elkaars schoenen stappen, in tegenstelling tot de oude traditionele aanpak waarbij de programmeurs niet veel gewicht hechtten aan de unit-tests omdat ze vertrouwden op de testers voor het vinden van bugs en defecten, en de testers wilden zichzelf niet uitleven om de technische dingen te leren omdat ze denken dat hun baan eindigt nadat ze de defecten hebben gevonden.

Gedragsgestuurde ontwikkeling

Behaviour Driven Development of BDD is een uitbreiding op Test Driven Development.

BDD illustreert, zoals de naam suggereert, de methoden om een ​​functie te ontwikkelen op basis van zijn gedrag. Het gedrag wordt in principe uitgelegd in termen van voorbeelden in een zeer eenvoudige taal die kan worden begrepen door iedereen in het team die verantwoordelijk is voor de ontwikkeling.

Enkele van de belangrijkste kenmerken van BDD zijn:

  • De taal die wordt gebruikt om het gedrag te definiëren is heel eenvoudig en in één formaat waarin het door iedereen kan worden begrepen - zowel technische als niet-technische mensen die bij de implementatie zijn betrokken
  • Biedt een platform waarmee de drie amigo's (programmeur, tester en PO / BA) kunnen samenwerken en de vereiste begrijpen. Bepaalt een algemeen sjabloon om het te documenteren
  • Deze techniek / benadering bespreekt het uiteindelijke gedrag van het systeem of hoe het systeem zich zou moeten gedragen en er wordt NIET gesproken over hoe het systeem moet worden ontworpen of geïmplementeerd
  • Benadrukt op beide aspecten van kwaliteit:
    • Voldoe aan de vereiste
    • Geschikt voor gebruik

Waarom BDD?

Nou, we weten dat het repareren van een defect / bug in de latere fase van een ontwikkelingscyclus is vrij kostbaar. Het verhelpen van de productiefouten heeft niet alleen invloed op de code, maar ook op het ontwerp en de vereisten ervan. Wanneer we het RCA (Root Cause Analysis) van elk defect, concluderen we meestal dat het defect in feite neerkomt op verkeerd begrepen vereisten.

Dit gebeurt in feite omdat iedereen verschillende vaardigheden heeft om de vereisten te begrijpen. Daarom kunnen technische en niet-technische mensen dezelfde eis verschillend interpreteren, wat kan leiden tot een foutieve levering. Daarom is het van cruciaal belang dat iedereen in het ontwikkelingsteam DEZELFDE vereiste begrijpt en op DEZELFDE manier interpreteert.

We moeten ervoor zorgen dat de volledige ontwikkelingsinspanningen gericht en gefocust zijn op het voldoen aan de vereisten. Om elke vorm van een 'vereiste - mis' -defect te voorkomen, moet het hele ontwikkelingsteam ze op één lijn brengen om de vereiste te begrijpen die geschikt is voor gebruik.

De BDD-benadering stelt het ontwikkelingsteam in staat dit te doen door: -

  • Een standaardbenadering definiëren om de vereiste in eenvoudig Engels te definiëren
  • Verstrekken van definiërende voorbeelden die de vereisten uitleggen
  • Zorg voor een interface / platform waarmee de technische (programmeurs / testers) en niet-technische (PO / BA / klant) kunnen samenwerken en samenkomen en op dezelfde pagina zijn om de vereisten te begrijpen en te implementeren

Hoe BDD implementeren?

Er zijn veel tools op de markt om BDD te implementeren. Ik noem er hier een paar:

  • Komkommer
  • Fitness
  • Concordion
  • J Gedraag je
  • Spec stroom

Voorbeeld:

Laten we BDD proberen te begrijpen met een voorbeeld. Voor mijn geval gebruik ik augurk (komkommer):

Beschouw een eenvoudig geval waarin we willen dat alleen geauthenticeerde gebruikers toegang krijgen tot de XYZ-site.

Het augurk-bestand (feature-bestand) zou er als volgt uitzien:

Voorzien zijn van: Test registratie portal

Scenario-overzicht: Geldige gebruiker ingelogd

Gegeven: Klant opent het registratieportaal

Wanneer: gebruiker voert de gebruikersnaam in als '' en wachtwoord als ''

Vervolgens: de klant moet het formulier kunnen bekijken.

Voorbeelden ​

| gebruiker | wachtwoord |

| gebruiker1 | pwd1 |

| gebruiker2 | pwd2 |

We kunnen zien hoe een bepaalde vereiste wordt gedocumenteerd in eenvoudig Engels. De drie amigo's kunnen samenwerken om de feature-bestanden te ontwerpen en specifieke testgegevens kunnen worden gedocumenteerd in het voorbeeldgedeelte. BDD biedt een medium om programmeurs, testers en bedrijven aan één tafel te brengen en een gemeenschappelijk begrip te krijgen van de functies die moeten worden geïmplementeerd.

De BDD-aanpak bespaart moeite en kosten en controleert of er defecten zijn na de implementatie van de productie, aangezien de samenwerking van de klanten en ontwikkelaars gedurende de ontwikkelingscyclus van de functie plaatsvond.

Ontwikkelteams kunnen deze feature-bestanden gebruiken en ze converteren naar uitvoerbare programma's om een ​​bepaalde feature te testen.

Hoe?

Nou, daarvoor moet je Cucumber / Fitnesse leren !!

Acceptatietestgestuurde ontwikkeling

Acceptance Test Driven Development of ATDD is een techniek waarbij het hele team samenwerkt om de acceptatiecriteria van een epos / verhaal te definiëren voordat de implementatie daadwerkelijk begint. Deze acceptatietests worden ondersteund door goede voorbeelden en andere noodzakelijke informatie.

Meestal worden BDD en ATDD door elkaar gebruikt. De ATDD-benadering kan ook worden geïmplementeerd met behulp van het Given-When-Then-formaat, net zoals we functies schrijven in de BDD-benadering.

Laten we snel proberen de verschillen tussen de drie benaderingen samen te vatten:

  • TDD is technischer en is geschreven in dezelfde taal waarin de functie is geïmplementeerd. Als de functie in Java is geïmplementeerd, schrijven we JUnit testgevallen ​Terwijl BDD & ATDD is geschreven in eenvoudige Engelse taal
  • De TDD-benadering richt zich op de implementatie van een functie. Terwijl BDD zich richt op het gedrag van de functie, en ATDD zich richt op het vastleggen van de vereisten
  • Om TDD te implementeren hebben we technische kennis nodig. Terwijl BDD & ATDD geen technische kennis vereisen. Het mooie van BDD / ATDD ligt in het feit dat zowel technische als niet-technische mensen kunnen deelnemen aan de ontwikkeling van de functie
  • Aangezien TDD is geëvolueerd, biedt het ruimte voor een goed ontwerp en richt het zich op het aspect “Meeting Requirement” van kwaliteit; terwijl BDD / ATDD zich richten op de 2ndaspect van kwaliteit dat 'Geschikt voor gebruik' is

Al deze technieken hebben het in feite over de 'test-First' -benadering, in tegenstelling tot de 'test-last' -benadering die wordt gebruikt in traditionele ontwikkelingsmethoden.

Omdat de tests eerst worden geschreven, spelen testers een zeer belangrijke rol. Testers moeten niet alleen een uitgebreide domein- en bedrijfskennis hebben, maar ze moeten ook over goede technische vaardigheden beschikken, zodat ze waarde kunnen toevoegen bij het brainstormen tijdens de 3 amigos-discussies.

Met de concepten als CI (Continuous Integration) en CD (Continuous Delivery), moeten testers goed samenwerken met de programmeurs en in gelijke mate bijdragen aan het ontwikkelings- en operatiegebied.

beste software voor het klonen van schijven windows 10

Laat me deze discussie samenvatten met de beroemde Test Pyramid in Agile:

Test Pyramid in Agile

De onderste laag van deze piramide bestaat uit de unit-testlaag. Deze laag is de basislaag; daarom is het essentieel dat deze laag rotsvast is. De meeste tests moeten in deze laag worden geduwd. Deze onderste laag richt zich alleen op TDD.

In de Behendig world wordt de nadruk gelegd op het sterker en robuuster maken van deze laag van de piramide en er wordt benadrukt dat de meeste testen op deze laag worden uitgevoerd.

Tools die in deze laag van een piramide worden gebruikt, zijn alle Xunit-tools.

De middelste laag van de piramide is de servicelaag, waarin de serviceniveautests worden uitgelegd. Deze laag fungeert als een brug tussen de gebruikersinterface van de applicatie en de eenheid / component op een lager niveau. Deze laag bestaat voornamelijk uit de API's die verzoeken van de gebruikersinterface accepteren en het antwoord terugsturen. De BDD- en TTDD-benadering is actief in deze laag van de piramide.

Hulpmiddelen die in de middelste laag van de piramide worden gebruikt, zijn: Fitnesse, Cucumber en Robot Framework ​

De bovenste laag van de piramide is de eigenlijke gebruikersinterface, die laat zien dat deze laag het minste aantal tests zou moeten bevatten, of ik zou moeten zeggen dat de testinspanning op deze specifieke laag minimaal zou moeten zijn. Het grootste deel van het testen van het kenmerk had moeten zijn voltooid wanneer we de bovenste laag van de piramide bereiken.

Gereedschappen die in de bovenste laag worden gebruikt zijn - Selenium ​ QTP , en RFT.

Omdat we in kleine stappen werken in Scrum (genaamd Sprints), handmatige implementatie van al deze benaderingen is niet haalbaar. Deze benaderingen vereisen geautomatiseerde tussenkomst. Automatisering is in dit geval erg cruciaal.

In feite worden deze benaderingen feitelijk uitgevoerd door middel van automatisering. Aan het einde van elke sprint worden nieuwe features toegevoegd, dus het wordt belangrijk dat de eerder geïmplementeerde feature werkt zoals verwacht; Vandaar, Automatisering wordt hier de HELD.

Gevolgtrekking

Aan het einde van het artikel moet u hebben geleerd hoe de testers betrokken zijn bij TDD-, BDD- en ATDD-technieken.

In het derde deel van de serie zal ik mijn bespreking richten op automatisering in een Agile wereld.

Over de auteur: Dit artikel is geschreven door STH Author Shilpa. Ze werkt al meer dan 10 jaar op het gebied van softwaretests in domeinen als internetreclame, investeringsbankieren en telecom.

Blijf deze ruimte in de gaten houden voor veel meer updates.

Aanbevolen literatuur

^