Hva er smidig testing?
AGILE TESTING er en testpraksis som følger reglene og prinsippene for smidig programvareutvikling. I motsetning til Waterfall-metoden kan Agile Testing begynne i starten av prosjektet med kontinuerlig integrasjon mellom utvikling og testing. Agile Testing-metoden er ikke sekvensiell (i den forstand den bare utføres etter kodingsfasen), men kontinuerlig.
I denne artikkelen vil vi diskutere
- Agil testplan.
- Agile Testing Strategies.
- The Agile Testing Quadrant.
- QA utfordrer med smidig programvareutvikling.
- Fare for automatisering i smidig prosess.
Agil testplan
Agile testplan inkluderer typer testing utført ved at iterasjon som testdatakrav, infrastruktur, testmiljøer og testresultater. I motsetning til fossemodellen, i en smidig modell, skrives og oppdateres en testplan for hver utgivelse. Typiske testplaner i smidige inkluderer
- Testing Omfang
- Nye funksjoner som testes
- Nivå eller typer testing basert på funksjonenes kompleksitet
- Last- og ytelsestesting
- Infrastrukturhensyn
- Avbøtende eller risikoplan
- Resursing
- Leveranser og milepæler
Agile Testing Strategies
Agile testing livssyklus strekker seg over fire trinn
(a) Iterasjon 0
I løpet av første trinn eller iterasjon 0 utfører du innledende oppsettoppgaver. Det inkluderer å identifisere personer for testing, installere testverktøy, planlegge ressurser (brukervennlighetstestingslaboratorium) osv. Følgende trinn er satt til å oppnå i Iterasjon 0
a) Etablere en business case for prosjektet
b) Etablere grensevilkår og prosjektomfang
c) Skissere nøkkelkravene og brukstilfeller som vil føre til kompromissene mellom design
d) Skissere en eller flere kandidatarkitekturer
e) Identifisere risikoen
f) Kostnadsestimering og utarbeide et forprosjekt
(b) Konstruksjonsterasjoner
Den andre fasen av smidig testmetodikk er konstruksjonsterasjoner, de fleste testene skjer i denne fasen. Denne fasen observeres som et sett med iterasjoner for å bygge en økning av løsningen. For å gjøre det, innen hver iterasjon, implementerer teamet en hybrid av praksis fra XP, Scrum, Agile modellering og smidige data og så videre.
I bygg iterasjon følger det smidige teamet den prioriterte kravpraksisen: For hver iterasjon tar de de viktigste kravene som gjenstår fra arbeidsgjenstanden og implementerer dem.
Bygg iterasjon er klassifisert i to, bekreftende testing og undersøkende testing. Bekreftende testing konsentrerer seg om å verifisere at systemet oppfyller intensjonen til interessentene som beskrevet til teamet til dags dato, og utføres av teamet. Mens undersøkelsestestingen oppdager problemet som bekreftende team har hoppet over eller ignorert. I undersøkende testing bestemmer tester potensielle problemer i form av mangelfortellinger. Undersøkende testing omhandler vanlige problemer som integrasjonstesting, belastning / stresstesting og sikkerhetstesting.
Igjen for, bekreftende testing er det to aspekter utvikler testing og smidig aksept test . Begge er automatisert for å muliggjøre kontinuerlig regresjonstesting gjennom hele livssyklusen. Bekreftende testing er den smidige ekvivalenten av testing til spesifikasjonen.
Agile aksept testing er en kombinasjon av tradisjonell funksjonell testing og tradisjonell aksept testing som utviklingsteamet, og interessenter gjør det sammen. Mens utviklertesting er en blanding av tradisjonell enhetstesting og tradisjonell serviceintegrasjonstesting. Utviklertesting verifiserer både applikasjonskoden og databaseskjemaet.
(c) 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 operasjonelle personer. Det inkluderer også markedsføring av produktutgivelse, sikkerhetskopiering og gjenoppretting, sluttføring av system- og brukerdokumentasjon.
Den siste smidige testmetoden inkluderer fullstendig systemtesting og godkjenningstesting. I samsvar med å fullføre den endelige testfasen uten hindringer, må du teste produktet strengere mens det er i konstruksjonsgjenoppretting. I sluttspillet vil testere jobbe med defekte historiene.
(d) Produksjon
Etter utgivelsesfasen vil produktet flytte til produksjonsfasen.
The Agile Testing Quadrants
De smidige testkvadranter skiller hele prosessen i fire kvadranter og hjelper til med å forstå hvordan smidig testing utføres.
a) Agile Quadrant I - Den interne kodekvaliteten er hovedfokuset i denne kvadranten, og den består av testtilfeller som er teknologidrevet og er implementert for å støtte teamet, den inkluderer
1. Enhetstester
2. komponenttester
b) Agile Quadrant II - Den inneholder testtilfeller som er forretningsdrevet og er implementert for å støtte teamet. Denne kvadranten fokuserer på kravene. Den typen test som er utført i denne fasen er
1. Testing av eksempler på mulige scenarier og arbeidsflyter
2. Testing av brukeropplevelse som prototyper
3. Par testing
c) Agile Quadrant III - Denne kvadranten gir tilbakemelding til kvadranter en og to. Testtilfellene kan brukes som grunnlag for å utføre automatiseringstesting. I denne kvadranten gjennomføres mange runder med iterasjonsgjennomganger som bygger tillit til produktet. Den typen testing som er gjort i denne kvadranten er
1. Testing av brukervennlighet
2. Utforskende testing
3. Par testing med kunder
4. Samarbeidstesting
5. Testing av brukeraksept
d) Agile Quadrant IV - Denne kvadranten konsentrerer seg om ikke-funksjonelle krav som ytelse, sikkerhet, stabilitet, etc. Ved hjelp av denne kvadranten er det søkt å levere de ikke-funksjonelle kvalitetene og forventet verdi.
1. Ikke-funksjonelle tester som stress og ytelsestesting
2. Sikkerhetstesting med hensyn til autentisering og hacking
3. Testing av infrastruktur
4. Testing av datamigrering
5. Testing av skalerbarhet
6. Lasttesting
QA utfordrer med smidig programvareutvikling
a) Sjansene for feil er mer smidige, ettersom dokumentasjon blir prioritert mindre, til slutt legger mer press på QA-teamet
b) Nye funksjoner introduseres raskt, noe som reduserer den tilgjengelige tiden for testteam til å identifisere om de nyeste funksjonene er i samsvar med kravet, og adresserer det virkelig forretningens dresser
c) Det kreves ofte at testere skal spille en semi-utvikler
d) Testutførelsessykluser er høyt komprimerte
e) Svært kortere tid til å utarbeide testplan
f) For regresjonstesting vil de ha minimal timing
g) Endring i deres rolle fra å være en portholder for kvalitet til å være en partner i Quality
h) Kravendringer og oppdateringer ligger i en smidig metode, som blir den største utfordringen for QA
Fare for automatisering i smidig prosess
- Automatisert brukergrensesnitt gir høyt tillit, men de er sakte å utføre, skjøre å vedlikeholde og dyre å bygge. Det kan hende at automatisering ikke forbedrer testproduktiviteten vesentlig med mindre testerne vet hvordan de skal teste
- Upålitelige tester er en stor bekymring i automatisert testing. Å fikse sviktende tester og løse problemer relatert til sprø tester bør være en topprioritet for å unngå falske positive
- Hvis den automatiserte testen startes manuelt i stedet for gjennom CI (kontinuerlig integrasjon), er det en risiko for at de ikke kjører regelmessig og derfor kan føre til mislykkede tester
- Automatiserte tester er ikke en erstatning for en utforskende manuell testing. For å oppnå den forventede kvaliteten på produktet kreves en blanding av testtyper og nivåer
- Mange kommersielt tilgjengelige automatiseringsverktøy gir enkle funksjoner som å automatisere fangst og avspilling av manuelle testsaker. Slike verktøy oppmuntrer til testing gjennom brukergrensesnittet og fører til en iboende sprø og vanskelig å opprettholde tester. Lagring av testtilfeller utenfor versjonskontrollsystemet skaper også unødvendig kompleksitet
- For å spare tid, er automatiseringstestplanen dårlig planlagt eller ikke planlagt mange ganger, noe som resulterer i at testen mislykkes
- En testoppsett og nedrivningsprosedyrer blir vanligvis savnet under testautomatisering, mens du utfører manuell testing, en testoppsett- og nedrivningsprosedyrer høres sømløs ut.
- Produktivitetsmålinger som for eksempel en rekke testsaker opprettet eller utført per dag kan være veldig misvisende, og kan føre til en stor investering i å kjøre ubrukelige tester
- Medlemmer av det smidige automatiseringsteamet må være effektive konsulenter: tilgjengelig, samarbeidsvillig og ressurssterk, ellers vil dette systemet raskt mislykkes
- Automatisering kan foreslå og levere testløsninger som krever for mye løpende vedlikehold i forhold til verdien
- Automatisert testing kan mangle kompetanse til å bli gravid og levere effektive løsninger
- Automatisert testing kan være så vellykket at de går tom for viktige problemer å løse, og dermed vender seg til uviktige problemer.
Konklusjon
Agil metodikk i programvaretesting innebærer testing så tidlig som mulig i livssyklusen for programvareutvikling. Det krever høy kundeinnblanding 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 lagene smidig modelltesting suksess !!!