Hvad er acceptantestning (En komplet guide)

what is acceptance testing

Introduktion til acceptprøvning (del I):

I denne tutorial-serie lærer du:

1. Hvad er acceptstest
2. Accept test og testplan
3. Status for accept af test og oversigtsrapporter
4. Hvad er UAT (User Acceptance Testing)

Er du færdig med systemtest? Er de fleste af dine bugs rettet? Er fejlene bekræftet og lukket? Så hvad er det næste?

Næste på listen kommer Acceptance Testing, som er den sidste fase af softwaretestprocessen . Dette er den fase, hvor kunden beslutter GO / No-GO for produktet og skal følges obligatorisk, før produktet frigives til markedet. Fælles indsats fra udviklingen og testteamet tildeles af kunden ved enten at acceptere eller afvise det udviklede produkt.

Denne unikke tutorial om Acceptance Testing giver dig et komplet overblik over betydningen, typerne, anvendelserne og forskellige andre faktorer, der er involveret i Acceptance Test på en enkel og nem måde for din bedre forståelse.

Hvad du vil lære:

• Hvad er accepttest?
• Hvorfor accepttest?
• Typer
  • # 1) Test af brugeraccept (UAT)
  • # 2) Test af forretningsaccept (BAT)
  • # 3) Kontrakttest (CAT)
  • # 4) Forskrifter / Test af overholdelse af accept (RAT)
  • # 5) Operativ accepttest (OAT)
  • # 6) Alpha Testing
  • # 7) Betatestning / feltprøvning
• Hvem laver test af accept?
• Kvaliteter af accepttestere
• Brug
• Forskelle mellem systemtest, accepttest og brugertesttest
• Accept test
• Accept test test seng
• Indgangs- og udgangskriterier for AT
  • Indgangskriterier
  • Udgangskriterier
• Acceptantestningsproces
• Succesfaktorer for denne test
• Konklusion
• Anbefalet læsning

Hvad er accepttest?

En gang Systemtestproces er afsluttet af testteamet og er underskrevet, hele produktet / applikationen overdrages til kunden / få brugere af kunder / begge for at teste for dets accept, dvs. produkt / applikation skal være fejlfri i at imødekomme både kritiske og store forretningskrav. End-to-end forretningsstrømme verificeres ligeledes som i realtidsscenarie.

Det produktionslignende miljø vil være testmiljøet for accept af testning (normalt betegnet som Staging, Pre-Prod, Fail-Over, UAT-miljø).

Dette er en black-box testteknik hvor kun funktionaliteten er verificeret for at sikre, at produktet opfylder de specificerede acceptkriterier (intet behov for design / implementeringsviden).

Hvorfor accepttest?

Selvom systemtest er afsluttet med succes, kræves accepttesten af ​​kunden. Test udført her er gentagne, da de ville være blevet dækket af systemtest.

Så hvorfor udføres denne test af kunder?

Dette er fordi:

• For at få tillid til det produkt, der bliver frigivet på markedet.
• For at sikre, at produktet fungerer som det skal.
• For at sikre, at produktet matcher de nuværende markedsstandarder og er konkurrencedygtigt nok med de andre lignende produkter på markedet.

Typer

Der er flere typer af denne test.

Få af dem er anført nedenfor:

# 1) Test af brugeraccept (UAT)

UAT skal vurdere, om produktet fungerer for brugeren, korrekt til brugen. Specifikke krav, som ofte bruges af slutbrugerne, vælges primært til testformålet. Dette betegnes også som test af slutbruger.

Udtrykket 'bruger' betyder her de slutbrugere, som produktet / applikationen er beregnet til, og derfor udføres test ud fra slutbrugernes perspektiv og fra deres synspunkt.

=> Også Læs: Hvad er UAT (User Acceptance Testing)?

# 2) Test af forretningsaccept (BAT)

Dette er for at vurdere, om produktet opfylder forretningsmålene og formålene eller ej.

BAT fokuserer primært på forretningsfordele (økonomi), som er ret udfordrende på grund af de skiftende markedsforhold / fremskridt teknologier, så den nuværende implementering muligvis skal gennemgå ændringer, der resulterer i ekstra budgetter.

websteder for at downloade videoer fra youtube

Selv produktet, der overholder de tekniske krav, kan mislykkes BAT på grund af disse grunde.

# 3) Kontrakttest (CAT)

Dette er en kontrakt, der specificerer, at når produktet er gået i live inden for en forudbestemt periode, skal acceptstesten udføres, og den skal bestå alle tilfælde af acceptanvendelse.

Kontrakt, der er underskrevet her, betegnes som serviceniveauaftale (SLA), som inkluderer de vilkår, hvor betalingen kun foretages, hvis produkttjenesterne er i overensstemmelse med alle kravene, hvilket betyder, at kontrakten er opfyldt.

Nogle gange kan denne kontrakt ske, inden produktet tages i brug. Uanset hvad må en kontrakt være veldefineret med hensyn til testperioden, testområder, forhold på problemer, der opstår på senere stadier, betalinger osv.

# 4) Bestemmelser /OverholdelseAcceptantestning (RAT)

Dette er for at vurdere, om produktet overtræder de regler og forskrifter, der er defineret af regeringen i det land, hvor det frigives. Dette kan være utilsigtet, men vil påvirke virksomheden negativt.

Normalt skal det udviklede produkt / applikation, der er beregnet til at blive frigivet over hele verden, gennemgå RAT, da forskellige lande / regioner har forskellige regler og forskrifter defineret af dets styrende organer.

Hvis nogen af ​​reglerne og forskrifterne overtrædes for et hvilket som helst land, har det pågældende land eller den specifikke region i det pågældende land ikke tilladelse til at bruge produktet og betragtes som et fiasko. Leverandører af produktet er direkte ansvarlige, hvis produktet frigives, selvom der er en overtrædelse.

# 5) Operativ accepttest (OAT)

Dette er for at vurdere produktets operationelle beredskab og er en ikke-funktionel test. Det inkluderer hovedsagelig test af gendannelse, kompatibilitet, vedligeholdelse, tilgængelighed af teknisk support, pålidelighed, fail-over, lokalisering osv.

OAT sikrer primært produktets stabilitet, inden det frigives til produktionen.

# 6) Alpha Testing

Dette er for at vurdere produktet i udviklings- / testmiljøet af et specialiseret testerteam, der normalt kaldes alfatestere. Her er testernes feedback, forslag med til at forbedre produktforbruget og også til at rette visse fejl.

Her sker testning på en kontrolleret måde.

=> Læs også: Hvad er Alpha Testing?

# 7) Betatestning / feltprøvning

Dette er for at vurdere produktet ved at udsætte det for de virkelige slutbrugere, normalt kaldet betatestere / beta-brugere, i deres miljø. Der indsamles løbende feedback fra brugerne, og problemerne løses. Dette hjælper også med at forbedre / forbedre produktet for at give en rig brugeroplevelse.

Test sker på en ukontrolleret måde, hvilket betyder, at en bruger ikke har nogen begrænsninger for den måde, produktet bruges på.

=> Læs også: Hvad er betatestning?

Alle disse typer har et fælles mål:

• Sørg for at vinde / berige tillid til produktet.
• Sørg for, at produktet er klar til brug af de rigtige brugere.

Hvem laver test af accept?

For Alpha-typen udfører kun medlemmerne af organisationen (som har udviklet produktet) testen. Disse medlemmer er ikke direkte en del af projektet (projektledere / leads, udviklere, testere). Ledelse, salg, supportteam udfører normalt testen og giver feedback i overensstemmelse hermed.

Bortset fra Alpha-typen udføres alle andre accepttyper generelt af forskellige interessenter. Ligesom kunder, kundens kunder, specialiserede testere fra organisationen (ikke altid).

Det er også godt at involvere forretningsanalytikere og fagmaterialeekspertise, mens du udfører denne test baseret på dens type.

Kvaliteter af accepttestere

Testere med nedenstående kvaliteter er kvalificeret som accepttestere:

• Evne til at tænke logisk og analytisk.
• God domæne viden.
• Kunne undersøge de konkurrencedygtige produkter på markedet og analysere det samme i det udviklede produkt.
• At have slutbrugeropfattelse under test.
• Forstå forretningsbehov for hvert krav og test i overensstemmelse hermed.

Virkningen af ​​problemer fundet under denne test

Eventuelle problemer, der opstår i Acceptance-testfasen, bør betragtes som en høj prioritet og løses med det samme. Dette kræver også, at der udføres rodårsagsanalyse på hvert eneste problem, der findes.

Testteamet spiller en vigtig rolle i at levere RCA'er til acceptproblemer. Disse hjælper også med at bestemme, hvor effektivt test udføres.

Gyldige problemer i acceptstest vil også ramme både test- og udviklingsteamets indsats med hensyn til indtryk, ratings, kundeundersøgelser osv. Nogle gange, hvis der findes nogen uvidenhed fra testteamet om valideringer, fører det også til optrapninger.

Brug

Denne test er nyttig fra flere aspekter.

Få af dem inkluderer:

• At finde ud af de problemer, der er gået glip af under den funktionelle testfase.
• Hvor godt produktet er udviklet.
• Et produkt er, hvad kunderne faktisk har brug for.
• Feedback / undersøgelser udført hjælper med at forbedre produktets ydeevne og brugeroplevelse.
• Forbedre processen efterfulgt af at have RCA'er som input.
• Minimer eller fjern de problemer, der opstår som følge af Produktionsproduktet.

Forskelle mellem systemtest, accepttest og brugertesttest

Nedenfor er de primære forskelle mellem disse 3 typer accepttest.

Accept test

I lighed med produkttestsager har vi acceptstest. Acceptstest stammer fra brugerhistoriernes acceptkriterier. Dette er normalt de scenarier, der er skrevet på højt niveau, der beskriver, hvad produktet skal gøre under forskellige forhold.

Det giver ikke et klart billede af, hvordan man udfører tests, som i testsager. Acceptprøver er skrevet af testere, der har et fuldstændigt greb om produktet, normalt fagemneekspertise. Alle de skriftlige prøver gennemgås af en kunde og / eller forretningsanalytikere.

Disse test udføres under acceptstest. Sammen med acceptstest skal der udarbejdes et detaljeret dokument om eventuelle opsætninger, der skal udføres. Det skal indeholde detaljer om hvert minut med korrekte skærmbilleder, opsætningsværdier, betingelser osv.

Accept test test seng

Test seng til denne test svarer til en almindelig test seng, men er en separat. Platform med al den nødvendige hardware, software, driftsprodukter, netværksopsætning og konfigurationer, serveropsætning og konfigurationer, databaseopsætning og konfigurationer, licenser, plug-ins osv. Skal konfigureres meget ens produktionsmiljøet.

Acceptance test bed er en platform / miljø, hvor de designede accept tests vil blive udført. Inden man overleverer accepttestmiljøet til kunden, er det en god praksis at kontrollere, om der er miljøproblemer og produktets stabilitet.

Hvis der ikke er indstillet et separat miljø til accepttest, kan et regelmæssigt testmiljø bruges til dette formål. Men her vil det være rodet, da testdata fra regelmæssig systemtest, og realtidsdata fra accepttest opretholdes i et enkelt miljø.

Acceptance testbed er normalt indstillet på kundesiden (dvs. i laboratoriet) og har begrænset adgang til udviklings- og testteamet.

Hold vil være forpligtet til at få adgang til dette miljø via VM'er / eller specifikt designede URL'er ved hjælp af specielle adgangsoplysninger, og al adgang til dette spores. Intet i dette miljø skal tilføjes / ændres / slettes uden kundens tilladelse, og de skal underrettes om de ændringer, der foretages.

Indgangs- og udgangskriterier for AT

Ligesom enhver anden fase i STLC har accepttest et sæt indgangs- og udgangskriterier, der skal defineres veldefineret i Acceptance Test Plan (som er dækket i den senere del af denne tutorial).

Dette er den fase, der starter lige efter systemtest og slutter inden produktionsstart. Så udgangskriterierne for systemtest bliver en del af adgangskriterierne for AT. Tilsvarende bliver udgangskriterierne for AT en del af indgangskriterierne for produktionsstart.

Indgangskriterier

Nedenfor er de betingelser, der skal opfyldes inden start:

• Forretningskrav skal være klare og tilgængelige.
• System- og regressionstestfasen skal være afsluttet.
• Alle de kritiske, større og normale bugs skal rettes og lukkes (Mindre bugs accepteres hovedsageligt er kosmetiske bugs, der ikke forstyrrer brugen af ​​produktet).
• Listen over kendte problemer skal udarbejdes og deles med interessenterne.
• Acceptance Test Bed skal opstilles, og der skal foretages kontrol på højt niveau uden miljøproblemer.
• Systemtestfasen skal underskrives, så produktet kan flytte til AT-fasen (normalt udført via e-mail-kommunikation).

Udgangskriterier

Der er visse betingelser, der skal opfyldes af AT for at lade produktet gå til en produktionsstart.

De er som følger:

• Acceptanstests skal udføres, og alle testene skal bestå.
• Ingen kritiske / større fejl er åben. Alle fejl skal rettes og bekræftes straks.
• AT skal underskrives af alle inkluderede interessenter med Go / No-Go Beslutning om produktet.

Acceptantestningsproces

I V-Model , AT-fasen er parallel med kravfasen.

Den faktiske AT-proces går som vist nedenfor:

Analyse af forretningskrav

Forretningskrav analyseres ved at henvise til alle tilgængelige dokumenter i projektet.

Nogle af dem er:

• Specifikationer for systemkrav
• Dokument om forretningskrav
• Brug sager
• Workflow diagrammer
• Designet datamatrix

Testplan for designaccept

Der er visse ting, der skal dokumenteres i Acceptance Test Plan.

Lad os se på nogle af dem:

• Acceptance Testing strategi og tilgang.
• Indgangs- og udgangskriterier skal være veldefinerede.
• Omfanget af AT skal være godt nævnt, og det skal kun dække forretningskravene.
• Acceptetest design design tilgang skal være detaljeret, så enhver, der skriver tests let kan forstå den måde, hvorpå det skal skrives.
• Opsætning af testbed, faktisk testplan / tidslinjer skal nævnes.
• Da test udføres af forskellige interessenter, bør detaljer om loggingfejl nævnes, da interessenterne muligvis ikke er opmærksomme på den fulgte procedure.

Design og gennemgangstest

Acceptprøver skal skrives på scenarieniveau, hvor der nævnes, hvad der skal gøres (ikke detaljeret for at inkludere, hvordan man gør). Disse skal kun skrives for de identificerede områder for forretningskrav, og hver test skal kortlægges til dens referencekrav.

Alle skriftlige acceptstest skal gennemgås for at opnå høj dækning af forretningskrav.

Dette er for at sikre, at andre tests bortset fra det nævnte omfang ikke er involveret, så test ligger inden for de planlagte tidslinjer.

Acceptance Test Bed Opsætning

Testbed skal opstilles svarende til et produktionsmiljø. Der kræves meget høje niveaukontroller for at bekræfte miljøstabilitet og brug. Del legitimationsoplysningerne for kun at bruge miljøet med en interessent, der udfører denne test.

sql database interview spørgsmål og svar

Opsætning af accepttestdata

Produktionsdata skal udarbejdes / udfyldes som testdata i systemerne. Der skal også være et detaljeret dokument på en sådan måde, at dataene skal bruges til testning.

Har ikke testdata som TestName1, TestCity1 osv. I stedet for Albert, Mexico osv. Dette giver en rig oplevelse af realtidsdata, og test vil være up-to-point.

Acceptance Test Execution

Designede accepttest skal udføres på miljøet på dette trin. Ideelt set skulle alle testene bestå ved selve første forsøg. Der bør ikke være nogen funktionelle fejl, der opstår ved accepttest, hvis nogen, så skal de rapporteres med en høj prioritet, der skal løses.

Igen skal fejl, der er rettet, verificeres og lukkes som en opgave med høj prioritet. Testudførelsesrapporten skal deles dagligt.

Fejl, der er logget ind i denne fase, skal diskuteres i et bug-triage-møde og skal gennemgå en procedure til rodårsaganalyse. Dette er det eneste punkt, hvor acceptstest vurderer, om alle forretningskrav faktisk er opfyldt af produktet eller ej.

Forretningsbeslutning

Der kommer en Go / No-Go beslutning om, at produktet skal lanceres i produktion. Gå beslutningen vil tage produktet forud for frigivelse på markedet. Nej beslutning markerer produktet som fejl.

Få faktorer i No-Go-beslutningen:

• Produktets dårlige kvalitet.
• For mange åbne funktionelle bugs.
• Afvigelse fra forretningskrav.
• Ikke op til markedsstandarderne og behovsforbedringer for at matche de nuværende markedsstandarder.

Succesfaktorer for denne test

Når denne test er planlagt, skal du udarbejde en tjekliste, der øger succesraten for den. Der er nogle handlingspunkter, der skal følges, inden acceptstesten starter.

De er:

• Har et veldefineret anvendelsesområde og sørg for, at der er et forretningsbehov for det anvendte omfang til denne test.
• Udfør accepttest i selve systemtestfasen mindst en gang.
• Udfør omfattende ad hoc-test for hvert af accept-testscenarierne.

Konklusion

I en nøddeskal hjælper accepttest med at finde ud af effektiviteten af ​​udviklings- og testteams.

Der er flere værktøjer til at udføre denne aktivitet, men det foretrækkes normalt at blive udført manuelt, da der er en involvering af de virkelige brugere og forskellige interessenter, der ikke har en teknisk baggrund, og det er muligvis ikke muligt for dem.

Hvad er det næste?

I vores næste vejledning vil vi svæve over nedenstående emner:

• Eksempler på kriterier for accepttest.
• Sådan skriver du en accepttestplan.
• En passende skabelon til skrivning af accepttest.
• Hvordan man skriver Acceptance tests med eksempler.
• Identificering af acceptscenarier.
• Accept testrapporter.
• Accept test i Agile og test-drevet udvikling.

NÆSTE tutorial # 2: Acceptance Test Plan

Har du udført Acceptance Testing? Vi ville være glade for at høre dine oplevelser !!

Anbefalet læsning

• Alpha Testing og Beta Testing (En komplet guide)
• Hvad er test af brugeraccept (UAT): En komplet guide
• Build Verification Testing (BVT Testing) Komplet guide
• Funktionel testning mod ikke-funktionel testning
• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Typer af softwaretest: Forskellige testtyper med detaljer
• ETL Testing Data Warehouse Testing Tutorial (En komplet guide)
• Vejledning til test af webapplikationssikkerhed