Hvad er Agile Testing?
AGILE TESTING er en testpraksis, der følger reglerne og principperne for agil softwareudvikling. I modsætning til Waterfall-metoden kan Agile Testing begynde i starten af projektet med kontinuerlig integration mellem udvikling og test. Agil testmetodologi er ikke sekventiel (i den forstand, at den kun udføres efter kodningsfasen), men kontinuerlig.
I denne artikel vil vi diskutere
- Agil testplan.
- Agile teststrategier.
- Den agile testkvadrant.
- QA-udfordringer med agil softwareudvikling.
- Risiko for automatisering i agil proces.
Agil testplan
Agil testplan inkluderer typer af test udført i den iteration som testdatakrav, infrastruktur, testmiljøer og testresultater. I modsætning til vandfaldsmodellen i en adræt model skrives og opdateres en testplan for hver udgivelse. Typiske testplaner i agile inkluderer
- Testomfang
- Nye funktionaliteter, der testes
- Niveau eller typer af test baseret på funktionernes kompleksitet
- Test af belastning og ydeevne
- Infrastrukturovervejelse
- Afbødning eller risikoplan
- Resourcing
- Leverancer og milepæle
Agile teststrategier
Agil test livscyklus spænder over fire faser
(a) Iteration 0
I den første fase eller iteration 0 udfører du indledende installationsopgaver. Det inkluderer identifikation af personer til test, installation af testværktøjer, planlægning af ressourcer (brugervenlighedstestlaboratorium) osv. Følgende trin er indstillet til at opnå i Iteration 0
a) Etablering af en business case for projektet
b) Fastlæg randbetingelser og projektomfang
c) Skitsere nøglekravene og brugssager, der vil drive designvurderingerne
d) Skitsere en eller flere kandidatarkitekturer
e) Identificering af risikoen
f) Omkostningsestimering og forbered et forprojekt
(b) Konstruktionspejl
Den anden fase af agil testmetode er konstruktion iterationer, størstedelen af testen finder sted i denne fase. Denne fase observeres som et sæt iterationer for at opbygge en forøgelse af løsningen. For at gøre det inden for hver iteration implementerer teamet en hybrid af praksis fra XP, Scrum, Agile modellering og agile data og så videre.
I konstruktion iteration følger det agile team den prioriterede kravpraksis: Med hver iteration tager de de mest væsentlige krav tilbage fra arbejdsemnet og implementerer dem.
Konstruktion iteration er klassificeret i to, bekræftende test og undersøgelse test. Bekræftende test koncentrerer sig om at kontrollere, at systemet opfylder interessenternes hensigt som beskrevet til holdet til dato og udføres af teamet. Mens undersøgelsestesten opdager det problem, som bekræftende team har sprunget over eller ignoreret. I undersøgelsestest bestemmer testeren de potentielle problemer i form af mangelfortællinger. Undersøgelsestest beskæftiger sig med almindelige problemer som integrationstest, belastning / stresstest og sikkerhedstest.
Igen for bekræftende test er der to aspekter udvikler test og agil accept test . Begge er automatiseret for at muliggøre kontinuerlig regressionstest gennem hele livscyklussen. Bekræftende test er den agile ækvivalent af test til specifikationen.
Agil accept test er en kombination af traditionel funktionel test og traditionel accept test som udviklingsteamet, og interessenter gør det sammen. Mens test af udviklere er en blanding af traditionel enhedstest og traditionel serviceintegrationstest. Udviklertest verificerer både applikationskoden og databaseskemaet.
(c) Slip slut spil eller overgangsfase
Målet med "Release, End Game" er at implementere dit system med succes i produktion. Aktiviteterne inkluderer i denne fase uddannelse af slutbrugere, supportpersoner og operationelle personer. Det inkluderer også markedsføring af produktudgivelsen, sikkerhedskopiering og gendannelse, færdiggørelse af system- og brugerdokumentation.
Den sidste testprøve på agil metode inkluderer fuld systemtest og accepttest. I overensstemmelse med at afslutte din sidste testfase uden forhindringer, skal du teste produktet strengere, mens det er i konstruktions-iterationer. I slutspillet arbejder testere på dens defekte historier.
(d) Produktion
Efter frigivelsesfasen flytter produktet til produktionstrinnet.
The Agile Testing Quadrants
De agile testkvadranter adskiller hele processen i fire kvadranter og hjælper med at forstå, hvordan agil test udføres.
a) Agile Quadrant I - Den interne kodekvalitet er hovedfokus i denne kvadrant, og den består af testcases, som er teknologidrevet og implementeres for at støtte teamet, det inkluderer
1. Enhedstest
2.Komponenttest
b) Agile Quadrant II - Den indeholder testcases, der er forretningsdrevne og implementeres for at støtte teamet. Denne kvadrant fokuserer på kravene. Den type test, der udføres i denne fase er
1. Test af eksempler på mulige scenarier og arbejdsgange
2. Test af brugeroplevelse såsom prototyper
3. Par test
c) Agile kvadrant III - Denne kvadrant giver feedback til kvadranter en og to. Testcases kan bruges som basis til at udføre automatiseringstest. I denne kvadrant gennemføres mange runder af iterationsanmeldelser, som skaber tillid til produktet. Den slags test, der udføres i denne kvadrant, er
1. Test af brugervenlighed
2. Undersøgelsestest
3. Par test med kunder
4. Samarbejdstest
5. Test af brugeraccept
d) Agile Quadrant IV - Denne kvadrant koncentrerer sig om de ikke-funktionelle krav såsom ydeevne, sikkerhed, stabilitet osv. Ved hjælp af denne kvadrant anvendes applikationen til at levere de ikke-funktionelle kvaliteter og forventet værdi.
1. Ikke-funktionelle tests såsom stress og performance test
2. Sikkerhedstest med hensyn til godkendelse og hacking
3. Infrastrukturafprøvning
4. Test af datamigrering
5. Test af skalerbarhed
6. Belastningstest
QA-udfordringer med agil softwareudvikling
a) Fejlchancerne er mere agile, da dokumentation prioriteres mindre og til sidst lægger mere pres på QA-teamet
b) Nye funktioner introduceres hurtigt, hvilket reducerer den tilgængelige tid for testteam til at identificere, om de nyeste funktioner er i overensstemmelse med kravet, og adresserer det virkelig forretningens dragter
c) Det kræves ofte, at testere spiller en semi-udvikler
d) Testudførelsescyklusser er meget komprimerede
e) Meget kortere tid til at udarbejde testplan
f) Til regressionstest har de minimal timing
g) Ændring i deres rolle fra at være en portholder af kvalitet til at være en partner i kvalitet
h) Kravsændringer og opdateringer er iboende i en smidig metode, der bliver den største udfordring for QA
Risiko for automatisering i agil proces
- Automatiseret brugergrænseflade giver et højt niveau af tillid, men de er langsomme til at udføre, skrøbelige at vedligeholde og dyre at bygge. Automatisering forbedrer muligvis ikke testproduktiviteten væsentligt, medmindre testerne ved, hvordan de skal teste
- Upålidelige tests er et stort problem i automatiseret test. Fastsættelse af fejlagtige tests og løsning af problemer i forbindelse med skøre tests bør være en topprioritet for at undgå falske positive
- Hvis den automatiserede test initieres manuelt snarere end gennem CI (kontinuerlig integration), er der en risiko for, at de ikke kører regelmæssigt og derfor kan medføre mislykkede tests
- Automatiske tests er ikke en erstatning for en sonderende manuel test. For at opnå den forventede kvalitet af produktet kræves en blanding af testtyper og niveauer
- Mange kommercielt tilgængelige automatiseringsværktøjer giver enkle funktioner som automatisering af optagelse og gentagelse af manuelle testsager. Et sådant værktøj tilskynder til testning gennem brugergrænsefladen og fører til en iboende sprød og vanskelig at vedligeholde tests. Opbevaring af testcases uden for versionskontrolsystemet skaber også unødvendig kompleksitet
- For at spare tid er automatiseringstestplanen dårligt planlagt eller ikke planlagt mange gange, hvilket resulterer i, at testen mislykkes
- En testopsætning og nedrivningsprocedurer går normalt glip af under testautomatisering, mens udførelse af manuel test, en testopsætning og nedrivningsprocedurer lyder problemfrit
- Produktivitetsmålinger såsom et antal testsager, der oprettes eller udføres pr. Dag, kan være frygtelig vildledende og kunne føre til en stor investering i at køre ubrugelige tests
- Medlemmer af det agile automatiseringsteam skal være effektive konsulenter: tilgængelig, samarbejdsvillig og opfindsomme, ellers vil dette system hurtigt mislykkes
- Automatisering kan foreslå og levere testløsninger, der kræver for meget løbende vedligeholdelse i forhold til den leverede værdi
- Automatiseret test mangler muligvis ekspertisen til at blive gravid og levere effektive løsninger
- Automatiseret test kan være så vellykket, at de løber tør for vigtige problemer at løse, og dermed vender sig til uvigtige problemer.
Konklusion
Agil metode i softwaretest involverer test så tidligt som muligt i softwareudviklings livscyklus. Det kræver høj kundeinddragelse og testkode, så snart den bliver tilgængelig. Koden skal være stabil nok til at tage den til systemtest. Omfattende regressionstest kan udføres for at sikre, at fejlene er rettet og testet. Hovedsagelig kommunikation mellem holdene gør agil model test succes !!!