when opt automation testing
Skal vi overveje automatiseringstest for et projekt? Hvornår skal vi gå til automatiseringstest?
Test udføres for at levere slutkundens leverancer af god kvalitet. Testfase er et af de vigtigste aspekter af STLC .
Enhver virksomhed fokuserer mere på softwaretest, da kvaliteten medfører optimal kundetilfredshed, men mange af dem kæmper stadig med at vælge, hvilken type test de skal udføre, enten med automatiseret test eller manuel test.
Denne artikel hjælper læseren med at forstå, hvad der er automatiseringstest, hvornår man skal gå efter det, og vigtigst af alt, hvornår man ikke skal gå efter det. Lær også optimal udnyttelse af Automatiseringsværktøjer til testning .
Uanset hvilket arbejde der udføres, skal det udføres effektivt og skal også være omkostningseffektivt. Desuden skal det give mening, så kunden føler sig tilfreds med leverancerne.
Hvad du vil lære:
- Softwaretest og omkostningsfordele
- Intelligens bag softwaretest
- Automatisering - er det virkelig vigtigt?
- Hvorfor automatisering?
- Risikofaktor
- Hvornår skal automatisering ikke foretrækkes?
- Omkostning i forhold til ROI til automatisering
- Hvor kan Automation gøre REDUKTION med minimale omkostninger uden omkostninger?
- Konklusion
- Anbefalet læsning
Softwaretest og omkostningsfordele
Softwaretest udføres normalt af en softwaretester. Forskellen mellem en tester og en reel bruger er, at sidstnævnte kun kender en delvis brug af den software, der bruges til deres forretning eller til deres opgaver, og ikke vil kende softwaren fuldstændigt. På den anden side vil en tester være opmærksom på alle de tekniske og funktionelle krav til softwaren. Baseret på kravene fra klienten skal testplaner og testcases udarbejdes.
En testplan er intet andet end en detaljeret plan for, hvordan testprocessen skal udføres. Dette vil have komplette detaljer om antallet af ressourcer og kilder, der er involveret i testning, hvad man skal gøre og hvornår man skal gøre det, hvad der ikke vil blive gjort, og det miljø, hvori det vil blive udført osv.
Testcases skal udarbejdes efter en klar forståelse af det funktionelle og tekniske aspekt af softwaren. Testeren skal have en stor observationsevne og fuldstændig viden om softwaren.
Desuden spiller omkostninger en effektiv rolle her. Kunder foretrækker at acceptere software med maksimal kvalitet til en minimal pris. Når vi går til manuel test, er processen mere kedelig og tidskrævende, da det hele gøres manuelt af en tester.
For eksempel , når vi har brug for 'n' antal testere til udføre regressionstest , det kan tage næsten 50 timer at udføre alle testsagerne. Og baseret på ressourcetilgængeligheden udføres testsagerne. Men med mindre tid til automatiseret test udføres optimal udnyttelse af ressourcer sammen med den maksimale dækning af testsager sammenlignet med manuel test.
Intelligens bag softwaretest
Det er meget vigtigt for enhver organisation at vide, hvornår testprocessen skal startes, og hvornår den skal afsluttes. Vi formodes at vide, hvornår vi skal starte med test, fordi det er nytteløst at starte test, når udviklingsfasen er færdig, og når de krævede kriterier ikke er opfyldt. Det er altid en bedste praksis at starte med testdesignfasen, mens udviklingen er i gang.
Nedenfor er kriterierne for software test ind- og udgang:
Indgangskriterier
Når designdokumentet er underskrevet, skal testplanerne udarbejdes i planlægningsfasen. En testplan spiller en vigtig rolle. Den krævede hardware skal installeres og konfigureres korrekt, og hardwarefunktionaliteten skal kontrolleres. Funktionskravene skal være klare og godkendte. Den udviklede kode skal enhedstestes og underskrives af udviklerne.
Testcases og testdata skal udarbejdes og godkendes. Testdata og anvendelse skal være tilgængelige. Testeren skal have betydelig og tilstrækkelig viden om applikationen. Ressourcerne skal være veluddannede om værktøjer og skal afklares med alle de nødvendige funktioner.
Testeren skal være tilgængelig. Når et af kriterierne ikke opnås, holdes testkriterierne for test tilbage.
[Bemærk: Klik på et hvilket som helst billede for at se et forstørret billede]
Udgangskriterier
Kun når mindst 95% af de obligatoriske testsager er låst med et 'bestået' resultat, kan vi afslutte testfasen for produktet. Det er dog ikke så let at afgøre, hvornår softwaretest kan stoppes, eller om det stadig skal udføres. Og denne slags situation opstår ofte også.
De vigtigste kriterier er angivet nedenfor:
- Når alle bugs er rettet.
- Når deadline er nået.
- Når budgettet er opbrugt eller udtømt.
- Når alle testsagerne er bestået.
- Når aftalen underskrives.
- Når en bestemt procentdel af test er udført.
- Når Alpha og Beta-test ender.
Udgangskriterierne kan udledes udelukkende baseret på faktorer som risiko, omkostninger osv. Når testning af det vigtigste funktionelle krav er opnået, stoppes testen normalt, og de ser aldrig efter mindre fejl, hvilket vil skabe problemer i senere perioder.
Eksempel: Software ABC er i en designfase. Udviklingen og testkonstruktionen sker generelt på samme tid. Efter at designet er frosset, starter udviklingen af softwaren. Afslutning af udviklingen af softwaren, som aftalt, angiver adgangskriterierne. Leveringer her er fra udviklingsteamet. Det inkluderer udgivelsesnotater og kendte problemer.
Efter få gentagelser af test, når ingen større / blocker / show-propper afventer opløsning, og 95% af testene har resulteret i et gennemslag, kaldes det som exitkriterier.
Automatisering - er det virkelig vigtigt?
Når vi har brug for at beslutte, om vi har brug for det Automatiseret testteknik eller ej, spørgsmålet om tilgængelige ressourcer opstår her. Årsagerne til, at vi har brug for at automatisere, er at kontrollere, om datastrømmen og den udviklede funktionalitet fungerer som forventet uden manuel indgriben eller ej. Det bruges hovedsageligt på steder, hvor softwaren vil have ændringer i form af flere udgivelser / cyklusser osv.
hvordan man åbner binære filer i Windows
I slutningen af udviklingen af hver cyklus udføres testningen af den aktuelt tilføjede funktionalitet. Derudover testes den gamle funktionalitet for at sikre, at de gamle funktioner ikke brydes. Dette er den største del, der har plads til automatisering.
Når man verificerer de kodedrevne logik og GUI-kravene, kan man vælge automatiseret test, forudsat at risikofaktoren er høj.
Eksempel: For softwaren ABC er der hyppige opgraderinger, opdateringer søges af klienten og leveres af udviklerne. Derfor foretages regression for softwaren, som allerede er live og kører i produktion, som en del af testningen. Uanset antallet af udgivelser, opgraderinger og opdateringer er den aktuelle version gyldig.
Sig, at der er 10 dages manuel indsats for dækning af regressionstest, og så skal der tages den største omhu for at automatisere dem. Det kan spare mindst 60% indsats og 10 * 8 = 80 timers manuelt arbejde.
Automatisering kan kun gennemføres 80/24 = 3,33 dage. Dette sparer ca. 6,67.
Hvorfor automatisering?
Automatisering kan kun vælges, når:
- Applikationen har et meget stort område med en høj grad af investeringsindsats i regression.
- Optimering af omkostninger opstod på grund af manuelle fejl.
- Softwaren har flere versioner og udgivelser.
- Det er omkostningseffektivt i det lange løb.
- Risikofaktoren er højere for et bredere omfang af testudførelse.
- Omkostningstal og matematiske beregninger er inkluderet i softwarefunktionaliteten.
- Der er en større stigning i udførelsestempo, effektivitet sammen med softwarekvaliteten.
- Der er en mindre drejningstid, selv til softwaretest med høj risiko.
Risikofaktor
Risikofaktor bliver overvejende almindelig i virksomheden, hvor der er mange afhængigheder af tidsfaktoren. Den software, der fungerer baseret på transaktionssystemerne, og som fungerer på tværs af flere applikationer, kræver, at softwaren fungerer ideelt i henhold til softwaredesignet. I dette tilfælde er der mange risici forbundet med at få den korrekte funktionelle adfærd registreret.
Her vil automatisering være meget nyttigt med at udføre de funktionelle transaktioner i et bedre tempo i henhold til softwaremekanismen.
For eksempel i tilfælde af en Forex-markedsindikator er tidsfaktoren meget vigtig og kritisk. Ændringerne i lagre og råvarer sker med hensyn til tid, undertiden mindre end sekunder. Her kan automatisering hjælpe med at teste sådan software med høj risiko.
Eksempel: Software ABC har flere opdateringer og opgraderinger. For at spare manuel indsats og reducere drejningstiden til testfasen kan basisversionen eller de gamle funktioner automatiseres. Dette kan kun blive gyldigt, når basisfunktionaliteterne forbliver uændrede.
Fordelen ved automatisering er, at de kan køres uden manuel indgriben. Selv dette kan udføres parallelt med test af nyere funktionalitet. Derfor sparer automatisering meget kræfter og meget tid.
Hvornår skal automatisering ikke foretrækkes?
Der er et spørgsmål blandt flere organisationer, som er - Hvorfor 100% automatisering er ikke mulig?
Svaret fra eksperter er LADE VÆRE MED fordi dygtige brugere skal udføre automatiseret test, og de skal også være veluddannede. Automatisering kan ikke udføres i den indledende fase af kriterierne, og kravene til applikationerne er ikke klare.
Normalt foretrækkes automatisering fra den anden iteration af enhver softwareudgivelse. Brugergrænsefladen kan ændres, hvilket er dyrere, og scriptvedligeholdelsen er også dyrere. Når de krævede omkostninger til automatiseringsværktøjet overstiger projektets budget, kan vi sige nej.
Eksempel: Software XYZ er en type e-handelswebsted, hvor kundekravene ikke er frossne og ændrer sig, når klienterne kræver det.
I dette tilfælde kan automatisering ikke hjælpe regressionen. Dette skyldes, at de gamle funktionaliteter, der ikke er gyldige, ikke bør testes, og derfor skal de udføres manuelt. For eksempel skal en klient have alle lister i basissoftwaren, der skal ændres som rullelister.
Omkostning i forhold til ROI til automatisering
ROI er meget lavt, når vi begynder med automatisering, fordi automatisering er dyr for første gang. ROI fortsætter med at stige, da den manuelle indsats for at teste softwaren sænkes fra gentagelserne af den anden udgivelse. Vi skal være opmærksomme på det forventede resultat af enhver testtilfælde inden Automation.
Overvej designet af testsagerne vigtigere, når du vælger Automation og ethvert værktøj for at sikre, at det ikke øger omkostningerne.
Hvor kan Automation gøre REDUKTION med minimale omkostninger uden omkostninger?
Selv automatiseringsomkostninger, fordi det nødvendige værktøj til test skal købes. Ressourcerne skal trænes med det særlige værktøj. Det valgte værktøj skal være muligt for at teste alle områder af softwaren.
Så værktøjsvalget skal udføres omhyggeligt af eksperterne inden for automatiseringstest.
Eksempel: Overvej produkt XYZ, der beskæftiger sig med forsikring. For at reducere omkostningsfaktoren brugte virksomheden kun manuel testning, men når det kommer til forsikring, er risikofaktoren høj og kan koste virksomheden penge, når en af præmieberegningerne går galt. Hele tabet er enten for ledelsen eller til slutbrugeren. Slutbrugeren bærer ikke tab, mens virksomheden skal.
Når det beregnede præmiebeløb ikke stemmer overens med den oprindelige præmie (dvs. når der er en forskel i front- og back-end-præmieberegningen, opstår der et stort problem mellem kunden og produktsælgeren. Det kan også indeholde mange moduler som biler, hjemmet og andre.
Når noget går galt, er det et fuldstændigt tab. Forskellen i beregningen kan give mening for testeren og kan rejse fejl. I dette projekt er manuel test kan udføres for den grundlæggende brugergrænseflade, såsom verificering af TIN-nummeret, det sociale ID og anden information relateret til brugerporteføljen og kan derfor testes manuelt, hvor risikofaktoren er lav. M eller virksomheden ville tjene penge, jo mere foretrækker de automatisering til at teste deres software.
Konklusion
Både automatisering og manuel test har også fordele og ulemper. Først når vi er klare over begreberne og kravene, kan vi vælge, hvilken type test vi skal udføre.
Intet projekt kan testes med manuel test eller automatiseret test alene. Det afhænger af designet, platformen og teknologien, som softwaren er udviklet med. Så når man træffer en beslutning, skal man være forsigtig med at vælge testmetoden og bruge råd fra eksperter.
I ovenstående artikel har vi måske gået glip af få faktorer, del venligst de faktorer, som du synes er vigtige, når du vælger automatisering eller endda værktøjer til automatisering.
I mellemtiden er du velkommen til at dele dine kommentarer / forslag til denne artikel.
Anbefalet læsning
- Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
- Manuel og automatiseringstestudfordringer
- Top 10+ bedste softwaretestbøger (manuel og automatiseringstestbøger)
- Softwaretest QA Assistant Job
- 11 bedste automatiseringsværktøjer til test af Android-applikationer (Android App-testværktøjer)
- Er du en manuel eller automatiseringstestekspert? Arbejd deltid for os!
- Software Testing Course: Hvilket Software Testing Institute skal jeg tilmelde mig?
- Valg af softwaretest som din karriere