what is acceptance testing
Introduksjon til akseptattesting (del I):
I denne opplæringsserien lærer du:
- Hva er akseptatesting
- Akseptstester og testplan
- Godkjennelsestester og sammendragsrapporter
- Hva er UTA (User Acceptance Testing)
Er du ferdig med systemtesting? Er de fleste av feilene dine løst? Er feilene bekreftet og lukket? Så, hva er det neste?
Neste i listen kommer Acceptance Testing, som er den siste fasen av Software Testing Process . Dette er fasen der kunden bestemmer GO / No-GO for produktet og må følges obligatorisk før produktet slippes ut på markedet. Felles innsats fra utviklingen og testteamet vil bli tildelt av kunden ved enten å godta eller avvise det utviklede produktet.
Denne unike opplæringen om Acceptance Testing vil gi deg en fullstendig oversikt over betydningen, typer, bruksområder og forskjellige andre faktorer som er involvert i Acceptance Test på en enkel og enkel måte for bedre forståelse.
Hva du vil lære:
- Hva er akseptattesting?
- Hvorfor aksepttester?
- Typer
- Hvem gjør akseptattesting?
- Kvaliteter av akseptantestere
- Bruk
- Forskjeller mellom systemtesting, godkjenningstesting og brukertestetesting
- Aksept tester
- Akseptprøveseng
- Inn- og utgangskriterier for AT
- Akseptprøvingsprosess
- Suksessfaktorer for denne testen
- Konklusjon
- Anbefalt lesing
Hva er akseptattesting?
Først når Systemtestprosess er fullført av testteamet og er signert av, blir hele produktet / applikasjonen overlevert til kunden / få brukere av kunder / begge deler, for å teste for dets akseptabilitet, dvs. at produktet / applikasjonen skal være feilfri i møte med både kritiske og store forretningskrav. Dessuten er end-to-end forretningsstrømmer verifisert som i sanntidsscenario.
Det produksjonslignende miljøet vil være testmiljøet for å akseptere testing (vanligvis betegnet som Staging, Pre-Prod, Fail-Over, UAT-miljø).
Dette er en black-box testing teknikk der bare funksjonaliteten er bekreftet for å sikre at produktet oppfyller de angitte akseptkriteriene (ikke behov for kunnskap om design / implementering).
Hvorfor aksepttester?
Selv om systemtesting er fullført, kreves det aksept av testen. Tester som er utført her er gjentatte, da de ville blitt dekket i systemtesting.
Så hvorfor utføres denne testen av kunder?
Dette er fordi:
- For å få tillit til produktet som slippes ut på markedet.
- For å sikre at produktet fungerer slik det må.
- For å sikre at produktet samsvarer med gjeldende markedsstandarder og er konkurransedyktig nok med de andre lignende produktene i markedet.
Typer
Det er flere typer av denne testingen.
Få av dem er oppført nedenfor:
# 1) Testing av brukeraksept (UAT)
UAT skal vurdere om produktet fungerer for brukeren, riktig for bruk. Spesifikke krav som ofte brukes av sluttbrukerne blir først og fremst valgt for testformålet. Dette blir også betegnet som sluttbrukertesting.
Uttrykket 'bruker' betyr her sluttbrukerne som produktet / applikasjonen er beregnet på, og testingen utføres derfor fra sluttbrukernes perspektiv og fra deres synspunkt.
=> Også Lese: Hva er UAT (User Acceptance Testing)?
Nr. 2) Testing av virksomhetens aksept (BAT)
Dette er for å vurdere om produktet oppfyller forretningsmålene og formålene eller ikke.
BAT fokuserer hovedsakelig på forretningsfordeler (økonomi) som er ganske utfordrende på grunn av endrede markedsforhold / fremskridende teknologier, slik at den nåværende implementeringen kan måtte gjennomgå endringer som resulterer i ekstra budsjetter.
verktøy for åpen kildetjeneste
Selv produktet som oppfyller de tekniske kravene kan mislykkes BAT på grunn av disse årsakene.
# 3) Testing av kontrakter (CAT)
Dette er en kontrakt som spesifiserer at når produktet går live, innen en forutbestemt periode, må akseptattesten utføres, og den skal bestå alle tilfeller for bruk av aksept.
Kontrakt som er signert her betegnes som servicenivåavtale (SLA), som inkluderer vilkårene der betalingen bare skal skje hvis produkttjenestene er i tråd med alle kravene, noe som betyr at kontrakten er oppfylt.
Noen ganger kan denne kontrakten skje før produktet settes i drift. Uansett må en kontrakt være godt definert når det gjelder testperioden, testområder, forhold på problemer som oppstår på senere stadier, betalinger osv.
# 4) Forskrifter /SamsvarAkseptprøving (RAT)
Dette er for å vurdere om produktet bryter med regler og forskrifter som er definert av myndighetene i landet der det blir utgitt. Dette kan være utilsiktet, men vil påvirke virksomheten negativt.
Vanligvis må det utviklede produktet / applikasjonen som er ment å bli utgitt over hele verden, gjennomgå RAT, ettersom forskjellige land / regioner har forskjellige regler og forskrifter definert av dets styrende organer.
Hvis noen av reglene og regelverket er brutt for et hvilket som helst land, vil ikke det landet eller den spesifikke regionen i det landet få lov til å bruke produktet og betraktes som et svikt. Leverandører av produktet vil være direkte ansvarlige hvis produktet frigjøres, selv om det er et brudd.
# 5) Driftstest (OAT)
Dette er for å vurdere produktets driftsberedskap og er en ikke-funksjonell testing. Det inkluderer hovedsakelig testing av gjenoppretting, kompatibilitet, vedlikehold, teknisk tilgjengelighets tilgjengelighet, pålitelighet, fail-over, lokalisering etc.
OAT forsikrer hovedsakelig produktets stabilitet før den slippes til produksjonen.
# 6) Alpha Testing
Dette er for å vurdere produktet i utviklings- / testmiljøet av et spesialisert testerteam som vanligvis kalles alfatestere. Her gir testerne tilbakemeldinger, forslag som hjelper til med å forbedre produktbruken og også til å fikse visse feil.
Her skjer testing på en kontrollert måte.
=> Les også: Hva er Alpha Testing?
# 7) Betatesting / feltprøving
Dette er for å vurdere produktet ved å eksponere det for de virkelige sluttbrukerne, vanligvis kalt beta-testere / beta-brukere, i deres miljø. Kontinuerlig tilbakemelding fra brukerne samles inn og problemene løses. Dette hjelper også med å forbedre / forbedre produktet for å gi en rik brukeropplevelse.
Testing skjer på en ukontrollert måte, noe som betyr at en bruker ikke har noen begrensninger på måten produktet blir brukt på.
=> Les også: Hva er betatesting?
Alle disse typene har et felles mål:
- Sørg for å få / berike tillit til produktet.
- Sørg for at produktet er klart til bruk av de virkelige brukerne.
Hvem gjør akseptattesting?
For Alpha-typen er det bare medlemmene i organisasjonen (som har utviklet produktet) som utfører testingen. Disse medlemmene er ikke direkte en del av prosjektet (prosjektledere / potensielle kunder, utviklere, testere). Ledelse, salg, supportteam utfører vanligvis testingen og gir tilbakemelding deretter.
Bortsett fra Alpha-typen, blir alle andre aksepttyper generelt utført av forskjellige interessenter. Som kunder, kundens kunder, spesialiserte testere fra organisasjonen (ikke alltid).
Det er også bra å involvere forretningsanalytikere og fagemneekspertise mens du utfører denne testen basert på typen.
Kvaliteter av akseptantestere
Testere med kvaliteter nedenfor er kvalifisert som akseptatestere:
- Evne til å tenke logisk og analytisk.
- God domenekunnskap.
- Kunne studere de konkurransedyktige produktene i markedet og analysere det samme i det utviklede produktet.
- Å ha sluttbrukeroppfatning under testing.
- Forstå forretningsbehovet for hvert krav og test deretter.
Virkningen av problemer som ble funnet under denne testingen
Eventuelle problemer som oppstår i godkjenningstestfasen bør betraktes som en høy prioritet og løses umiddelbart. Dette krever også at årsaksanalyse skal utføres på hvert eneste problem som blir funnet.
Testteamet spiller en viktig rolle i å levere RCA for akseptproblemer. Disse hjelper også til å bestemme hvor effektivt testing utføres.
Også gyldige problemer i akseptanstesten vil treffe både testingen og utviklingsteamets innsats når det gjelder inntrykk, rangeringer, kundeundersøkelser, etc. Noen ganger, hvis det blir funnet uvitenhet fra testteamet om validering, fører det til eskaleringer også.
Bruk
Denne testen er nyttig fra flere aspekter.
Få av disse inkluderer:
- For å finne ut hvilke problemer som ble savnet i løpet av funksjonstestingsfasen.
- Hvor godt produktet er utviklet.
- Et produkt er det kundene faktisk trenger.
- Tilbakemeldinger / undersøkelser gjennomført hjelper til med å forbedre produktytelsen og brukeropplevelsen.
- Forbedre prosessen etterfulgt av å ha RCA som input.
- Minimer eller eliminer problemene som oppstår fra produksjonsproduktet.
Forskjeller mellom systemtesting, godkjenningstesting og brukertestetesting
Nedenfor er de viktigste forskjellene mellom disse 3 typene aksepttester.
| Systemtesting | Akseptprøving | Testing av brukeraksept |
|---|---|---|
| Positive og negative tester utføres | Vanligvis utføres positive tester | Bare positive tester utføres |
| Det utføres en helhetlig testing for å verifisere om produktet oppfyller alle spesifiserte krav | Testing utføres for å verifisere om produktet oppfyller kundens krav for aksept | Testing utføres for å verifisere om sluttbrukernes krav er oppfylt for aksept |
| Et produkt blir testet som helhet og fokuserer bare på funksjonelle og ikke-funksjonelle behov | Produktet er testet for forretningsbehov - aksept av brukere, forretningsmål, regler og forskrifter, operasjoner osv. | Produktet er bare testet for aksept av brukere |
| Testteam utfører systemtesting | Kunden, kundenes kunder, tester (sjelden), ledelse, salg, supportteam utfører godkjenningstesting avhengig av type test som er utført | Kunden, kundenes kunde, testere utfører (sjelden) testing av brukeraksept |
| Test tilfeller blir skrevet og utført | Akseptprøver skrives og utføres | Brukeracceptansetester skrives og utføres |
| Kan være funksjonell og ikke-funksjonell | Vanligvis funksjonell, men ikke-funksjonell i tilfelle RAT, OAT, etc. | Bare funksjonell |
| Bare testdata brukes til testing | Sanntidsdata / produksjonsdata brukes til testing | Sanntidsdata / Produksjonsdata brukes til testing |
| Problemer funnet blir betraktet som feil og løst basert på alvorlighetsgrad og prioritet | Problemer funnet merker Produktet som feil, og anses å være løst umiddelbart | Problemer funnet merker Produktet som feil og anses å være løst umiddelbart |
| Kontrollert måte å teste på | Kan kontrolleres eller ukontrollert basert på type testing | Ukontrollert måte å teste på |
| Testing på utviklingsmiljø | Testing på utviklingsmiljø eller pre-produksjonsmiljø eller produksjonsmiljø, basert på type | Testing er alltid i Pre-Production miljø |
| Ingen forutsetninger, men hvis noen kan kommuniseres | Ingen forutsetninger | Ingen forutsetninger |
Aksept tester
I likhet med produkttesttilfeller har vi akseptattester. Akseptprøver er hentet fra brukerhistorieres akseptkriterier. Dette er vanligvis scenariene som er skrevet på høyt nivå med detaljer om hva produktet må gjøre under forskjellige forhold.
Det gir ikke et klart bilde av hvordan man skal utføre tester, som i testsaker. Akseptprøver er skrevet av testere som har et fullstendig grep om produktet, vanligvis fagkompetanse. Alle testene som er skrevet blir gjennomgått av en kunde og / eller forretningsanalytiker.
Disse testene ble utført under akseptanstesten. I tillegg til godkjenningstester må det utarbeides et detaljert dokument om eventuelle oppsett som skal gjøres. Den bør inneholde detaljer om hvert minutt med riktige skjermbilder, oppsettverdier, betingelser osv.
Akseptprøveseng
Test Bed for denne testen ligner på en vanlig test seng, men er en separat. Plattform med all nødvendig maskinvare, programvare, operasjonsprodukter, nettverksoppsett og konfigurasjoner, serveroppsett og konfigurasjoner, databaseoppsett og konfigurasjoner, lisenser, plugin-moduler osv. Må settes opp veldig likt produksjonsmiljøet.
Akseptprøveseng er en plattform / et miljø der de utformede aksepttestene skal utføres. Før du overleverer godkjenningstestmiljøet til kunden, er det en god praksis å sjekke for eventuelle miljøproblemer og stabilitet i produktet.
Hvis det ikke er satt opp et eget miljø for akseptanstesting, kan et vanlig testmiljø brukes til det formålet. Men her vil det være rotete ettersom testdataene fra vanlig systemtesting, og sanntidsdataene fra godkjenningstesting opprettholdes i et enkelt miljø.
Akseptprøveseng er vanligvis satt opp på kundesiden (dvs. i laboratoriet) og vil ha begrenset tilgang til utviklings- og testteamene.
Lag vil være pålagt å få tilgang til dette miljøet via virtuelle maskiner / eller spesielt utformede nettadresser ved hjelp av spesielle tilgangsopplysninger, og all tilgang til dette vil bli sporet. Ingenting i dette miljøet må legges til / endres / slettes uten kundens tillatelse, og de bør varsles om endringene som er gjort.
Inn- og utgangskriterier for AT
Akkurat som enhver annen fase i STLC, har aksepttesting et sett med inn- og utgangskriterier som skal være veldefinerte i Acceptance Test Plan (som er dekket i den senere delen av denne opplæringen).
Dette er fasen som starter rett etter systemtesting og slutter før produksjonslanseringen. Så, Exit-kriteriene for systemtesting blir en del av inngangskriteriene for AT. Tilsvarende blir utgangskriteriene til AT en del av inngangskriteriene for produksjonslanseringen.
Oppføringskriterier
Nedenfor er vilkårene som skal oppfylles før du starter:
- Forretningskrav bør være klare og tilgjengelige.
- Testfasen for system og regresjon bør være fullført.
- Alle de kritiske, store og normale feilene bør fikses og lukkes (Mindre feil som hovedsakelig aksepteres er kosmetiske feil som ikke forstyrrer bruken av produktet).
- Listen over kjente saker bør utarbeides og deles med interessentene.
- Acceptance Test Bed bør settes opp og det skal utføres høynivåsjekk for miljøproblemer.
- Systemtestfasen bør være avskrevet, slik at produktet kan gå til AT-fasen (vanligvis gjøres via e-postkommunikasjon).
Utgangskriterier
Det er visse vilkår som AT må oppfylle for å la produktet gå for en produksjonslansering.
De er som følger:
- Akseptprøver skal utføres, og alle testene skal bestås.
- Ingen kritiske / store mangler igjen åpne. Alle feilene skal løses og bekreftes umiddelbart.
- AT skal signeres av alle inkluderte interessenter med Go / No-Go Beslutning om produktet.
Akseptprøvingsprosess
I V-modell , AT-fasen er parallell med Krav-fasen.
Den faktiske AT-prosessen går som vist nedenfor:
Analyse av forretningskrav
Forretningskrav analyseres ved å henvise til alle tilgjengelige dokumenter i prosjektet.
Noen av disse er:
hvordan du konfigurerer junit i formørkelse
- Systemkrav Spesifikasjoner
- Dokument for forretningskrav
- Bruk tilfeller
- Arbeidsflytdiagrammer
- Designet datamatrise
Design godkjenningstestplan
Det er visse ting som skal dokumenteres i akseptplanen.
La oss ta en titt på noen av dem:
- Aksept Testing strategi og tilnærming.
- Inngangs- og utgangskriterier bør være veldefinerte.
- Omfanget av AT bør være godt nevnt, og det må bare dekke forretningskravene.
- Godkjenningstestdesigntilnærmingen bør være detaljert, slik at alle som skriver tester lett kan forstå måten den må skrives på.
- Test seng satt opp, faktisk testplan / tidslinjer bør nevnes.
- Ettersom testing utføres av forskjellige interessenter, bør detaljer om loggingsfeil nevnes, da interessentene kanskje ikke er klar over fremgangsmåten som følges.
Design og gjennomgangstest
Akseptprøver bør skrives på scenarinivå og nevne hva som må gjøres (ikke detaljert for å inkludere hvordan du gjør). Disse skal bare skrives for de identifiserte områdene for forretningskrav, og hver test må tilordnes til referansekravet.
Alle skriftlige akseptprøver må gjennomgås for å oppnå høy dekning av forretningskrav.
Dette for å sikre at andre tester bortsett fra nevnte omfang ikke er involvert, slik at testing ligger innenfor de planlagte tidslinjene.
Akseptprøveseng satt opp
Test Bed bør settes opp i likhet med et produksjonsmiljø. Det kreves svært høye nivåer for å bekrefte miljøstabilitet og bruk. Del legitimasjonen for å bruke miljøet bare med en interessent som utfører denne testen.
Oppsett av godkjenningstestdata
Produksjonsdata må utarbeides / fylles ut som testdata i systemene. Det bør også være et detaljert dokument på en slik måte at dataene må brukes til testing.
Ikke ha testdata som TestName1, TestCity1 osv. I stedet har Albert, Mexico osv. Dette gir en rik opplevelse av sanntidsdata og testing vil være up-to-the-point.
Akseptprøveutførelse
Konstruerte aksepttester må utføres på miljøet på dette trinnet. Ideelt sett bør alle testene bestå ved første forsøk. Det bør ikke være noen funksjonelle feil som oppstår på grunn av godkjenningstesting, hvis noen, bør de rapporteres med høy prioritet for å bli løst.
Igjen, feil som er løst, må bekreftes og lukkes som en oppgave med høy prioritet. Testutførelsesrapporten må deles på daglig basis.
Feil som er logget inn i denne fasen, bør diskuteres i et bug-triage-møte og må gjennomgå analysen av rotårsaken. Dette er det eneste punktet der akseptansetesting vurderer om alle forretningskravene faktisk blir oppfylt av produktet eller ikke.
Forretningsbeslutning
Det kommer ut en Go / No-Go beslutning om at produktet skal lanseres i produksjon. Gå beslutningen vil føre produktet fremover for å bli lansert på markedet. Nei det går ikke avgjørelsen markerer produktet som feil.
Få faktorer ved No-Go-avgjørelsen:
- Dårlig kvalitet på produktet.
- For mange åpne funksjonelle feil.
- Avvik fra forretningskrav.
- Ikke opp til markedsstandardene og behovsforbedringer for å matche dagens markedsstandarder.
Suksessfaktorer for denne testen
Når denne testen er planlagt, utarbeider du en sjekkliste som øker suksessraten for den. Det er noen handlingselementer som skal følges før godkjenningstesten starter.
De er:
- Ha et veldefinert omfang og sørg for at det er et forretningsbehov for omfanget som er identifisert for denne testingen.
- Utfør akseptattester i selve systemtestfasen minst en gang.
- Utfør omfattende ad-hoc testing for hvert av aksept-test-scenariene.
Konklusjon
I et nøtteskall hjelper akseptatestesting med å finne ut effektiviteten til utviklings- og testteam.
Det er flere verktøy for å gjennomføre denne aktiviteten, men vanligvis foretrekkes det å gjøres manuelt, da det er en involvering av de virkelige brukerne og forskjellige interessenter som ikke har teknisk bakgrunn, og det kan ikke være mulig for dem.
Hva blir det neste?
I vår neste opplæring vil vi sveve på emnene nedenfor:
- Eksempler på kriterier for akseptatestest.
- Hvordan skrive en akseptplan.
- En passende mal for skriving av godkjenningstester.
- Hvordan skrive aksepttester med eksempler.
- Identifisere scenarier for akseptatest.
- Akseptprøverapporter.
- Akseptprøving i smidig og testdrevet utvikling.
NESTE veiledning nr. 2: Godkjenningstestplan
Har du utført Acceptance Testing? Vi vil gjerne høre dine erfaringer !!
Anbefalt lesing
- Alpha Testing og Beta Testing (En komplett guide)
- Hva er brukertest (UAT): En komplett guide
- Build Verification Testing (BVT Testing) Komplett guide
- Funksjonstesting mot ikke-funksjonell testing
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Typer programvaretesting: Ulike testtyper med detaljer
- ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
- Veiledning for testing av webapplikasjoner