Hva er smidig testing? Prosess og livssyklus
Hva er smidig testing?
Smidig testing er en testpraksis som følger reglene og prinsippene for smidig programvareutvikling. I motsetning til Waterfall-metoden, kan Agile Testing starte ved oppstart av prosjektet med kontinuerlig integrasjon mellom utvikling og testing. Agile testmetodikk er ikke sekvensiell (i den forstand at den utføres bare etter kodefasen), men kontinuerlig.
Prinsipper for smidig testing
Her er de grunnleggende prinsippene for smidig testing:
- I denne smidige testmodellen er fungerende programvare det primære målet på fremgang.
- Det beste resultatet kan oppnås av de selvorganiserende lagene.
- Å levere verdifull programvare tidlig og kontinuerlig er vår høyeste prioritet.
- Programvareutviklere må handle for å samles daglig gjennom hele prosjektet.
- Forbedrer smidigheten gjennom kontinuerlige tekniske forbedringer og godt design.
- Agile testing sikrer at sluttproduktet oppfyller virksomhetens forventninger ved å gi kontinuerlig tilbakemelding.
- I Agile Test-prosessen må vi utføre testprosessen under implementeringen, noe som reduserer utviklingstiden.
- Testprosessen i Agile bør fungere med konsekvent utviklingstempo
- Gi regelmessige refleksjoner om hvordan du kan bli mer effektiv.
- De beste arkitekturene, kravene og designene kommer fra selvorganiserende team.
- Hver gang teamet møtes, vurderer og justerer det atferden for å bli mer effektiv.
- Samtale ansikt til ansikt med utviklingsteamet er den mest effektive og effektive metoden for å formidle informasjon i teamet.
Agile testing inkluderer ulike prinsipper som hjelper oss å øke programvarens produktivitet.
Livssyklus for smidig testing
Den smidige testlivssyklusen fullføres i fem forskjellige faser, som vi kan se på følgende bilde:
Her er trinnene for agile prosesstesting:
Fase 1: Konsekvensanalyse: I denne startfasen samler vi inn innspill fra interessenter og brukere. Denne fasen kalles også tilbakemeldingsfasen, da den hjelper testingeniørene med å sette mål for neste livssyklus.
Fase 2: Planlegging av smidig testing: Det er den andre fasen av livssyklusen for smidig testing, hvor alle interessenter kommer sammen for å planlegge tidsplanen for testprosessen og leveransene.
Fase 3: Utgivelsesberedskap: På dette stadiet vurderer vi at funksjonene som er utviklet/implementert er klare til å gå live eller ikke. I denne fasen avgjøres det også hvilken som må gå tilbake til forrige utviklingsfase.
Fase 4: Daglige Scrums: Dette stadiet inkluderer hvert morgenmøte for standup for å følge med på teststatusen og sette målet for hele dagen.
Fase 5: Test Agility Revse: Den siste fasen av Agile-livssyklusen er Agility Review møte. Det innebærer ukentlige møter med interessenter for å jevnlig evaluere og vurdere fremgang i forhold til mål.
Agil testplan
Agil testplan inkluderer typer testing utført i den iterasjonen som krav til testdata, infrastruktur, testmiljøerog testresultater. I motsetning til fossefallsmodellen, i en smidig modell, skrives og oppdateres en testplan for hver utgivelse. Typiske testplaner i agile inkluderer
- Testingsomfang
- Nye funksjoner som testes
- Nivå eller typer testing basert på funksjonenes kompleksitet
- Last og ytelsestesting
- Infrastrukturhensyn
- Reduserings- eller risikoplan
- ressurs
- Leveranser og milepæler
Agile teststrategier
Livssyklusen for smidig testing spenner over fire stadier
iterasjon 0
Under den første fasen eller iterasjon 0 utfører du innledende oppsettoppgaver. Det inkluderer å identifisere personer for testing, installere testverktøy, planlegge ressurser (brukerbarhetstestlaboratorium), osv. Følgende trinn er satt til å oppnå i iterasjon 0
- Etablere en business case for prosjektet
- Etablere grensebetingelsene og prosjektets omfang
- Skisser de viktigste kravene og brukstilfellene som vil drive designavveiningene
- Skisser en eller flere kandidatarkitekturer
- Identifisere risikoen
- Kostnadsestimat og utarbeide et forprosjekt
Byggeterasjoner
Den andre fasen av smidig testmetodikk er Construction Iterations, mesteparten av testingen skjer i denne fasen. Denne fasen observeres som et sett med iterasjoner for å bygge en økning av løsningen. For å gjøre det, innenfor hver iterasjon, laget implementerer en hybrid av praksis fra XP, Scrum, Agile modellering og smidige data og så videre.
I konstruksjonsiterasjon følger det smidige teamet den prioriterte kravpraksisen: Med hver iterasjon tar de de mest essensielle kravene som gjenstår fra arbeidselementstabelen og implementerer dem.
Konstruksjonsiterasjon er klassifisert i to, bekreftende testing og undersøkende testing. Bekreftende testing konsentrater på å verifisere at systemet oppfyller intensjonene til interessentene som beskrevet for teamet til dags dato, og utføres av teamet. Mens undersøkende testing oppdager problemet som bekreftende team har hoppet over eller ignorert. I Undersøkende testing bestemmer testeren de potensielle problemene i form av feilhistorier. Undersøkende testing tar for seg vanlige problemer som integrasjonstesting, belastnings-/stresstesting og sikkerhetstesting.
Igjen for bekreftende testing er det to aspekter utviklertesting og smidig akseptansetesting. Begge to er automatisert for å muliggjøre kontinuerlig regresjonstesting gjennom hele livssyklusen. Bekreftende testing er den smidige ekvivalenten til testing i henhold til spesifikasjonen.
Agile aksepttesting er en kombinasjon av tradisjonell funksjonell testing og tradisjonell aksepttesting som utviklingsteamet, og interessenter gjør det sammen. Mens utviklertesting er en blanding av tradisjonell enhetstesting og tradisjonell tjenesteintegrasjonstesting. Utviklertesting verifiserer både applikasjonskoden og databaseskjemaet.
Slipp sluttspill eller overgangsfase
Målet med "Release, End Game" er å distribuere systemet ditt med suksess i produksjon. Aktivitetene inkluderer i denne fasen opplæring av sluttbrukere, støttepersoner og operative personer. Det inkluderer også markedsføring av produktutgivelsen, sikkerhetskopiering og gjenoppretting, ferdigstillelse av system- og brukerdokumentasjon.
Det siste trinnet for smidig metodikktesting inkluderer full systemtesting og aksepttesting. For å fullføre den siste testfasen uten noen hindringer, bør du teste produktet mer strengt mens det er i konstruksjonsgjentakelser. I løpet av sluttspillet vil testerne jobbe med defekthistoriene.
Produksjon
Etter utgivelsesstadiet vil produktet gå til produksjonsstadiet.
De smidige testkvadrantene
De smidige testkvadrantene skiller hele prosessen i fire kvadranter og hjelper til med å forstå hvordan smidig testing utføres.
Smidig kvadrant I
Den interne kodekvaliteten er hovedfokuset i denne kvadranten, og den består av testcases som er teknologidrevet og implementert for å støtte teamet, det inkluderer
- Enhetstester
- Komponenttester
Agile Quadrant II
Den inneholder testcases som er forretningsdrevet og implementert for å støtte teamet. Denne kvadranten fokuserer på kravene. Den typen test som utføres i denne fasen er
- Testing av eksempler på mulige scenarier og arbeidsflyter
- Testing av brukeropplevelse som prototyper
- Partesting
Smidig kvadrant III
Denne kvadranten gir tilbakemelding til kvadrant en og to. Testcasene kan brukes som grunnlag for å utføre automatiseringstesting. I denne kvadranten gjennomføres mange runder med iterasjonsgjennomganger som bygger tillit til produktet. Den type testing som gjøres i denne kvadranten er
- Brukervennlighetstesting
- Utforskende testing
- Partesting med kunder
- Samarbeidstesting
- Brukeraksepttesting
Smidig kvadrant IV
Denne kvadranten konsentrerer seg om de ikke-funksjonelle kravene som ytelse, sikkerhet, stabilitet, etc. Ved hjelp av denne kvadranten søkes det om å levere de ikke-funksjonelle kvalitetene og forventet verdi.
- Ikke-funksjonelle tester som stress- og prestasjonstesting
- Sikkerhetstesting mht autentisering og hacking
- Infrastrukturtesting
- Datamigrasjonstesting
- Skalerbarhetstesting
- Lasttesting
QA-utfordringer med smidig programvareutvikling
- Mulighetene for feil er mer smidige, ettersom dokumentasjon gis mindre prioritet, legger til slutt mer press på QA-teamet
- Nye funksjoner introduseres raskt, noe som reduserer den tilgjengelige tiden for testteamene til å identifisere om de nyeste funksjonene er i henhold til kravet og omhandler det virkelig forretningsdraktene
- Testere er ofte pålagt å spille en semi-utviklerrolle
- Testutførelsessykluser er svært komprimerte
- Svært mindre tid til å utarbeide testplan
- For regresjonstesting vil de ha minimal timing
- Endring i deres rolle fra å være en portvokter av kvalitet til å være en partner i kvalitet
- Kravendringer og oppdateringer er iboende i en smidig metode, og blir den største utfordringen for QA
Risiko for automatisering i smidig prosess
- Automatisert brukergrensesnitt gir et høyt nivå av selvtillit, men de er trege å utføre, skjøre å vedlikeholde og dyre å bygge. Automatisering forbedrer kanskje ikke testproduktiviteten vesentlig med mindre testerne vet hvordan de skal teste
- Upålitelige tester er en stor bekymring i automatisert testing. Å fikse mislykkede tester og løse problemer knyttet til sprø tester bør være en toppprioritet for å unngå falske positiver
- Hvis den automatiserte testen initieres manuelt i stedet for gjennom CI (Continuous Integration), er det en risiko for at de ikke kjører regelmessig og derfor kan føre til at testene mislykkes
- Automatiserte tester er ikke en erstatning for en utforskende manuell testing. For å oppnå forventet kvalitet på produktet kreves en blanding av testtyper og nivåer
- Mange kommersielt tilgjengelige automatiseringsverktøy gir enkle funksjoner som automatisering av fangst og avspilling av manuelle testsaker. Et slikt verktøy oppmuntrer til testing gjennom brukergrensesnittet og fører til en iboende sprø og vanskelig å vedlikeholde tester. Lagring av testsaker utenfor versjonskontrollsystemet skaper også unødvendig kompleksitet
- For å spare tid er automatiseringstestplanen ofte dårlig planlagt eller uplanlagt, noe som resulterer i at testen mislykkes
- En testoppsett- og riveprosedyre går vanligvis glipp av under testautomatisering, mens å utføre manuell testing, en testoppsett- og riveprosedyre høres sømløst ut
- Produktivitetsmålinger som et antall testtilfeller opprettet eller utført per dag kan være veldig misvisende, og kan føre til store investeringer i å kjøre ubrukelige tester
- Medlemmer av det smidige automatiseringsteamet må være effektive konsulenter: tilgjengelige, samarbeidsvillige og ressurssterke, ellers vil dette systemet raskt mislykkes
- Automatisering kan foreslå og levere testløsninger som krever for mye løpende vedlikehold i forhold til verdien som tilbys
- Automatisert testing kan mangle ekspertisen til å tenke ut og levere effektive løsninger
- Automatisert testing kan være så vellykket at de går tom for viktige problemer å løse, og dermed blir uviktige problemer.
Konklusjon
Smidig metodikk i programvaretesting innebærer testing så tidlig som mulig i livssyklus for programvareutvikling. Det krever høy kundeinvolvering og testkode så snart den blir tilgjengelig. Koden skal være stabil nok til å ta den til systemtesting. Omfattende regresjonstesting kan gjøres for å sikre at feilene er fikset og testet. Hovedsakelig gjør kommunikasjon mellom teamene smidig modelltesting til suksess!!!