Als u bekend bent met TDD, dan is ATDD op de een of andere manier TDD met een hoger niveau van testen en met meer betrokken stakeholders, met andere woorden het is meer een acceptatietest dan een unit-test. Als je meer wilt weten over TDD, bekijk dan de volgende post:
Acceptatie test-gedreven ontwikkeling (ATDD) is een ontwikkelmethodologie gebaseerd op communicatie tussen de zakelijke klanten, de ontwikkelaars en de testers. ATDD omvat veel van dezelfde praktijken als specificatie door voorbeeld, gedrag-gedreven ontwikkeling (BDD), voorbeeld-gedreven ontwikkeling (EDD), en ondersteuning-gedreven ontwikkeling ook wel verhaal-test-gedreven ontwikkeling (SDD) genoemd. Al deze processen helpen ontwikkelaars en testers bij het begrijpen van de behoeften van de klant voordat deze worden geïmplementeerd en stellen klanten in staat om in hun eigen domeintaal te converseren.
Wijdverbreid geïmplementeerd binnen Agile-teams, is ATDD een praktijk waarbij bedrijfsanalisten, ontwikkelaars, testers en de gebruikers samenwerken om elke story (of functie) acceptatiecriteria te definiëren in een vroeg stadium van het ontwikkelingsproces (voordat de codering begint). Deze aanpak stelt alle belanghebbenden in staat om hetzelfde niveau van verwachte resultaten te hebben en te behouden voordat een ontwikkelaar begint te coderen.
Ik weet dat we allemaal het stereotype hebben gehoord van “Ontwikkelaars geven niets om specificatie en testers willen niet automatiseren”, maar met ATDD zal dit veel verspilde tijd en geld besparen door ervoor te zorgen dat de ontwikkelaars meer betrokken zijn bij de vroege stadia van specificatie en de tester de acceptatietests automatiseren.
Hoe ATDD wordt geïmplementeerd in het “echte leven”?
Maakt u gebruik van SCRUM? Zo ja, dan doet u al het meeste werk in ATDD. Zo nee, dan moet het volgende voorbeeld uw nieuwsgierigheid voeden :
Example
Laten we aannemen dat de product owner of de klant de volgende feature in onze mobiele applicatie heeft gevraagd: “Als gebruiker wil ik het inlogscherm omzeilen zodat ik anoniem gebruik kan maken van de applicatie” Na het reviewen van dit verzoek met het hele team (Business analist, Developers, Testers…) en met meer details toegevoegd aan de story of de feature, zullen we een aantal “acceptatie” of “functionele” tests hebben die hier op lijken (Let op dit is slechts een voorbeeld, veel acceptatie tests ontbreken voor deze feature):
- Acceptatiecriteria 1: De applicatie accepteert optioneel login/wachtwoord om in te loggen
- Acceptatiecriteria 2: De knop bypass stelt de gebruiker in staat om binnen de applicatie te browsen zonder login.
- Acceptatiecriteria 3: Wanneer de knop bypass is geselecteerd, slaat de toepassing geen gebruikersspecifieke informatie op of toont deze niet.
- Acceptatiecriteria 4: Wanneer de login/wachtwoord worden gebruikt, moet de GUI van de toepassing worden aangepast aan de gebruikersinstellingen.
Voordelen
1- Afstemming klant-verkoper : Door bovenstaande acceptatiecriteria als invoerinformatie te hebben, zijn wij (ieder teamlid) er nu zeker van dat de applicatie haar login/wachtwoord functionaliteit zal behouden en alleen een knop zal toevoegen om de gebruiker in staat te stellen het login scherm te omzeilen.
2- Kwaliteit en kosteneffectiviteit: De bovenstaande tests kunnen eenvoudig worden geautomatiseerd, nog voordat de ontwikkelaars beginnen te coderen.
3- Time to Market: Zodra de tests zijn geïmplementeerd, kunnen de ontwikkelaars hun vereiste taken valideren voordat ze aankondigen dat ze klaar zijn.
ATDD vereist geen specifieke tools. Het is belangrijk om te weten, dat NIET alle acceptatietesten geautomatiseerd moeten worden. Het automatiseren van uw tests hangt af van meerdere aspecten, zoals: technische uitdagingen, deadline en kosten.
Aanbevolen hulpmiddelen?
ATDD vereist geen specifieke hulpmiddelen. Het is belangrijk om te weten dat NIET alle acceptatietests geautomatiseerd moeten worden. Het automatiseren van uw tests is afhankelijk van meerdere aspecten, zoals: technische uitdagingen, deadline en kosten.
In dit gedeelte geef ik u slechts een overzicht van de meest gebruikte automatiseringstools voor ATDD:
FitNess: Het volledig geïntegreerde standalone wiki- en acceptatietestframework
Robot framework: generiek testautomatiseringsframework voor acceptatietesten en acceptatietestgedreven ontwikkeling (ATDD)
Calabash: Geautomatiseerde acceptatietesten voor mobiele apps – Wees ervan bewust dat dit framework mogelijk niet de laatste OS-versie ondersteunt (boven Android O )