5 grunde, du skal vide om, før du bygger dit testautomatiseringsprojekt

I teorien skal testautomatiseringsprogrammer eller -værktøjer gøre tingene lettere for testere, fritid og give os et ekstra afslapningstæppe til vores evalueringsdækning.

Og så mange organisationer undlader at implementere en skalerbar, stærk og god Test Automation-infrastruktur, der returnerer de ressourcer, der er investeret og kan spare dem. Nogle "Kast" skriftlige testautomatiseringsjob, og andre opretholdt i en løbende kamp med deres mål om at tjene en stabil automatiseringspakke.

I årenes løb har jeg observeret mange virksomheder, der forsøger at udføre deres automatiseringsindsats, jeg har set skriftlige projekter kastet, rammer skiftet og ledere fyret, fordi de ikke leverede det, der er blevet lovet eller sat som et mål.

Der er mange grunde til fiasko, selvom automatisering giver perfekt mening på lang sigt, er vi nødt til at forstå, at det er langt hårdere, som det ser ud til.

Nedenfor er et par af de grunde, du skal vide om, før du springer videre og begynder at opbygge dit testautomatiseringsprojekt:

Analyser og still spørgsmål: Et testautomatiseringsjob er et job som ethvert andet applikationsprojekt og burde behandles ligesom et; Hvordan ville du behandle planlægningen af et softwareprojekt? Lad denne idé lede dig, når du tænker på at implementere dit Test Automation-projekt. Hvem ville du vælge til jobbet? Hvem bruger det producerede produkt? Hvilket sprog eller ramme er bedst egnet til jobbet? Ville du forstå ud fra udfordringer og deres retningslinjer og få et kig? Ville du komponere en arkitektur, du ikke ved noget om på egen hånd, eller vil du ringe til en rådgiver for at rådgive dig med et par tanker?

Alle disse spørgsmål er simpelthen toppen af dette isbjerg af, hvad du burde spørge dig selv, før du skriver en linie kode eller endda testsituation.

Utilstrækkelig Skillset: Lad mig stille dig et spørgsmål. Vil du tillade værre eller en ikke-erfaren programmør, en person, der ikke forstår, hvordan man komponerer en god ren søgbar kode - stil design af din app og skriv den fra bunden? Jeg tror, at svaret er nej. Så hvorfor tror så mange virksomheder, at kvalitet kunne implementeres af nogen Evaluation Automation-infrastruktur uden erfaring og dygtighed? Hvis det dedikerede personale ikke har erfaring og viden, og du ikke planlægger at ansætte nogen, der har det, skal du overveje at bruge kodeløse automatiseringsværktøjer.

Urealistiske forventninger / tilgang: Jeg deler den i to dele. Den første er en fejlagtig forståelse af ROI (return of investment) af testautomatisering, og den anden komponent er urealistiske forventninger pr. Tidsramme. Der er et job så godt som det er lavet af dig, og du kan ikke forvente noget uden at investere tid til at levere værdi. Jeg har talt med en QA-ingeniør, der fortalte mig, at han fik 6 timer ugentligt for at komponere en undercover-infrastruktur. Hvad skal du forvente, at han opnår 6 timer?

For at få dette til at fungere skal du spørge:

• Hvad er de mål, du ønsker at opnå sammen med din testautomatisering?
• Hvad ville blive betragtet som en fantastisk værdi for indsatsen / tiden?
• Hvad er kriterierne for opnåelse?
• Hvor meget tid / penge er du parat til at bruge for at få det til at ske?

Automatisering er ikke en "Start og glem" -opgave. Du vil erkende, at det er en kontinuerlig proces, der kræver vedligeholdelse, en gruppeindsats og fremskridt.

Jeg må erkende, at desværre ved det, jeg har set, oplever nogle virksomheder at give en QA-ingeniør et undercover-job som kun en måde at bevare en arbejdstager eller lægge noget " krydderi " i hans ugentlige rutine. Gør mig ikke forkert, jeg siger ikke, at vi ikke skal bevare vores arbejdere eller give dem tid til at lære og fremskridt, jeg siger kun, at det skal være i overensstemmelse med forventninger, der er realistiske og gennemsigtighed i arbejdstageren, det selv .

Utilstrækkelig planlægning: Et fantastisk automatiseringsprojekt skal starte med en plan og plan på højt niveau, der vil udvikle sig til en omfattende teknisk stil. Selv strategien "En størrelse passer alle" kan være katastrofal for din succes. Det, der fungerede fremragende for et enkelt firma, indikerer ikke nødvendigvis, at det ville gøre jobbet for dig. Denne meddelelse kan være sandt om et instrumentvalg. Når du faktisk ikke behøver at bruge den pågældende teknologi, går det op til buzz word. Dette er uhyre vigtigt at bemærke. Der er et stort antal open source og kommercielle værktøjer derude, som kan give værdi for pengene, der er høj og uden engang at overveje alternativerne og de fordele / alternativ, disse værktøjer kan tilbyde. Vælg et værktøj, der opfylder dine behov. Her er mine to cent - det er langt meget bedre at betale for en løsning snarere end at spilde mange gange (Det vil træde op til at være langt dyrere end programmets omkostningsskilt).

Når vi fortsætter med at diskutere måden at planlægge vores design på, bliver vi nødt til at tænke over vores altomfattende tekniske arkitektur og forretningskrav. Her er blot nogle af de aspekter, du skal tage i betragtning:

• Forestil dig job, moduler, forretningsstrømme, ville folk undersøge?
• Hvad er den planlagte politik for hver udførelsesfase? (Sanity, Regression, CI / CD dedikeret pakke?)
• Hvad er de vigtigste delte / fælles / gentagne flow / funktionalitet?
• Hvordan planlægger vi hver test for en kort, uafhængig artefakt? (SetUp og TearDown, afhængighed af eksterne data i stedet for genererede evalueringsdata, Hvad skal der køres før hver test, suite-klasse?)
• Hvordan forhindrer vi en evaluering, der "bryder" en anden, hvis de kører i samtidighed?
• Hvordan kan vi producere en god skalerbar, ren og passende atmosfære? (Mock-servere, databasesager, oprydningsscript, browserindstillinger, net- / serverkonfigurationer, opsætning og oprydning, virtuelle omgivelser eller dockercontainere).
• Hvad bygger vi præcist værktøjer, hvis vi bruger?
• Præcis hvordan kunne vores afhængigheder styres?
• Hvor opbevares vores projekt?
• Hvor mange ingeniører arbejder på projektet og den måde, hvorpå variantledelsen ville blive styret?
• Hvilke CI-værktøjer er bedst til at udføre vores builds?
• Vil du implementere CI / CD workflow?
• Hvor vil du køre dine tests og ressourcer, som du kan bruge til at designe din egen eksekveringsplatform? (Får du midlerne til at købe cloud-løsningstilladelser? Har du værktøjerne eller supporten til at etablere din egen Selenium Server-infrastruktur?)
• Præcis hvilken slags tests vil snart være automatiske? (API, Visual Concepts, Server processer, Web / UI Automation, Mobile - Android / IOS).
• Er der nogle store datasamlinger, lange strømme, komplicerede processer, integrationer, der vil kræve yderligere vurdering?
• Hvad skal vi teste gennem GUI, og hvad der kan være mere sikkert at kontrollere via API'en?
• Præcis hvilke logfiler, rapporteringsmekanismer, håndterere og lyttere skal vi implementere for at gøre vores rodårsagsevaluering og fejlretning enklere? (Hvad er en times automatiseringspakke, hvis du bruger en dags forståelse af resultatet?)
• Hvilke målinger / rapport / output skal kørsler levere?
• Præcis hvilke integrationer ønsker vi virkelig? (Rapporteringsprogrammer, ALM-værktøjer, Bug Trackers, Evalueringsstyringsprogrammer).
• Hvem kan sammensætte infrastrukturen, og hvem skal implementere testene? (Kan der endda være en gren mellem begge?)
• Hvem er ansvarlig for at tilbyde automatiseringsingeniørerne de forretningsstrømme / testcases / forretningslogik, der formodes at være automatisk?
• Er der defineret en POC-fase (Proof of concept) for at bestemme fremtidige mål?

Det er bare nogle af spørgsmålene i en nøddeskal, og hvad du skal tage ud af dette er det

En passende værktøjsmulighed, overlegen planlægning / design vil sandsynligvis producere forskellen mellem fiasko og succes.

Automatisering af alt : Et vigtigt punkt at bemærke er, at ikke hvad der kan eller skal være automatisk. Til tider opfattelse eller forkerte ledelsesbeslutninger automatiserer vi alt, hvad der kommer til testers hoved eller konverterer blindtestsager blindt til scripts. Først og fremmest er ikke alle evalueringer passende at automatisere. For det andet er selve testcases ikke acceptabelt for jobbet. Dette ender i en uvedligeholdelig flok automatiske tests, der er umulige at holde, og desværre vil de fleste lejligheder føre til at markere meget af vores skriftlige arbejde. Der er ingen ekstra værdi i automatisering, hvis din virksomhed ikke har midlerne til at opretholde automatiseringsteams titusinder af testforekomster, der lejlighedsvis kontrollerer den samme forretningslogik.

Vi bliver også nødt til at producere en klar plan om, hvad der skal opretholde enhver automatisering. Hvad er inkluderet i vores regression? Hvad er beskrevet som vores sundhed? Hvad er sikkert og pålideligt nok til at komme ind i vores CI / CD-rørledning?

Test-automatisering har brug for solid planlægning, forståelse, engagement og dedikation for at levere passende værdi.

Manglende færdigheder / korrekt instruktion, forkert valg af værktøj, utilstrækkelige ressourcer, mangel på passende forberedelse, urealistisk forventning, alt sammen kan få et projekt til at mislykkes.

Jeg håber, at denne rapport vil have en positiv indvirkning og hjælpe nogle få af jer til at følge en produktiv tankegang.