Meny

10-trinns automatiseringstestprosess: Slik starter du automatiseringstesting i organisasjonen din

10 step automation testing process

Prøv Instrumentet Vårt For Å Eliminere Problemer

Automasjonstestprosess: Lær hvordan du starter automatiseringstesting på prosjektet ditt (en trinnvis guide)

I mange organisasjoner er kvalitet den første preferansen. Hvis du blir funnet å være i en slik organisasjon, og det fortsatt ikke er noen formell testautomatisering, kan du være personen til å innvie den.

Det vil hjelpe organisasjonen din med å bygge flere kvalitetsprodukter på kortere tid og på samme måte være i stand til å markedsføre det tidlig.

=> I dette tredje stykket av ‘ Test opplæringsserie for automatisering ’, Vil jeg diskutere hva som er testautomatiseringsprosess og hvordan du starter testautomatisering i organisasjonen din . Det er viktig å forstå hvilket trinn som er å utføre først og hvorfor.

Ved å følge disse trinnene vil du hjelpe deg med å introdusere automatisering på en sømløs måte og lar deg avverge vanlige fallgruver som fører til automatiseringsfeil.

trinn for å innføre testautomatisering

Hva du vil lære:

10-trinns automatiseringstestprosess for å starte testautomatisering

Her er en trinnvis testautomatiseringsprosess og en guide som hjelper deg med å starte automatiseringstesting.

La oss begynne.

Trinn 1.Overbevise ledelsen

Uansett hvor mye du er ivrig etter å oppdage og starte testautomatisering i organisasjonen din, kan du ikke gjøre noe hvis ledelsen ikke er overbevist om fordelene som testautomatisering tilbyr. Det er et universelt faktum at testautomatisering er dyrt. Verktøyene er dyre ( HP QTP / UFT lisens koster rundt $ 8K per maskin). Det koster en testautomatiseringsarkitekt eller ingeniør (som for øvrig også er dyrt). Etter det kan ikke fordelene med testautomatisering sees umiddelbart. Du må vente 2-3 måneder før manusene dine blir klargjort, testet, og det kan kjøres pålitelig for at du skal teste applikasjonen.

Du må overbevise ledelsen om å bære smerten av disse utgiftene, og du må også fortelle dem å være tålmodige før testautomatisering kan begynne å gi dem resultater.

Så hvordan blir de overbevist? Du må fortelle dem om kostnads-nytte-analysen. Som om du kan stille spørsmål om hvor lang tid vi tar å teste BAT (Build Acceptance Testing) av søknaden vår? Så kan du si, hvis det tar en dag, med testautomatisering, kan vi teste det innen 2 timer. Kostnaden er at du må kjøpe verktøyet, trene ressursen og vente på resultatene i to måneder. Etter to måneder vil vi kunne kjøre en BAT om to timer. Det vil spare 6 timer manuell testing hver gang en ny versjon slippes. Hvis build blir utgitt 4 ganger i måneden. Du vil kunne spare 24 timer eller 3 dager med manuell testing!

Det betyr ikke at manuelle testere ikke vil gjøre noe. De vil bruke disse 6 timene med testing for å fokusere på nye og viktige funksjoner i applikasjonen, mens automatisering vil ta seg av regresjonsproblemene. Dette oppsettet vil generelt forbedre produktkvaliteten et dusin ganger.

Hvis ledelsen ikke er villig til å betale for kvaliteten på produktene sine, kan ingen tvinge dem til å gjøre det. De lærer automatisk når klienter klager på produktene. Kvalitet påvirker alt. Det påvirker salget ditt, det påvirker forholdet til kunder, det påvirker din oppfatning i forbrukernes sinn. Så intelligent ledelse har alltid investert i kvaliteten på produktene deres.

Så fem poeng å huske på å overbevise ledelsen din:

  1. Fortell dem om fordelene med testautomatisering i detalj.
  2. Fortell dem at testautomatisering er dyrt, og det vil koste deg penger i utgangspunktet, men deretter vil kostnadene bli redusert når skript er klargjort og begynne å kjøre.
  3. Fortell dem at de må vente i rundt 3 måneder før de forventer noe resultat fra testautomatisering.
  4. Fortell dem at testautomatisering ikke er å erstatte manuelle testere, men å hjelpe manuelle testere, da de kan teste mer samtidig.
  5. Testautomatisering betyr ikke mer testing på kortere tid; det betyr mer testing på samme tid. (Hvis manuelle testere pleide å teste BAT på 8 timer, vil de kunne teste BAT pluss ny funksjonalitet pluss mange andre ting i de samme 8 timene i nærvær av automatisering.)

Husk at å overbevise ledelsen din er det første og viktigste trinnet i å innføre testautomatisering i organisasjonen din. Hvis de ikke er overbevist, glem testautomatisering eller endre organisasjonen. :)

Steg 2.Finne eksperter på automatiseringsverktøy

Det er to typer automatiseringseksperter.

  1. Automatiseringsarkitekter
  2. Automatiseringsingeniører

Automatiseringsarkitekter er en sjelden rase. De er vanskelige å finne, ekstremt dyre og ekstremt nødvendige for å lykkes med automatiseringsprosjektet. Disse menneskene er vanligvis ansvarlige for å bygge automatiseringsrammer. (Vi vil diskutere automatiseringsrammer i detalj i en egen artikkel)

Automatiseringsarkitekter oppleves i forskjellige typer verktøy, og de kjenner vanligvis styrker og svakheter ved hvert verktøy. De vil også hjelpe ledelsen med å velge riktig verktøy for automatisering ved å nøye analysere applikasjonen og teknologiene som brukes i den applikasjonen . De vil også bidra til å bygge rammeverket, utforme navnekonvensjonene og lage regler for skripting. De vil også hjelpe deg med å velge hvilke testsaker som skal automatiseres først.

Hvis du klarer å finne en riktig ressurs for stillingen som automatiseringsarkitekt, gjøres det halve arbeidet ditt med vellykket automatisering i organisasjonen din.

Automatiseringsingeniører derimot, er menneskene som vil konvertere manuelle testsaker til automatiserte skript. De vil jobbe under en automatiseringsarkitekt og vil være ansvarlig for å opprette og utføre skript .

Noen selskaper ansetter automatiseringsingeniører utenfra, og noen selskaper ansetter internt ved å trene sine eksisterende manuelle testere. Uansett må ressursen være god i programmering. Han / hun må vite spesielt om objektorientert programmering. En kombinasjon av 1 automatiseringsarkitekt og to automatiseringsingeniører er flott for de fleste produktene.

Trinn 3.Bruke riktig verktøy for automatisering

Dette punktet fortjener sin egen artikkel (og jeg vil skrive en om det). Dette er nok et vanskelig trinn i prosessen med å starte automatisering. Det finnes forskjellige verktøy i markedet, men du må velge de som er best for applikasjonen din.

For å gjøre det kort, vil jeg skrive de viktigste vurderingene mens jeg velger verktøyet. Jeg vil forklare prosessen for valg av verktøy i detalj i en egen artikkel.

De viktigste tingene du bør vurdere når du velger de riktige verktøyene, er:

  1. Verktøyet må være i ditt budsjett . Automatiseringsverktøyene er veldig dyre. Så selskapet bør ha budsjett for å kjøpe verktøyet.
  2. Verktøyet må støtte teknologier brukt i applikasjonen din. Hvis applikasjonen din bruker flash eller Silverlight, må verktøyet støtte det. Hvis applikasjonen din kjører på mobil, må verktøyet kunne utføre skript på mobil. Du kan kjøpe et enkelt verktøy som støtter all teknologi som brukes i applikasjonen din, eller du kan kjøpe separate verktøy for hver teknologi. For eksempel , kan du bruke selen til webapplikasjonene dine, roboter for Android-applikasjoner og MS-kodet brukergrensesnitt for stasjonære applikasjoner. Uansett beslutning, bør dette være i budsjettet ditt.
  3. Du må ha det nødvendige dyktige ressurser som kan bruke dette verktøyet eller lære det verktøyet på kortere tid. For eksempel , du har ansatt automatiseringsarkitekten som bare har opplevd QTP, og du kjøper en lisens for MS Coded UI, ressursen er kanskje ikke komfortabel med å bruke den. Verktøy er som gode biler, men du må også ha gode drivere for å kjøre disse gode bilene.
  4. Verktøyet må ha en god rapporteringsmekanisme å vise resultatene til interessenter etter hver gjennomføring.

Det er forskjellige andre faktorer når du velger riktig verktøy, og jeg vil dekke dem i en egen artikkel.

Les denne veiledningen for de nyeste automatiseringsverktøyene:

Topp 20 beste verktøy for automatiseringstesting i 2020 (omfattende liste)

Trinn 4.Analyserer forskjellige applikasjoner for å bestemme de som er best egnet for automatisering

Hvis organisasjonen din jobber med fem applikasjoner, er det ikke nødvendig at hver av dem skal automatiseres. Vi må se de forskjellige faktorene mens vi velger et hvilket som helst program som skal automatiseres.

Applikasjonen som skal automatiseres, må ha følgende faktorer:

  1. Søknaden skal ikke være i de tidlige stadiene av utviklingen. (Søknaden skal ha alle eller noen moduler som er stabile og testet av manuelle testere)
  2. Brukergrensesnittet til applikasjonen må være stabilt. (Brukergrensesnittet må ikke endres ofte)
  3. De manuelle testtilfellene til denne søknaden skal være i skriftlig form.

Hovedmålet med automatisering er å sørge for at hvis applikasjonen er feilfri i en versjon, skal den forbli feilfri i neste bygging. Den manuelle testeren skal ikke kaste bort tiden sin på å finne regresjonsproblemer, disse problemene bør identifiseres i automatisering.

Så for å finne en regresjon, må vi ha en applikasjon som allerede er stabil og har noen testtilfeller skrevet for den. Automatiseringsteamet vil konvertere disse testtilfellene til skript og vil kjøre disse skriptene på alle bygg for å sikre at ingen regresjon vises.

Les også => Hvordan velge riktige testtilfeller for automatiseringstesting

Trinn 5.Trening av teamet

Etter verktøyvalg og ressursutleie er neste trinn logisk opplæring av ressursene.

Hvis manuelle testere blir omgjort til automatiseringsingeniører, må de opplæres i automatiseringsterminologier og konsepter. Hvis det ansettes automatiseringsarkitekt utenfra, må han få kunnskap om produktet som skal testes, den manuelle testprosessen og hva ledelsen forventer.

Gi ressursene litt tid til å prøve forskjellige ting til de endelig kommer med en vinnende automatiseringsstrategi. Tren dem på verktøyene som organisasjonen allerede bruker bug tracking software og programvare for behovshåndtering .

God opplæring og sterk kommunikasjon mellom manuelle testere, utviklere og automatiseringsteam er virkelig nødvendig.

Trinn 6.Opprette rammen for testautomatisering

Den største oppgaven for automatiseringsarkitekten er å komme opp med et automatiseringsrammeverk som skal støtte automatisert testing i det lange løp.

Automatiseringsrammeverk er i utgangspunktet sett med regler og nøye planlegging for å skrive manusene på en måte som gir minst mulig vedlikehold. Hvis noe endres i applikasjonen, trenger manusene liten eller ingen oppdatering for å takle den endringen. Det er skjønnheten i et automatiseringsrammeverk.

Det er fem typer automatiseringsrammer, nemlig lineær, modulær, datadrevet, søkeorddrevet og hybrid. Alle disse rammene vil bli dekket i detalj med eksempler i en egen artikkel i denne serien.

Du kan også begynne å lese mer om automatiseringsrammer i følgende veiledninger:

=> Hvorfor trenger vi rammeverk for testautomatisering?
=> QTP Framework eksempler
=> Selenium Framework eksempler

Trinn 7.Utvikle en gjennomføringsplan

Utførelsesplanen inkluderer å velge hvilke miljøer manusene skal kjøres. Miljøet inkluderer OS, nettleser og forskjellige maskinvarekonfigurasjoner.

For eksempel , hvis testsaken krever at den skal sjekke nettstedet i tre nettlesere, nemlig Chrome, Firefox og IE, så vil automatiseringsteamet skrive skriptet på en slik måte at det vil være i stand til å utføre i hver nettleser.

Dette bør alltid fortelles før du skriver manusene, fordi det blir ivaretatt i manus hvis automatiseringsteamet vet det på forhånd. I gjennomføringsplanen skal det også fremgå at hvem som skal utføre manusene. Normalt utfører automatiseringsteamet skriptene på alle bygg, men det varierer fra selskap til selskap. Noen ledere ber utviklere om å utføre disse skriptene på deres build før utgivelsen, og noen selskaper ansetter en dedikert ressurs bare for utførelsen. Selv noen selskaper kjører skript i uovervåket modus, noe som selvfølgelig ikke krever noen ekstra ressurs.

Trinn 8.Skrive manus

Når rammeverket er utformet, er utførelsesplanen kjent og ressurser blir trent på det nye verktøyet. Nå er det riktig tidspunkt å begynne å skrive manus.

Manus skal skrives på en organisert måte med riktig navngivningskonvensjon. Kildekoden bør opprettholdes i en kildekontroll for å unngå tap av kode. Versjonskontroll og historikk bør opprettholdes. Testautomatisering er akkurat som programvareutvikling. Alle beste programmeringsrutiner bør tas vare på mens du skriver manusene.

Les også => Hvordan oversette manuelle testtilfeller til automatiseringsskript

Trinn 9.Rapportering

Rapporteringsfunksjonen leveres vanligvis av verktøyet. Men vi kan lage tilpassede rapporteringsmekanismer som å sende resultatene automatisk til ledelsen.

Vi kan lage rapporter på slutten av hver utførelse i form av diagrammer og tabeller hvis ledelsen trenger det. Ledelsen bør alltid informeres om dekksaken av testsaken, det vil si hvilke manuelle testsaker som dekkes av automatisering og hvilke av dem som gjenstår.

Trinn 10.Vedlikehold av skript

Hvis beste programmeringspraksis følges og rammeverket er bra, vil ikke vedlikehold være noe problem.

Vedlikehold skjer vanligvis når det er en endringsanmodning om en applikasjon. Manusene bør umiddelbart oppdateres for å takle den endringen for å sikre feilfri utførelse.

For eksempel , hvis du skriver litt tekst i tekstboksen gjennom skriptet og nå blir denne tekstboksen rullegardinlisten, bør vi umiddelbart oppdatere skriptet.

Noen andre typer endringer inkluderer at manusene dine kjørte på den engelske versjonen av applikasjonen. Nå er det en endringsforespørsel om at applikasjonen skal støtte kinesisk. Rammeverket ditt skal tillate deg å oppdatere skriptene dine med liten innsats for å støtte utførelse på kinesisk også! Derfor er automatiseringsarkitekter dyre. :)

Hvis rammeverket ikke er bra og beste praksis ikke følges, vil vedlikehold bli et mareritt. De fleste automatiseringsprosjekter mislykkes på grunn av dårlig vedlikehold av skript.

Konklusjon

Denne artikkelen beskriver hva er automatiseringsprøveprosessen og hvordan du starter automatiseringstesting i organisasjonen din fra start til slutt trinnvis. Hvis du følger disse trinnene, håper jeg automatiseringen din vil lykkes.

Foreslått lesing = >> Beste IT-prosessautomatiseringsprogramvare

Det er noen deler (som valg av automatiseringsverktøy og automatiseringsrammer) som fortjener sine egne artikler. Vi vil dekke disse i kommende deler av denne opplæringsserien for automatiseringstesting.

=> I mellomtiden Klikk her for å sjekke alle veiledningene vi har allerede lagt ut i denne serien.

Jeg prøvde å dekke alle aspekter i et bredere syn og bruk min egen erfaring til å skrive denne veiledningen.

Hvis du føler at jeg savnet noe viktig, eller noen deler av denne veiledningen trenger litt mer forklaring, kan du spørre meg i kommentarfeltet. Jeg vil gjerne svare på spørsmålene dine.

hvilket av følgende er definisjonen av testing av hvit boks?

PREV Opplæring nr. 2 | NESTE veiledning nr. 4

Anbefalt lesing

^