klaar om meer te leren over _Agile testen _?
De Agile-methodologie gebruikt verschillende tests om ervoor te zorgen dat het eindproduct perfect voldoet aan de behoeften van de klant.
En als je in een Agile team moet je alles testen.
net als Rick Sanchez, de wetenschapstovenaar uit het programma Rick and Morty
Daarom gebruiken we voorbeelden uit Rick and Morty in dit artikel om je te helpen Agile testen te begrijpen.
Je leert de basis van alle 4 soorten Agile testen, de Agile testkwadranten en hoe je gemakkelijk je Agile testproces kunt beheren!
Laten we beginnen!
Wat is Agile?
Noot: Dit gedeelte is voor lezers die meer willen weten over de basisprincipes van de Agile methodologie . Als je daarmee bekend bent, klik hier om naar de sectie over _testen te gaan._ Agile projectbeheer helpt teams betere, klantgerichtere producten te bouwen in kortere ontwikkelingscycli, in tegenstelling tot traditionele projectmanagementmethoden .
De Agile-methode is in principe geschikt voor sneldenkende genieën, zoals Rick.
waarom?
Het houdt zijn vooruitgang niet tegen met onnodige processen, maar laat hem toch geweldige producten bouwen.
Hier is een voorbeeld om je te helpen begrijpen hoe de Agile-methode werkt:
Laten we zeggen dat Rick een app wil bouwen die de locatie van zijn kleinzoon (Morty) volgt wanneer de twee op avontuur zijn. Dit zal Rick niet alleen helpen om Morty te vinden in parallelle dimensies, maar het zal ook Morty's ouders helpen om bij te houden waar hun zoon is.
we weten tenslotte hoe Rick het haat dat zijn schoonzoon Jerry klaagt over hun avonturen
Als Rick traditionele projectmanagementmethoden gebruikt, ontwikkelt hij het product van begin tot eind zonder enige inbreng van Jerry. Dit kan jaren duren en kan zelfs resulteren in een eindproduct dat Jerry haat omdat hij nooit geraadpleegd is!
Als Rick echter de Agile-methode gebruikt, bouwt hij de app in een aantal korte ' sprints en test het na elke sprint. Na het testen vraagt hij Jerry om feedback en implementeert deze in de volgende sprint, om uiteindelijk de uiteindelijke app te bouwen precies zoals Jerry het wil!
Omdat er zoveel getest moet worden in deze sprints, vertrouwt een Agile team op een set geavanceerde en uitgebreide testmethoden.
Laten we er alles over leren...
Noot: Hoewel de Agile methodologie kan worden aangepast voor elk soort project, bespreken we in dit artikel de toepassingen ervan in software projecten.
Wat is het Agile testraamwerk?
De testmethode gebaseerd op de Agile waarden en principes staat bekend als het Agile testraamwerk.
Als gevolg hiervan volgt het een aantal richtlijnen uit de Agile ontwikkelingsmethodologie, zoals:
- Het bieden vancontinue feedback aan ontwikkelaars om het product
- Het testen van software eenvoudig houden
- Zoveel mogelijk het hele team erbij betrekken
- Minder documentatie en meer directe communicatie
Op basis van deze richtlijnen gebruikt een Agile team 4 soorten Agile testtechnieken:
(Klik erop om naar de secties te gaan die elk van de testtypes behandelen.)
- Gedragsgestuurde ontwikkeling
- Acceptatietest Gedreven Ontwikkeling
- Verkennend testen
- Sessie-gebaseerd testen
Maar waarom gebruikt een Agile team zijn eigen testmethode _?
Dat is net zoiets als je afvragen waarom Rick zijn eigen spullen maakt in plaats van ze gewoon te kopen!
omdat het veel cooler is!
Maar dat is natuurlijk niet de enige reden.
Agile teams volgen een andere testmethodologie voor software omdat traditionele testmethodes niet gebruikt kunnen worden in een Agile team Agile omgeving .
laten we eens kijken hoe _Agile testtechnieken verschillen van _traditioneel testen .
Het verschil tussen traditionele en Agile testtechnieken
1. Frequentie van testen
In traditionele projectmanagementmethoden zoals Waterval testen, wordt het product pas getest nadat de ontwikkelingscyclus is afgelopen. Maar omdat de omvang van het testen exponentieel zou zijn toegenomen tegen het einde van je project, stelt het team ofwel de productrelease uit of _bezuinigt het softwaretesten.
Om dit te voorkomen, beveelt de Agile testmethodologie continu testen aan, gevolgd door continue integratie van nieuwe functies in het product.
In een Agile omgeving bouwt het team tegelijkertijd functies en test ze op nauwkeurigheid en prestaties, waardoor ze robuuste producten binnen de deadline kunnen afleveren.
2. Aard van het testteam
Traditioneel testen wordt meestal uitgevoerd door een apart Quality Assurance of QA team wiens doel het is om fouten in het product te vinden. Het QA team is echter geen onderdeel van het probleemoplossingsproces met de ontwikkelaars, wat kan leiden tot informatiesilo's in het team creëren .
Een Agile proces is echter afhankelijk van cross-functionele samenwerking en het bouwen van een communicatiesysteem voor je testteam.
Alle teams werken samen aan de gewenste resultaten en er is geen apart QA-team nodig.
De ontwikkelaars maken de test, voeren hem uit en vinden ook oplossingen. Dit zorgt ervoor dat iedereen in het team evenveel eigenaar is van het product.
Wie is een Agile tester?
Iedereen in een Agile team kan een tester zijn en niemand wordt alleen voor die ene functie aangenomen.
Maar volgens Rick's overtuigingen over expertise, moet een Agile tester bedreven zijn in een paar dingen:
- Communicatieve vaardigheden
- Samenwerking
- Zelforganisatie
- Reactievermogen op verandering
- Technische vaardigheden (vooral voorgeautomatiseerde tests) en ervaring inverkennende tests* Documentatie
De 4 typen van agile testen
Nu je de basis van Agile testen kent, leren we over de 4 soorten testen en hoe ze worden uitgevoerd.
laten we meteen in deze nieuwe dimensie duiken!
Type #1: Gedragsgedreven ontwikkeling (BDD)
weet je nog hoe Rick ontsnapte uit een maximaal beveiligde gevangenis van de Galactische Federatie?
Hij knoeide met het systeem om zijn ondervragers te laten geloven dat zijn plan mislukte.
En zo wist hij het hele spel om te draaien!
Behavior Driven Development of BDD volgt een enigszins vergelijkbaar proces.
omdat het de bedoeling is dat het product niet slaagt voor de _test !
waarom?
Elke keer dat een product faalt in een BDD-test, vertelt het de ontwikkelaars precies hoe het reageert op een scenario. Met deze kennis kunnen ze functies bouwen die dit gedrag kunnen corrigeren.
hoe wordt het uitgevoerd?
De testers, ontwikkelaars en business analisten maken samen een lijst met scenario's of 'testgevallen' waarin ze het product willen testen.
Deze worden geschreven in de Gherkin syntaxis: Gegeven/Wanneer/Dan
Een voorbeeldtestcase voor Rick's Morty-tracking app zou kunnen zijn:
Given the plan fails, when Morty is lost in space and time, then the app should be able to point out both his location and timeframe.
Het testteam verfijnt verder de stappen en processen die het product zal gebruiken om op deze situatie te reageren.
En omdat het testen gelijktijdig met Agile ontwikkeling gebeurt, is het de bedoeling dat het product in deze scenario's faalt!
Naast de test maken de ontwikkelaars functies die het product helpen om de BDD-test te doorstaan.
Ze testen het product totdat het slaagt en verfijnen het verder bij elke sprint.
een beetje zoals Rick, Morty en zijn zus Summer een manier vonden om tijd te verdelen om dingen tegelijkertijd te doen!
Echter, net zoals er regels zijn voor tijdreizen (die Rick bijna altijd volgt), moet je op sommige dingen letten bij het uitvoeren van BDD-tests.
Enkele best practices voor BDD-testen zijn:
- Schrijf specifieke, gedefinieerde testgevallen die uitvoerbaar zijn
- Gebruik geautomatiseerde tests om uniformiteit in alle testgevallen te garanderen
- Beperk documentatie, maar vergeet niet alle hoogtepunten vast te leggen
Type #2: Acceptatietestgedreven ontwikkeling (ATDD)
ATDD of Acceptatietesten lijkt erg op BDD-testen .
Ze volgen allebei hetzelfde proces van:
Schrijf testcriteria -> Test product -> Faal test -> Bouw functies om de test te doorstaan -> Test opnieuw -> Doorsta de test
Maar omdat ze gelijkaardig lijken, wil nog niet zeggen dat ze dat ook zijn.
zoals Rick and Morty opmerkte "kleine verschillen" _tussen de oneindige universums in oneindige dimensies.
Op dezelfde manier verschillen BDD en Acceptatietesten op twee belangrijke punten:
- Terwijl ATDD wordt uitgevoerd met actieve deelname van de klant, zijn bij BDD alleen de bedrijfsanalisten betrokken (naast de ontwikkelaars)
- ATDD richt zich op het begrijpen van het product door middel van menselijke interactie, en omvat dus ook de klant. BDD test echter alleen het technische gedrag.
Dit neemt verder de druk weg van ontwikkelaars om de behoeften van hun klant te begrijpen (of aan te nemen). Ze kunnen ze gewoon meenemen en vragen tijdens het proces!
Een voorbeeld AcceptanceTest scenario voor Rick's Morty tracker zou kunnen zijn:
Onboarding Jerry die niet bekend is met de wetenschap van tijdreizen.
En hoewel dit misschien niets te maken heeft met de technische functies van het product, is het cruciaal voor de gebruikservaring van de klant. Dus Rick zal Jerry betrekken bij het testen van de app en de bruikbaarheid te bepalen .
Hier zijn enkele goede praktijken om te volgen bij acceptatietesten:
- Ontvang feedback uit eerste hand van klanten met behulp vanfocusgroepen of enquêtes* Betrek niet-technisch, klantgericht personeel bij het proces voor interactie met klanten
- Maak een lijst met 'acceptatiecriteria' en controleer deze met de klantgerichte medewerkers
- Houd de reactie van de klant centraal in het Agile ontwikkelingsproces na de test
volg al deze punten en misschien, heel misschien, kun je Jerry van zichzelf redden!
Type #3: Verkennend testen
Weet je nog hoe het interdimensionale kabelnetwerk (waar Rick en Morty zo gek op zijn) geen script lijkt te hebben?
Maar hey, dat is waarom we er zo van houden, toch?!
En als je een fan bent van geïmproviseerde tv zoals Rick and Morty, dan zal Exploratory Testing je bevallen omdat het ook geen script volgt!
Testers die deze methode volgen, spelen chaotisch met het product, spelen gebruikersgedrag na om fouten te vinden.
er is echter een methode voor deze waanzin!
Terwijl ze met het product spelen, spelen verkennende testers:
- Specifieke, vooraf gestelde doelen volgen
- Gebruikerspersona's aannemen
- Log hun activiteiten
- Ontwerp tegelijkertijd nieuwe tests
Dit maakt het proces wetenschappelijk, leuk en avontuurlijk... precies wat je nodig hebt om dit dynamische duo aan de haak te slaan!
Om Verkennend Testen effectief te maken, zijn hier een paar best practices die je kunt volgen:
- Maak een gedetailleerd overzicht van de functionaliteiten van het product om ze allemaal te testen
- Noteer de functies die niet in elke ronde zijn getest om ze later te testen
- Pas uw gebruikerspersona's aan aan de denkwijze van uw doelgroep
- Documenteer en communiceer zoveel mogelijk details
Type #4: Testen op basis van sessies
Sessiegebaseerd testen is vergelijkbaar met Verkennende testen als het gaat om het toepassen van creatieve en free-flow testen.
Exploratory Testing is echter het beste voor ervaren testers die bekend zijn met de ins en outs van het product. De methode legt dan ook geen nadruk op verantwoordelijkheid en structuur.
Dat is waar Session-Based Testing helpt.
Het volgt dezelfde improviserende manier van testen, maar past ook een structuur toe:
- Test charters die de doelen van elke testsessie vastleggen
- Tijdboxed sessies waarin testers geacht worden het testen af te ronden
- Testrapporten die testers indienen om verslag te doen van de activiteiten in elke sessie
- Debriefs om de testactiviteiten te bespreken tussen de testers en managers na elke sessie
Deze testmethode is perfect voor teams die moeite hebben om zich aan te passen aan het tempo van Verkennend Testen. Maar het kan ook een stapsteen zijn voor het testteam, om een meer open testaanpak te volgen.
En om het meeste uit Session-Based Testing te halen, zijn hier een aantal goede praktijken om te volgen:
- Schets van tevoren het testschema (met een agenda voor elke sessie)
- Definieer kristalheldere doelen voor elke testsessie
- Voer ononderbroken testsessies uit
- Bespreek de volgende stappen tijdens de debriefing na de sessie
Wat zijn Agile Testkwadranten?
alles weten over de verschillende soorten testen is geweldig
Maar je moet leren hoe je deze kennis toepast, anders maak je uiteindelijk iets volstrekt nutteloos als dit.
dus, **_welke test moet je gebruiken en wanneer**_?
Meer belangrijk, wanneer moet je geautomatiseerd testen_ in de _Agile teststrategie _ opnemen?
Agile testkwadranten hebben het antwoord op beide vragen en hier is hoe het eruit ziet:
(Maak je geen zorgen als het er verwarrend uitziet, we gaan je alles uitleggen!)
De kwadranten zijn afgeleid volgens deze specificaties:
- 'X' as: verdeelt de tests in business-facing (inspelen op de behoeften van de klant) en technology-facing (begrijpen van het technische gedrag van het product)
- 'Y'-as: verdeelt de tests in ondersteuning of kritiek op het product
Dit geeft aanleiding tot 4 verschillende testtypes die kunnen worden samengevat in de volgende kwadranten:
Agile testen kwadrant 1: Geautomatiseerde testen
Dit zijn een aantal technologische of unit testmethodes die het team helpen om een beter product te bouwen. Voorbeelden: Unit test, Component tests.
Agile testkwadrant 2: Geautomatiseerd testen en handmatig testen
Dit zijn bedrijfsgerichte tests die het team ondersteunen bij het bouwen van producten die een betere bedrijfswaarde opleveren. Voorbeeld: Functionele testen.
Agile testkwadrant 3: Handmatig testen
Dit zijn bedrijfsgerichte tests die bedoeld zijn om feedback te geven om de prestaties van het product te verbeteren. Voorbeelden: Gebruikersacceptatietests, verkennende tests.
Agile testkwadrant 4: Hulpmiddelen
Dit zijn technische tests die de prestaties van het product controleren op niet-functionele gebieden (die niet klantgericht zijn, zoals beveiliging, onderhoud, schaalbaarheid, enz: Performance en Load Tests.
Omdat Agile testen de Agile waarden en principes volgt, worden er geen harde en snelle regels voor testen aanbevolen. In plaats daarvan moedigt het je aan om de juiste keuze te maken op basis van de eisen van je team.
Of, zoals Rick het zegt:
Hoewel de kwadranten bijvoorbeeld genummerd zijn, hoef je niet dezelfde volgorde te volgen.
Je kunt een type test kiezen op basis van de huidige vereisten van uw product .
Hier zijn een paar vragen die je jezelf kunt stellen voordat je een testplan maakt:
- _Heeft je team de capaciteit (zowel vaardigheden als middelen) om een bepaalde test uit te voeren?
- Test je de prioriteitsfuncties in je project?
- Hoe ga je continu testen en de Agile ontwikkelingsprocessen tegelijkertijd organiseren?
- Heb je handmatig testen of testautomatisering nodig?
Bonus: Tech Schuldenkwadrant Uiteindelijk is de enige vraag die u moet beantwoorden:
Wat kun je doen om een klantgericht product te maken, en hoe kan Agile testen je daarbij helpen?
Hoe beheer je het Agile testproces?
weet je nog waarom de Galactische Federatie **_en _miljoenen huurlingen uit het hele universum achter Rick aanzaten vanwege zijn portaalkanon?
Dat is de levensveranderende kracht van een echt goed gereedschap!
En hoewel je Agile testdoelen geen betrekking hebben op tijd- en ruimtereizen, kunnen je test- en ontwikkelingsproces net zo uitdagend zijn.
Je kunt in je testproces op een van de volgende hindernissen stuiten:
- Voortdurend veranderende eisen
- Gebrek aan voldoende gegevens
- Gebrek aan bekwame testers
- Coördinatie tussen teams en belanghebbenden
En natuurlijk de grootste uitdaging voor elk Agile team: continu testen, wat er ook gebeurt.
Gelukkig is er een manier om al deze problemen op te lossen!
Je hebt je 'portaalkanon' nodig: een krachtige Agile project management software.
Gelukkig is er maar één all-in-one Software voor agile projectbeheer die je nodig hebt: Klik omhoog!
**Wat is ClickUp?
ClickUp
is 's werelds
toonaangevende projectmanagementtool
dat wordt gebruikt door s werelds meest productieve teams van startups tot techgiganten om hun Agile projecten eenvoudig te beheren.
Met een grote verscheidenheid aan Agile softwareontwikkeling en samenwerkingsfuncties, het heeft alles om elke Agile of Scrum-team !
Laten we eens kijken hoe deze portal-gun-of-a-software kan helpen bij het beheren van je Agile testproces:
A. Stroomlijn het test- en ontwikkelingsproces met Taken,
Subtaken en Controlelijsten natuurlijk, Rick is een genie, maar je kunt hem niet altijd vertrouwen met kleine, eenvoudige taken._
Kijk maar naar deze cue card voor zijn toespraak als getuige!
Je Agile team (zelfs als ze betere notulisten zijn dan Rick) zal ook ondersteuning nodig hebben om hun test- en ontwikkelingsproces te beheren.
ClickUp's taken, subtaken en checklists zullen hen helpen om hun testactiviteiten te stroomlijnen door ze op te splitsen in kleine, uitvoerbare items.
Dit is hoe u dit kunt doen:
- Taken en subtaken: splits je Agile testplan op in taken en subtaken en wijs ze toe aan een willekeurig teamlid
- Checklists: ontwikkel een lijst met items die fungeert als een to-do lijst of zelfs een kwaliteitstest om af te vinken tijdens een Agile test
Bovendien kun je je proces verder vereenvoudigen met de volgende functies:
- Nesting: voeg zoveel subitems toe als je wilt in je checklist
- Slepen en neerzetten: items verplaatsen om je lijst te herschikken
- Items toewijzen: wijs items uit de lijst direct toe aan meerdere teamleden
- Sjablonen: maak herbruikbare sjablonen voor checklists en voeg ze toe aan uw projecten
B. Leg elk detail vast in Documentensoms moet je gewoon dingen opschrijven, toch?
Maar dankzij de Docs functie van ClickUp hebt u geen onwerkelijke, parasitaire aliens nodig om u te helpen notities te maken!
U kunt Docs maken om op te nemen:
- Agile teststrategie
- Testplan
- Test handvest
- Instructies voor geautomatiseerd testen
Je kunt Docs ook gebruiken om je eigen in-house wiki te maken voor je Agile testmethodologie!
het beste deel?
Je kunt al deze documenten direct bij je projecten vinden, zodat je er nooit naar hoeft te zoeken!
En schrijven in ClickUp Docs is super leuk dankzij functies zoals:
- Rijke tekstopmaak voor opvallend ogende documenten
- Pagina's in documenten nestelen voor meer details
- Aanpasbare toegangsrechten om teamleden bij het bewerken te betrekken
- De mogelijkheid om deze documenten door Google te laten indexeren zodat ze in zoekresultaten verschijnen
C. De tijd bijhouden met Inheemse tijdregistratieTijdbeheer is moeilijk en het is bijna verleidelijk om terug in de tijd te reizen om iets af te maken.
maar je wilt hier niet aan de verkeerde kant van de 'tijdreispolitie' komen te staan:_
Daarom helpt ClickUp u uw tijd beter te beheren met de functie Native Time Tracking. Deze functie is super handig voor teamleden die op afstand werken of offsite .
U kunt de tracker binnen ClickUp gebruiken om snel de tijd bij te houden die u aan taken besteedt. U kunt zelfs labels en notities toevoegen en tijd classificeren als factureerbare uren voor efficiënter tijdbeheer!
Maar als je al een tijdregistratiesysteem van derden gebruikt zoals Tijddokter,Hubstaff of Toggl kunt u integreren met ClickUp ook gemakkelijk.
Op deze manier kunt u het tijdsgebruik in de gaten houden en uw testsessie beter plannen, allemaal zonder tijd te verplaatsen!
D. Delen Aangepaste toegangsrechten met belanghebbenden
Onthoud dat een Agile team moet samenwerken met alle belanghebbenden om een goed product af te leveren.
Om u hierbij te helpen, kunt u met ClickUp aangepaste toegangsrechten met hen delen. U kunt uw projectbestanden, mappen en takenlijsten delen met iedereen binnen en buiten uw netwerk.
Maar je kunt nog steeds controle uitoefenen over wat ze kunnen doen als ze eenmaal in je werkruimte zijn door hun ' Toestemmingen '.
Hier zijn een paar voorbeeldpermissies die je kunt instellen:
- Kan bekijken: projectdetails bekijken maar geen interactie
- Kan commentaar geven: commentaar geven op de taken en takenlijsten
- Kan bewerken: taken bewerken maar niet aanmaken
- Kan taken en subtaken maken en bewerken: taken en subtaken maken en bewerken
- Kan verwijderen: taken verwijderen die hij niet heeft gemaakt
Dit zal u helpen om klanten op te nemen in uw ATDD-testproces.
Maar wacht, er is meer!
net zoals het aantal Mr. Meeseeks dat Jerry bedient, is de lijst met ClickUp-functies eindeloos!
Maar in tegenstelling tot deze functies, zullen deze echt voldoen aan je Agile testbehoeften!
Sommige van de verbazingwekkende Agile functies ClickUp biedt uw team onder andere:
- Dashboards : maak een aangepast dashboard met widgets zoalsTaartdiagrammen en berekeningenen volg uw Agile en Scrum punten
- Kladblok: open een notitieblok vanaf uw dashboard om snel ideeën op te schrijven
- Doelen : stel testdoelen op, zet ze om in meetbare doelen en houd ze bij
- Prioriteiten : voer tests uit op basis van urgentie en belang
- Aangepaste statussen : maak testspecifieke statussen voor uw taken
- Gantt Grafieken : uw volledige projecttijdlijn visualiseren
- Project Automatisering : automatiseer 50+ repetitieve taken tijdens tests en bespaar tijd
- Krachtige mobiele apps voor iOS en Android : onderweg samenwerken met uw team
Conclusie
Het begrijpen van de Agile testmethodologie kan lonend zijn voor je team.
Tenslotte is je Agile teststrategie het hart van de Agile methode.
Hoe gerichter en nauwkeuriger je tests zijn, hoe beter je producten zullen zijn.
Maar goed testen vereist meer dan alleen kennis en vaardigheden.
Je hebt ook het volgende nodig vlijmscherp gereedschap om je te helpen continue testen uit te voeren.
gelukkig heb je Rick's lab niet nodig om er een te maken
**Alles wat u nodig hebt is ClickUp!
Het heeft de juiste functies om elke Agile teststrategie te ondersteunen, samen met robuuste projectmanagementondersteuning voor een Agile omgeving. Meld u vandaag nog aan voor ClickUp en vier uw Agile projectmanagementavonturen, net als Rick en zijn kleinkinderen!
