Agile Test Automation Framework

I løpet av de siste årene, helt siden den smidige metodikken kom om bord med grunnleggerne ropende og villige til å gjøre opp med de verdslige og arbeidskrevende realitetene til den tradisjonelle fossefallsmodellen, kan virkningen av den samme merkes også når det gjelder Automatiseringstesting.

Automatisering i Waterfall vs Automation in Agile

I området for den tradisjonelle prosessen med livssyklus for programvaretesting, er automatiseringstesting normalt mulig når applikasjonen er stabil, stødig og kravet er involvert med en virkelig betydelig tid og i de fleste tilfeller involverer det et sett med svært dyktige automasjonsekspertressurser samt en betydelig mengde etableringskostnader. Det grunnleggende formålet med automatiseringstesting er å redusere kostnadene over lang tid og sikre at ingen nye feil har blitt introdusert som følge av eksisterende testtilfeller.

Automatiseringstesting er etter teknologiens natur ikke utforskende i naturen siden hovedrollen til automatiseringstesting er å spare tid og redusere kostnader. Automatiseringstesting er ikke ment å komme opp med nye og innovative feil. Automatiseringstesting tar hovedsakelig sikte på bekreftelse av det allerede eksisterende.

Hvordan automatisere i Agile Metodikk

Agil metodikk snakker nå i sin definisjon om å fjerne arbeidskrevende og kjedelig dokumentasjon slik at nye og innovative ideer kan implementeres og folk kan samhandle fritt med hverandre slik at flere av disse innovative og utforskende ideene kan implementeres.

Dermed kunne vi se en motsetning mellom de grunnleggende grunnleggende filosofiene til smidige metoder og automatiseringstesting.

Grunnleggende poeng for smidig testautomatisering

Så vi må vurdere visse grunnleggende punkter her når det gjelder å evaluere bruken av smidige metoder med hensyn til automatiseringstestmetoder og -teknikker. Derfor må vi vurdere noen grunnleggende punkter som tid det tar for design og koding, validering av de utformede skriptene med de eksisterende testdataene og bruken av de samme for testing (enten testene har funksjonelle eller regresjonsformål) Så det virkelige faktum alle disse hendelsene er at for å utføre alle disse faktaene, må vi sørge for at det kreves en betydelig mengde tid for disse oppgavene og i et smidig miljø der en gjennomsnittlig sprint tar gjennomsnittlig 1-2 uker å fullføre, og dermed er det åpenbart for vanskelig å tenke på å gi så mye tid til å automatisere skript på en slik måte.

En annen vesentlig faktor gjenstår her at typen endringer i krav som kommer inn i bildet når den smidige metodikken er i bruk. Den smidige metodikken er i sin egen definisjon en slags teknikk som er svært nyttig for å svare på raske kundeinduserte endringskrav og som dermed egner seg godt til hyppige endringer under den generelle utviklingen av applikasjonen.

Derimot er automatiseringstesting veldig nyttig når det kommer til de mer stabile og mindre hyppige kravene. Derfor egner automatiseringstesting seg per definisjon ikke godt til ulike typer hyppige endringer i krav som kommer sammen med bruk av smidige metoder.

Agile automatiseringsverktøy

Utvalget av relevante automatiseringsverktøy er også en potensielt svært viktig faktor når det gjelder å ta i bruk automatiseringstesting innenfor rammen av en overordnet smidig metodikk. Lisensierte automatiseringsverktøy, for eksempel, pålegger strenge sikkerhetstilgangskriterium til forskjellige typer og nivåer av brukere når det gjelder tilgang til forskjellige viktige ressurser som tilhører det bestemte testautomatiseringsrammeverket.

I kontrast legger smidig metodikk vekt på stort sett åpent samarbeid og åpen interaksjon mellom teammedlemmer og dermed restriktive retningslinjer som direkte påvirker hvordan brukerne vil ha en negativ innvirkning på den generelle samhørigheten i teamet og dermed kan føre til resultater som verken er særlig nyttig eller veldig gunstig for den generelle suksessen til prosjektet.

Derfor bør den primære viktigheten av prosessen være å sikre at for å oppnå kvalitetslevering av automatiseringstestskript innen en fastsatt tid som er gitt av smidig metodikk; vi må velge våre potensielle testtilfeller som vil bli automatisert på en mer nyansert måte slik at disse automatiserte testskriptene egner seg godt for fremtidig gjenbruk i tillegg til å sikre at de kan forberedes innenfor riktig varighet av den tildelte tiden (som kreves under den smidige metodeprosessen).

Etter å ha vurdert alle de ovennevnte faktorene kan vi derfor innse at selv når vi tar i bruk smidige metoder, må vi bringe inn i bildet hvilke typer tester som for eksempel regresjonstester (siden selv under smidig testing er det en betydelig mengde testarbeid som kreves å sette inn jobben med smidige metoder for å sikre bedre kvalitet på det totale produktet)

La oss nå se på de mest grunnleggende situasjonene der automatiseringstesting kan brukes, og hvordan vi kan bruke det samme mot riket av smidig testing.

Automatiseringstesting Concepts når den brukes på Agile