Är du redo att lära dig mer om agil testning?
Den agila metodiken använder olika tester för att säkerställa att slutprodukten tillfredsställer kundernas behov fullt ut.
Och om du ingår i ett agilt team ska du testa allt.
Ungefär som Rick Sanchez, vetenskapsgeniet från serien Rick and Morty.

Därför använder vi exempel från Rick and Morty i den här artikeln för att hjälpa dig att förstå agil testning.
Du lär dig grunderna i alla fyra typer av agil testning, de agila testkvadranterna och hur du enkelt hanterar din agila testprocess!
Låt oss sätta igång!
Vad är agilt?
Obs! Detta avsnitt är avsett för läsare som vill lära sig grunderna i agil metodik. Om du redan är bekant med detta, klicka här för att gå direkt till avsnittet om testning.
Agil projektledning hjälper team att skapa bättre, mer kundorienterade produkter i kortare utvecklingscykler, till skillnad från traditionella projektledningsmetoder.
Den agila metoden passar i grunden snabbtänkta genier, som Rick.
Varför?
Det hindrar inte hans framsteg med onödiga processer, men låter honom ändå skapa fantastiska produkter.
Här är ett exempel som hjälper dig att förstå hur den agila metoden fungerar:
Låt oss säga att Rick vill bygga en app som spårar hans sonsons (Mortys) position när de två är ute på äventyr. Detta hjälper inte bara Rick att hitta Morty i parallella dimensioner, utan hjälper också Mortys föräldrar att hålla koll på var deras son befinner sig.
Vi vet ju hur mycket Rick hatar sin svärson Jerry och hans klagomål om deras äventyr.

Om Rick använder traditionella projektledningsmetoder skulle han utveckla produkten från början till slut utan någon input från Jerry. Detta kan ta flera år och kan till och med resultera i en slutprodukt som Jerry hatar eftersom han aldrig blev tillfrågad!
Om Rick använder den agila metoden kommer han dock att bygga appen i flera korta ”sprintar” och testa den efter varje sprint. Efter testningen kommer han att be Jerry om feedback och sedan implementera den i nästa sprint, för att slutligen bygga den slutgiltiga appen precis som Jerry vill ha den!
Eftersom dessa sprintar innebär så mycket testning förlitar sig ett agilt team på en uppsättning sofistikerade och omfattande testmetoder.
Låt oss lära oss allt om dem...
Observera: Även om den agila metodiken kan anpassas till alla typer av projekt, kommer vi i denna artikel att diskutera dess tillämpningar i mjukvaruprojekt.
Vad är ramverket för agil testning?
Testmetoden som baseras på agila värderingar och principer kallas agilt testramverk.
Som ett resultat följer den vissa riktlinjer från den agila utvecklingsmetodiken, såsom:
- Ge kontinuerlig feedback till utvecklare för att förbättra produkten
- Håll mjukvarutestningsprocessen enkel
- Involvera hela teamet så långt det är möjligt
- Minska dokumentationen och öka den direkta kommunikationen
Baserat på dessa riktlinjer använder ett agilt team fyra typer av agila testtekniker:
(Klicka på dem för att hoppa till avsnitten som behandlar respektive testtyp. )
Men varför använder ett agilt team sin egen testmetod?
Det är som att undra varför Rick skapar sina egna saker istället för att bara köpa dem!

För att det är mycket coolare!
Men det är förstås inte den enda anledningen.
Agila team följer en annan metodik för mjukvarutestning eftersom traditionella testmetoder inte kan användas i en agil miljö.
Låt oss se hur agila testtekniker skiljer sig från traditionell testning.
Skillnaden mellan traditionella och agila testtekniker
1. Testfrekvens
I traditionella projektledningsmetoder som vattenfallstestning testas produkten först efter att utvecklingscykeln har avslutats. Men eftersom testomfånget skulle ha ökat exponentiellt i slutet av projektet, väljer teamet antingen att skjuta upp produktlanseringen eller att spara in på mjukvarutestningen.
För att undvika detta rekommenderar den agila testmetodiken kontinuerlig testning följt av kontinuerlig integration av nya funktioner i produkten.
I en agil miljö utvecklar teamet samtidigt funktioner och testar dem för noggrannhet och prestanda, vilket hjälper dem att leverera robusta produkter inom tidsfristen.
2. Testteamets karaktär
Traditionell testning utförs vanligtvis av ett separat kvalitetssäkringsteam eller QA-team vars syfte är att hitta fel i produkten. QA-teamet är dock inte en del av problemlösningsprocessen tillsammans med utvecklarna, vilket kan skapa informationssilos i teamet.
En agil process är dock beroende av tvärfunktionellt samarbete och uppbyggnad av ett kommunikationssystem för ditt testteam.
Alla team arbetar tillsammans mot önskade resultat, och det finns inget behov av ett separat QA-team.
Utvecklarna skapar testet, genomför det och också hittar lösningar. Detta säkerställer att alla i teamet har lika stort ansvar för produkten.
Så vem är en agil testare?
Alla i ett agilt team kan vara testare, och ingen anställs bara för det jobbet.
Men i enlighet med Ricks övertygelse om expertis måste en agil testare vara skicklig på några saker:
- Kommunikationsförmåga
- Samarbete
- Självorganisering
- Responsivitet mot förändring
- Tekniska färdigheter (särskilt för automatiserade tester ) och erfarenhet av explorativa tester
- Dokumentation
De fyra typerna av agil testning
Nu när du känner till grunderna i agil testning ska vi lära oss om de fyra testtyperna och hur de genomförs.
Låt oss dyka rätt in i denna nya dimension!
Typ 1: Beteendestyrd utveckling (BDD)
Minns du hur Rick flydde från Galaktiska federationens högsäkerhetsfängelse?
Han manipulerade systemet för att få sina förhörsledare att tro att hans plan misslyckades.
Och så lyckades han vända hela spelet!

Behavior Driven Development eller BDD följer en något liknande process.
Eftersom produkten är avsedd att misslyckas med testet!
Varför?
Varje gång en produkt misslyckas med ett BDD-test får utvecklarna exakt information om hur den reagerar på ett scenario. Denna kunskap gör det möjligt för dem att bygga funktioner som kan korrigera detta beteende.
Så hur genomförs det?
Tillsammans skapar testare, utvecklare och affärsanalytiker en lista över scenarier eller ”testfall” som de vill testa produkten i.
Dessa är skrivna i Gherkin-syntax: Given/When/Then
Ett exempel på ett testfall för Ricks Morty-spårningsapp kan vara:
Om planen misslyckas, när Morty är vilse i rymden och tiden, då ska appen kunna ange både hans position och tidsram.
Testteamet förfinar ytterligare de steg och processer som produkten kommer att använda för att hantera denna situation.
Eftersom testningen sker samtidigt med agil utveckling är det meningen att produkten ska misslyckas i dessa scenarier!
Parallellt med testningen skapar utvecklarna funktioner som hjälper produkten att klara BDD-testet.
De testar produkten tills den fungerar och förfinar den ytterligare med varje sprint.
Ungefär som när Rick, Morty och hans syster Summer hittade ett sätt att dela upp tiden för att göra flera saker samtidigt!

Men precis som det finns regler för tidsresor (som Rick nästan alltid följer), måste du tänka på vissa saker när du utför BDD-tester.
Några bästa praxis för BDD-testning är:
- Skriv specifika, definierade testfall som är genomförbara
- Använd automatiserade tester för att säkerställa enhetlighet i alla testfall.
- Begränsa dokumentationen, men glöm inte att dokumentera alla viktiga punkter.
Typ 2: Acceptanstestdriven utveckling (ATDD)
ATDD eller acceptanstestning är mycket lik BDD-testning.
Båda följer samma process:
Skriv testkriterier –> Testa produkten –> Misslyckas med testet –> Bygg funktioner för att klara testet –> Testa igen –> Klara testet
Men bara för att de verkar likna varandra betyder det inte att de är det.
Ungefär som när Rick och Morty upptäckte ”små skillnader” mellan de oändliga universumen i oändliga dimensioner.
På samma sätt skiljer sig BDD och acceptanstestning åt på två viktiga punkter:
- Medan ATDD genomförs med aktivt deltagande från kunden, omfattar BDD endast affärsanalytiker (förutom utvecklarna).
- ATDD fokuserar på att förstå produkten genom mänsklig interaktion och inkluderar därför kunden. BDD testar dock endast dess tekniska beteende.
Detta minskar ytterligare trycket på utvecklare att förstå (eller anta) sina kunders behov. De kan helt enkelt inkludera dem och fråga dem under processen!
Ett exempel på ett AcceptanceTest-scenario för Rick’s Morty-tracker kan vara:
Introduktion av Jerry, som inte är bekant med vetenskapen om tidsresor.
Och även om detta kanske inte har något att göra med produktens tekniska funktioner, är det avgörande för kundens upplevelse av att använda den. Så Rick kommer att involvera Jerry för att testa appen och avgöra dess användbarhet.
Här är några bra metoder att följa vid acceptanstestning:
- Få förstahandsfeedback från kunder genom fokusgrupper eller enkäter
- Inkludera icke-teknisk, kundorienterad personal i processen för att interagera med kunderna.
- Skapa en lista med ”acceptanskriterier” och kontrollera den med kundtjänstpersonalen.
- Håll kundernas respons i centrum för den agila utvecklingsprocessen efter testningen.
Följ alla dessa råd och kanske, bara kanske, kan du rädda Jerry från sig själv!
Typ 3: Utforskande testning
Minns du hur det interdimensionella kabelnätverket (som Rick och Morty älskar så mycket) inte verkar ha något manus?

Men det är ju därför vi älskar det så mycket, eller hur?!
Och om du gillar improviserade TV-serier som Rick and Morty kommer du att uppskatta Exploratory Testing, eftersom den inte heller följer ett manus!
Testare som följer denna metod leker kaotiskt med produkten och efterliknar användarbeteende för att hitta brister.
Men det finns en metod i denna galenskap!
Medan de leker med produkten gör utforskande testare följande:
- Följ specifika, förinställda mål
- Använd användarpersonligheter
- Logga deras aktiviteter
- Utforma nya tester samtidigt
Detta gör processen vetenskaplig, rolig och spännande – precis vad du behöver för att få detta dynamiska duo att fastna!

För att göra explorativ testning effektiv kan du följa dessa bästa praxis:
- Skapa en detaljerad dokumentation av produktens funktionalitet för att testa alla funktioner.
- Notera de funktioner som inte testades i varje omgång för att testa dem senare.
- Anpassa dina användarpersonligheter så att de matchar din målgrupps tankesätt
- Dokumentera och kommunicera så många detaljer som möjligt
Typ 4: Sessionsbaserad testning
Sessionsbaserad testning liknar explorativ testning när det gäller att använda kreativ och fri testning.
Explorativ testning passar dock bäst för erfarna testare som är väl förtrogna med produktens alla detaljer. Metoden lägger därför inte någon större vikt vid ansvar och struktur.
Det är där sessionbaserad testning kommer till hjälp.
Den följer samma improviserade testmetod, men tillämpar också en struktur med:
- Testcharter som anger målen för varje testomgång
- Tidsbegränsade sessioner där testarna ska avsluta testningen
- Testrapporter som testare lämnar in för att rapportera aktiviteter i varje session
- Debriefing för att diskutera testaktiviteter mellan testare och chefer efter varje session.
Denna testmetod är perfekt för team som har svårt att anpassa sig till takten i explorativ testning. Men den kan också vara ett steg på vägen för testteamet att övergå till en mer öppen testmetod.
Och för att få ut mesta möjliga av sessionsbaserad testning finns här några bra metoder att följa:
- Gör upp en översikt över testschemat (med en agenda för varje session) i förväg.
- Definiera tydliga mål för varje testomgång
- Genomför oavbrutna testningssessioner
- Diskutera nästa steg under debriefingen efter sessionen.
Vad är agila testkvadranter?
Det är bra att känna till alla olika typer av tester.
Men du måste lära dig hur du tillämpar denna kunskap, annars kommer du att skapa något helt värdelöst som detta.

Så, vilken test ska du använda och när?
Ännu viktigare, när bör du inkludera automatiserad testning i den agila teststrategin?
Agila testkvadranter har svaret på båda dessa frågor, och så här ser det ut:
(Oroa dig inte om det verkar förvirrande, vi kommer att förklara allt för dig!)

Kvadranterna är framtagna enligt följande specifikationer:
- X-axeln: delar upp testerna i affärsorienterade (svarar på kundernas behov) och teknikorienterade (förstår produktens tekniska beteende).
- Y-axeln: delar upp testerna efter om du stöder eller kritiserar produkten.
Detta ger upphov till fyra olika testtyper som kan sammanfattas i följande kvadranter:
Agil testkvadrant 1: Automatiserade tester
Detta är en uppsättning tekniska eller enhetstestmetoder som hjälper teamet att bygga en bättre produkt. Exempel: Enhetstest, komponenttester.
Agil testningskvadrant 2: Automatiserad testning och manuell testning
Dessa är affärsinriktade tester som hjälper teamet att utveckla produkter som ger bättre affärsvärde. Exempel: Funktionstester.
Agil testningskvadrant 3: Manuell testning
Dessa är affärsinriktade tester som syftar till att ge feedback för att förbättra produktens prestanda. Exempel: användartester, utforskande tester.
Agil testningskvadrant 4: Verktyg
Detta är tekniska tester som kontrollerar produktens prestanda inom icke-funktionella områden (som inte är kundinriktade funktioner såsom säkerhet, underhåll, skalbarhet etc.). Exempel: Prestanda- och belastningstester.
Eftersom agil testning följer agila värderingar och principer rekommenderas inga fasta regler för testning. Istället uppmuntras du att fatta rätt beslut utifrån ditt teams krav.
Eller, som Rick uttrycker det:

Till exempel, även om kvadranterna är numrerade behöver du inte följa samma ordning.
Du kan välja en testtyp baserat på de aktuella kraven för din produkt.
Här är några frågor du kan ställa dig själv innan du skapar en testplan:
- Har ditt team kapacitet (både kompetens och resurser) att genomföra en viss test?
- Testar du de prioriterade funktionerna i ditt projekt?
- Hur ska du organisera kontinuerlig testning och agila utvecklingsprocesser samtidigt?
- Behöver du manuell testning eller testautomatisering?
Bonus: Teknikskuldskvadranten
I slutändan är den enda frågan du behöver besvara:
Vad kan du göra för att skapa en kundcentrerad produkt, och hur kan agil testning hjälpa dig att uppnå detta?
Hur hanterar man den agila testprocessen?
Kommer du ihåg varför Galaktiska federationen och miljontals legosoldater från hela universum jagade Rick på grund av hans portalpistol?

Det är den livsförändrande kraften hos ett riktigt bra verktyg!
Och även om dina agila testmål inte omfattar tids- och rymdresor, kan din test- och utvecklingsprocess vara lika utmanande.
Du kan stöta på någon av följande hinder i din testprocess:
- Ständigt föränderliga krav
- Brist på tillräckliga data
- Brist på skickliga testare
- Samordning mellan team och intressenter
Och naturligtvis den största utmaningen för alla agila team: kontinuerlig testning, oavsett vad.
Lyckligtvis finns det ett sätt att lösa alla dessa problem!
Du behöver din "portal gun": en kraftfull agil projektledningsprogramvara.
Lyckligtvis finns det bara en allt-i-ett -programvara för agil projektledning som du behöver: ClickUp!
Vad är ClickUp?

ClickUp är världens ledande projektledningsverktyg som används av världens mest produktiva team, från nystartade företag till teknikjättar, för att enkelt hantera sina agila projekt.
Med ett brett utbud av agila funktioner för mjukvaruutveckling och samarbete har den allt som behövs för att stödja alla agila eller Scrum-team!
Låt oss ta reda på hur denna portal-gun-of-a-software kan hjälpa dig att hantera din agila testprocess:
A. Effektivisera test- och utvecklingsprocessen med uppgifter, deluppgifter och checklistor
Visst, Rick är ett geni, men man kan inte alltid lita på honom när det gäller små, enkla uppgifter.
Titta bara på hans tal som best man på detta kort!

Ditt agila team (även om de är bättre på att ta anteckningar än Rick) kommer också att behöva stöd för att hantera sin test- och utvecklingsprocess.
ClickUps uppgifter, deluppgifter och checklistor hjälper dem att effektivisera testaktiviteten genom att dela upp den i små, genomförbara delar.
Så här gör du:
- Uppgifter och deluppgifter: dela upp din agila testplan i uppgifter och deluppgifter och tilldela dem till valfri teammedlem.
- Checklistor: skapa en lista med punkter som fungerar som en att göra-lista eller till och med ett kvalitetstest som du kan bocka av under en agil testning.

Dessutom kan du förenkla din process ytterligare med följande funktioner:
- Nesting: lägg till så många underpunkter du vill i din checklista
- Dra-och-släpp-funktion: flytta objekt för att omplanera din lista
- Tilldela objekt : tilldela objekt från listan direkt till flera teammedlemmar
- Mallar : skapa återanvändbara mallar för checklistor och lägg till dem i dina projekt
B. Dokumentera varje detalj i Docs
Ibland behöver man bara skriva ner saker, eller hur?

Men tack vare ClickUps Docs-funktion behöver du inga overkliga, parasitiska utomjordingar som hjälper dig att ta anteckningar!
Du kan skapa dokument för att registrera:
- Agil teststrategi
- Testplan
- Testcharter
- Instruktioner för automatiserad testning
Du kan också använda Docs för att skapa en egen intern wiki för din agila testmetodik!
Det bästa?
Du hittar alla dessa dokument bredvid dina projekt så att du aldrig behöver lägga tid på att leta efter dem!
Och det är superkul att skriva i ClickUp Docs tack vare funktioner som:
- Rich text-formatering för dokument med distinkt utseende
- Nästla sidor i dokument för mer detaljerad information
- Anpassningsbara åtkomsträttigheter för att inkludera teammedlemmar i redigeringen
- Möjligheten att låta Google indexera dessa dokument så att de visas i sökresultaten

C. Spåra tid med Native Time Tracking
Tidshantering är svårt, och det är nästan frestande att resa tillbaka i tiden för att avsluta något.
Men du vill inte hamna på fel sida av "tidsresepolisen" här:

Det är därför ClickUp hjälper dig att hantera din tid bättre med hjälp av funktionen Native Time Tracking. Denna funktion är mycket användbar för teammedlemmar som arbetar på distans eller utanför kontoret.
Du kan komma åt trackern inom ClickUp för att snabbt spåra den tid du lägger på uppgifter. Du kan till och med lägga till etiketter, anteckningar och klassificera tid som fakturerbara timmar för mer effektiv tidshantering!

Men om du redan använder en tidsspårare från tredje part, som Time Doctor, Hubstaff eller Toggl, kan du också enkelt integrera den med ClickUp.
På så sätt kan du övervaka tidsanvändningen och planera dina testningar bättre, utan att behöva resa i tiden!
D. Dela anpassade åtkomsträttigheter med intressenter
Kom ihåg att ett agilt team måste samarbeta med alla intressenter för att kunna leverera en bra produkt.
För att hjälpa dig med detta låter ClickUp dig dela anpassade åtkomsträttigheter med dem. Du kan dela dina projektfiler, mappar och uppgiftslistor med vem som helst inom och utanför ditt nätverk.

Men du kan fortfarande kontrollera vad de kan göra när de väl är inne i ditt arbetsområde genom att ställa in deras " behörigheter ".
Här är några exempel på behörigheter som du kan ställa in:
- Kan visa: visa projektdetaljer men inte interagera
- Kan kommentera: kommentera uppgifterna och uppgiftslistorna
- Kan redigera: redigera uppgifter men inte skapa dem
- Skapa och redigera: skapa och redigera uppgifter och deluppgifter
- Kan radera: radera uppgifter som de inte har skapat
Detta hjälper dig att inkludera kunderna i din ATDD-testprocess.
Men vänta, det finns mer!
Precis som antalet Mr. Meeseeks som samlats för att tjäna Jerry är listan över ClickUps funktioner oändlig!

Men till skillnad från dem kommer dessa funktioner faktiskt att lyckas uppfylla dina behov av agil testning!
Några av de fantastiska agila funktionerna som ClickUp erbjuder ditt team är:
- Dashboards: skapa en anpassad dashboard med widgets som cirkeldiagram och beräkningar, och spåra dina agila och Scrum-poäng.
- Anteckningsblock: öppna ett anteckningsblock från din instrumentpanel för att snabbt skriva ner idéer.
- Mål: sätt upp testmål, omvandla dem till mätbara mål och följ upp dem.
- Prioriteringar: utför tester baserat på brådskande behov och viktighet
- Anpassade statusar: skapa testspecifika statusar för dina uppgifter
- Gantt-diagram: visualisera hela projektets tidslinje
- Projektautomatisering: automatisera över 50 repetitiva uppgifter under testerna och spara tid
- Kraftfulla mobila appar för iOS och Android: samarbeta med ditt team när du är på språng
Slutsats
Att förstå den agila testmetodiken kan vara givande för ditt team.
Din agila teststrategi är trots allt själva hjärtat i den agila metoden.
Ju mer fokuserade och exakta dina tester är, desto bättre blir dina produkter.
Men bra testning kräver mer än bara kunskap och färdigheter.
Du behöver också extremt precisa verktyg som hjälper dig att genomföra kontinuerliga tester.
Lyckligtvis behöver du inte Ricks laboratorium för att skapa en.
Allt du behöver är ClickUp!
Den har rätt uppsättning funktioner för att stödja alla agila teststrategier, tillsammans med robust projektledningsstöd för en agil miljö.
Registrera dig för ClickUp idag och fira dina agila projektledningsäventyr, precis som Rick och hans barnbarn!


