Menu

Hvordan adskiller testplanlægningen sig for manuelle og automatiseringsprojekter?

how does test planning differ

Prøv Vores Instrument Til At Fjerne Problemer

Vi er alle enige om, at automatiseringsprojekter er forskellige i forhold til manuelle testprojekter. Selvom autonome automatiseringsprojekter ikke rigtig eksisterer (eller ikke burde eksistere ideelt), behandles både manuelle og automatiseringsprojekter forskelligt, når de planlægges.

Et mix planlagt projekt uundgåeligt får udføres; dette påvirker ikke kun det aktuelle projekt og kaster en skygge for individets evner, men kan også føre til tab af tillid til teamet for klienten / ledelsen, hvilket påvirker yderligere forretning. Jeg vil hellere sige, at vi testere er sikre end ked af det.

=> Klik her for en komplet testplan-tutorial-serie

Testplanlægning

En god Dilbert-tegneserie om planlægning:

projektplanlægning dilbert

Inden vi går videre, vil jeg fastslå, hvad denne artikel IKKE handler om.

# 1) Dette er ikke en grundig diskussion af automatiseringsrammer. Forskellige projekter bruger forskellige rammer afhængigt af karakteren af ​​deres AUT, arkitektur, kompleksitet, teamets ekspertise osv.

Oplysningerne om rammerne kan findes på nedenstående links:

Test automatiseringsrammer del 1 og del 2 .

#to) Dette handler heller ikke om skabelon, format eller oprettelse af en Testplan dokument . Vi vil tage hensyn til præ-dokumentationsovervejelserne for et automatiseringsprojekt mere i tråd med en gennemførlighedsanalyse.

# 3) Dette er heller ikke værktøjer specifikt. Hver aktivitet i SDLC tager tid, kræfter, infrastruktur - med andre ord - PENGE.

For et manuelt testprojekt er de omkostningsforbrugende faktorer:

  • Mennesker
  • Værktøjer - Test / fejlhåndtering
  • Infrastruktur - miljø
  • Tid
  • Uddannelse

For et automatiseringsprojekt har det ud over ovenstående poster brug for udgifter til:

  • Automatiseringsværktøjer
  • Tilføjelse til integration af teststyringsværktøjer
  • Tilføjelse til understøttelse af AUT (som SAP, Oracle osv.)
  • Ramme oprettet
  • Værktøjsspecifik træning

Under disse omstændigheder afhænger succesen af ​​et automatiseringsprojekt af, hvor godt du har skrevet koden, hvor mange genanvendelige komponenter, du har skrevet, eller i hvor få kodelinjer, du har opnået det ønskede resultat?

Lade være med.

Der er et og det eneste spørgsmål, der bestemmer succesen - “Er du i stand til at generere et bedre ROI (Return on Investment) sammenlignet med den manuelle rute”? - Hvis ikke straks, til sidst.

Hvis svaret på dette spørgsmål er “NEJ”, har du planlagt Automation-projektet forkert.

Normalt har en testplan følgende afsnit. Vi vil diskutere hver enkelt af dem med fokus på automatiseringsspecifikke aspekter, der skal overvejes:

plan for automatiseringstest

Automatiseringstest Testplanafsnit

Afsnit 1:Anvendelsesområde

  • Vælg de testsager / scenarier, der skal regresseres igen og igen på tværs af flere cyklusser.
  • Nogle gange har de enkleste testsager brug for masser af komplicerede løsninger, der skal automatiseres. Hvis disse kun er til engangsbrug, giver det selvfølgelig ikke mening. Genanvendelighed skal være dit fokus.
  • Automatiseringstest udfører / kan ikke udføre sonderende test.

Afsnit # 2: Teststrategi

  • Dette afsnit kaldes Framework i Automation-verdenen. Nogle rammer er ekstremt udfordrende at skabe og er også effektive - men tid, kræfter og kompetencer er krævende. Se altid efter en mellemvej og gør det bedste, du kan, uden at overudnytte ressourcerne i fare.
  • Beslut om kodning af bedste praksis, der skal bruges, navngivningskonventioner, placeringer for testaktiver, der skal lagres, formatet for testresultater osv. For at opretholde ensartethed og øge produktiviteten.

Afsnit # 3:Ressourcer / roller og ansvar

  • Det første skridt i denne retning er at forstå holdets muligheder og forudse inden omfanget af automatisering, der kommer ind i billedet. Dette hjælper med at vælge et team, der passer til både automatiserings- og manuel testbehov. Vælg også folk, der har den rigtige holdning - de mener ikke, at manuel test er under deres statur.
  • Vælg et team, der er fortrolig med AUT, Test Management, Defect Management og andre SDLC-aktiviteter
  • Afsnit # 1: Anvendelsesområde

Afsnit # 4:Værktøjer

Vælg automatiseringsværktøjer baseret på følgende regler:

  • Har virksomheden allerede licenser til et bestemt værktøj, prøv at se om du kan bruge det
  • Kig efter open source (men pålidelige) værktøjer
  • Kender teammedlemmerne værktøjet allerede, eller har vi brug for at hente nogen nye? Eller træne de eksisterende?

Afsnit # 5: Tidsplaner

  • Medtag tid til gennemgang af kode og inspektion af Automation-scripts
  • Vedligehold scriptsne i tide. Hvis du opretter et stykke kode, som du ikke skal bruge i de næste 6 måneder, skal du sørge for regelmæssigt at vedligeholde det for at mindske dets chancer for fiasko.

Afsnit # 6:Miljø

  • Det målmiljø, som din AUT skal køre, og det automatiseringsværktøj, du vil bruge, skal være kompatibelt. Dette er en af ​​de faktorer, der skal betragtes som prælicensiering af værktøjet.
  • Analyser også, om resten af Ledelsesværktøjer på plads, og det automatiseringsværktøj, du prøver at bringe, er indbyrdes forbundne for yderligere fordele.

Afsnit # 7:Leverancer

  • Dine testskripter er dine leverancer. Imidlertid er ikke alle automatiserede / programmeringssprog kyndige. Så planlæg at oprette et 'How-to' -dokument, der hjælper de nuværende brugere og fremtidige teammedlemmer til at være i stand til at forstå dette script, selv når du ikke er i nærheden.
  • Medtag også kommentarer i dit script.

Afsnit # 8: Risici

Hvis du vil foreslå en automatiseringsløsning, skal du sørge for at vælge omkostningseffektive værktøjer og løsninger for at sikre, at Automation-bestræbelsen ikke belaster projektet.

Det er vigtigt at indstille forventningen om, at ROI for et automatiseringsprojekt ikke kan være positivt med det samme, men kan ses tydeligt over lange perioder.

Derfor, hvis du foreslår automatisering af et system, skal du vælge det, der er

  • Stabil og ikke for meget vedligeholdelse
  • Har plads til enorme regressionssuiter
  • Har ikke for meget manuel indgriben eller afhænger ikke af et menneskes intuition

Afsnit 9:Testdata

  • Tag højde for sikkerhedsaspekterne ved dataene
  • Indsæt ikke testdata hårdt i scripts. Dette fører bare til for meget vedligeholdelse af script og kan medføre fejl under ændring.
  • Vær meget specifik. For et manuelt testtrin - 'indtast fornavnet', kan du sige indtast et hvilket som helst navn på 5 tegn. Under test kan en tester skrive 'Swati' eller 'Seela' eller noget andet. Men for et værktøj kan det ikke komme med sådanne formodninger. Angiv derfor nøjagtige værdier.

Afsnit # 10:Rapporter / resultater

  • Resultater for scriptudførelse er også tekniske og kan ikke forstås let af resten af ​​holdene. Planlæg at skrive detaljerede resultater til notesblok eller excel-ark som en yderligere foranstaltning.
  • Der forventes også detaljerede rammedokumenter, gennemgangsresultater, fejlrapporter, eksekveringsstatusrapporter.

Vi som automatiseringsentusiaster tror måske, at klienter / ledelse ikke let køber automatiseringsforslagene.

c ++ konverter char * til int

Men når vores ultimative mål er at maksimere ROI gennem automatisering, er vi også i perfekt harmoni med ledelsens / klientens mål. Dette vil sikre, at vi ikke kun kommer til at automatisere vores projekt, men vil være i stand til at gøre det med masser af samtykke, samarbejde og spænding.

Planlægning og grundig analyse af alle ovennævnte faktorer kan være vores allierede gennem denne rejse. Igen betyder ROI alt.

Dette indlæg er skrevet af STH-forfatteres teammedlem Swati Seela.

Har du spørgsmål eller ting at diskutere? Du er velkommen til at skrive i nedenstående kommentarer.

=> Besøg her for en komplet testplan-tutorial-serie

Anbefalet læsning

^