Vad är acceptantestning (en komplett guide)

what is acceptance testing

Introduktion till acceptantestning (del-I):

I denna handledningsserie lär du dig:

1. Vad är acceptantestning
2. Godkännande tester och testplan
3. Godkännandesteststatus och sammanfattningsrapporter
4. Vad är UAT (User Acceptance Testing)

Är du klar med systemtestning? Är de flesta av dina buggar fixade? Är buggarna verifierade och stängda? Så, vad är nästa?

Nästa i listan kommer Acceptance Testing, som är den sista fasen av Software Testing Process . Detta är den fas där kunden bestämmer GO / No-GO för produkten och måste följas obligatoriskt innan produkten släpps ut på marknaden. Gemensamma ansträngningar för utvecklingen och testteamet kommer att tilldelas av kunden genom att antingen acceptera eller avvisa den utvecklade produkten.

Denna unika handledning om Acceptance Testing ger dig en fullständig översikt över betydelse, typer, användningsområden och olika andra faktorer som är involverade i Acceptance Test på ett enkelt och enkelt sätt för din bättre förståelse.

Vad du kommer att lära dig:

• Vad är acceptantestning?
• Varför godkännande tester?
• Typer
  • # 1) Test av användaracceptans (UAT)
  • # 2) Test av affärsacceptans (BAT)
  • # 3) Test av kontraktering (CAT)
  • # 4) Föreskrifter / testning av godkännande av efterlevnad (RAT)
  • # 5) OAT (Operational Acceptance Testing)
  • # 6) Alpha Testing
  • # 7) Betatestning / fälttestning
• Vem gör acceptantestning?
• Godkännande av godkännande testare
• Använda sig av
• Skillnader mellan systemtestning, acceptantestning och testning av användaracceptans
• Godkännande tester
• Godkännandeprov
• Inträdes- och utgångskriterier för AT
  • Inträdeskriterier
  • Utgångskriterier
• Testprocess för godkännande
• Framgångsfaktorer för denna testning
• Slutsats
• Rekommenderad läsning

Vad är acceptantestning?

När Systemtestprocess har slutförts av testteamet och är utloggad, hela produkten / applikationen överlämnas till kunden / få användare av kunder / båda, för att testa om den är godtagbar, dvs. produkten / applikationen ska vara felfri för att möta både kritiska och stora affärskrav. Dessutom kontrolleras helhetsaffärsflöden på samma sätt som i realtidsscenario.

Den produktionsliknande miljön kommer att vara testmiljön för Accepting Testing (vanligtvis benämnd Staging, Pre-Prod, Fail-Over, UAT-miljö).

Det här är en black-box testteknik där endast funktionaliteten är verifierad för att säkerställa att produkten uppfyller de angivna acceptanskriterierna (inget behov av kunskap om design / implementering).

Varför godkännande tester?

Även om systemtestningen har slutförts framgångsrikt, krävs acceptantestet av kunden. Tester som utförs här är repetitiva, eftersom de skulle ha behandlats i systemtester.

Varför utförs denna test av kunder?

Det här är för att:

• För att få förtroende för den produkt som släpps ut på marknaden.
• För att säkerställa att produkten fungerar som den måste.
• För att säkerställa att produkten uppfyller gällande marknadsstandarder och är tillräckligt konkurrenskraftig med andra liknande produkter på marknaden.

Typer

Det finns flera typer av denna testning.

Få av dem listas nedan:

# 1) Test av användaracceptans (UAT)

UAT är att bedöma om produkten fungerar för användaren, korrekt för användningen. Specifika krav som ofta används av slutanvändarna väljs främst för teständamålet. Detta kallas också testning av slutanvändare.

Uttrycket 'Användare' betyder här de slutanvändare som Produkten / applikationen är avsedd för och därför utförs testning ur slutanvändarperspektivet och ur deras synvinkel.

=> Också Läsa: Vad är UAT (User Acceptance Testing)?

# 2) Test av affärsacceptans (BAT)

Detta för att bedöma om produkten uppfyller affärsmålen och syftena eller inte.

BAT fokuserar främst på affärsnytta (ekonomi) som är ganska utmanande på grund av förändrade marknadsförhållanden / avancerad teknik så att det nuvarande genomförandet kan behöva genomgå förändringar som resulterar i extra budgetar.

c ++ intilliggande lista oriktad graf

Även produkten som uppfyller de tekniska kraven kan misslyckas BAT på grund av dessa skäl.

# 3) Test av kontraktering (CAT)

Detta är ett avtal som specificerar att när produkten går i drift inom en förutbestämd period måste godkännandestestet utföras och det ska klara alla fall för acceptansanvändning.

Kontrakt som undertecknas här betecknas som servicenivåavtal (SLA), vilket inkluderar villkoren där betalningen endast kommer att göras om produkttjänsterna är i linje med alla krav, vilket innebär att avtalet uppfylls.

Ibland kan detta avtal inträffa innan produkten sätts i drift. Hur som helst, ett kontrakt bör vara väl definierat i termer av testperioden, testområden, förhållanden i frågor som påträffas i senare skeden, betalningar etc.

# 4) Regler /ÖverensstämmelseAcceptation Testing (RAT)

Detta för att bedöma om produkten bryter mot de regler och regler som definieras av regeringen i det land där den släpps. Detta kan vara oavsiktligt men kommer att påverka verksamheten negativt.

Vanligtvis måste den utvecklade produkten / applikationen som är avsedd att släppas över hela världen genomgå RAT, eftersom olika länder / regioner har olika regler och regler som definieras av dess styrande organ.

Om något av reglerna och reglerna överträds för något land, får inte det landet eller den specifika regionen i det landet använda produkten och anses vara ett misslyckande. Leverantörer av produkten är direkt ansvariga om produkten släpps även om det finns ett brott.

# 5) OAT (Operational Acceptance Testing)

Detta för att bedöma produktens driftberedskap och är en icke-funktionell testning. Det inkluderar främst testning av återställning, kompatibilitet, underhållsbarhet, tillgänglighet för teknisk support, tillförlitlighet, fail-over, lokalisering etc.

OAT säkerställer främst produktens stabilitet innan den släpps ut till produktionen.

# 6) Alpha Testing

Detta är för att bedöma produkten i utvecklings- / testmiljön av ett specialiserat testteam som vanligtvis kallas alfatestare. Här testarnas feedback, förslag hjälper till att förbättra produktanvändningen och även att fixa vissa buggar.

Här sker testning på ett kontrollerat sätt.

=> Läs också: Vad är Alpha Testing?

# 7) Betatestning / fälttestning

Detta är för att bedöma produkten genom att exponera den för de riktiga slutanvändarna, vanligtvis kallade betatestare / betanvändare, i deras miljö. Kontinuerlig feedback från användarna samlas in och problemen fixas. Detta hjälper också till att förbättra / förbättra produkten för att ge en rik användarupplevelse.

Testning sker på ett okontrollerat sätt, vilket innebär att en användare inte har några begränsningar för hur produkten används.

=> Läs också: Vad är betatestning?

Alla dessa typer har ett gemensamt mål:

• Se till att få / berika förtroende för produkten.
• Se till att produkten är redo att användas av riktiga användare.

Vem gör acceptantestning?

För Alpha-typ är det bara medlemmarna i organisationen (som har utvecklat produkten) som testar. Dessa medlemmar är inte direkt en del av projektet (projektledare / leads, utvecklare, testare). Ledning, försäljning, supportteam utför vanligtvis testningen och ger feedback därefter.

Förutom Alpha-typen utförs alla andra typer av acceptans i allmänhet av olika intressenter. Liksom kunder, kundens kunder, specialiserade testare från organisationen (inte alltid).

Det är också bra att involvera affärsanalytiker och ämneskompetens när du utför denna testning baserat på dess typ.

Godkännande av godkännande testare

Testare med nedanstående kvaliteter är kvalificerade som acceptantestare:

• Förmåga att tänka logiskt och analytiskt.
• Bra domänkunskap.
• Kunna studera konkurrenskraftiga produkter på marknaden och analysera detsamma i den utvecklade produkten.
• Att ha slutanvändarens uppfattning under testningen.
• Förstå affärsbehovet för varje krav och testa därefter.

Effekten av problem som hittats under denna testning

Eventuella problem som uppstått under godkännandestestfasen bör betraktas som en hög prioritet och åtgärdas omedelbart. Detta kräver också att orsaksanalys ska utföras för varje problem som hittas.

Testteamet spelar en viktig roll när det gäller att tillhandahålla RCA för acceptansfrågor. Dessa hjälper också till att bestämma hur effektivt testning utförs.

Giltiga problem i godkännandeprov kommer också att träffa både test- och utvecklingsteamets ansträngningar när det gäller intryck, betyg, kundundersökningar, etc. Ibland, om någon okunnighet från testteamet om valideringar upptäcks, leder det också till eskaleringar.

Använda sig av

Denna testning är användbar ur flera aspekter.

Få av dessa inkluderar:

• Att räkna ut de problem som missats under den funktionella testfasen.
• Hur bra produkten är utvecklad.
• En produkt är vad kunderna faktiskt behöver.
• Återkopplingar / undersökningar genomförde hjälp med att förbättra produktens prestanda och användarupplevelse.
• Förbättra processen följt av att ha RCA som input.
• Minimera eller eliminera de problem som uppstår från produktionsprodukten.

Skillnader mellan systemtestning, acceptantestning och testning av användaracceptans

Nedan följer de främsta skillnaderna mellan dessa tre typer av acceptantest.

Godkännande tester

I likhet med fall av produkttest har vi acceptantest. Godkännandeprov härleds från användarberättelsernas acceptanskriterier. Det här är vanligtvis scenarierna som skrivs på hög nivå med information om vad produkten måste göra under olika förhållanden.

Det ger ingen tydlig bild av hur man utför tester, som i testfall. Godkännande tester skrivs av testare som har ett fullständigt grepp om produkten, vanligtvis ämnesområde expertis. Alla skrivna tester granskas av en kund och / eller affärsanalytiker.

Dessa tester utförs under godkännandestestet. Tillsammans med acceptantest måste ett detaljerat dokument om eventuella inställningar som ska göras utarbetas. Den ska innehålla detaljer varje minut med korrekta skärmdumpar, inställningsvärden, villkor etc.

Godkännandeprov

Testbädd för denna testning liknar en vanlig testbädd men är en separat. Plattform med all nödvändig hårdvara, programvara, operativprodukter, nätverksinställningar och konfigurationer, serverinställningar och konfigurationer, databasinställningar och konfigurationer, licenser, plugin-program etc. måste ställas in mycket lika produktionsmiljön.

Acceptance test bed är en plattform / miljö där de designade acceptansproven kommer att utföras. Innan vi överlämnar Acceptance-testmiljön till kunden är det en god praxis att kontrollera om det finns miljöproblem och stabilitet hos produkten.

Om det inte finns någon separat miljö för acceptantestning kan en vanlig testmiljö användas för detta ändamål. Men här kommer det att bli rörigt eftersom testdata från regelbunden systemtestning och realtidsdata från godkännandestester bibehålls i en enda miljö.

Acceptans testbädd är vanligtvis inställd på kundsidan (dvs. i laboratoriet) och har begränsad tillgång till utvecklings- och testteam.

Team kommer att krävas för att komma åt den här miljön via virtuella datorer / eller specifikt utformade webbadresser med särskild åtkomstinformation och all åtkomst till detta kommer att spåras. Ingenting i den här miljön måste läggas till / ändras / raderas utan kundens tillstånd, och de bör meddelas om de ändringar som görs.

Inträdes- och utgångskriterier för AT

Precis som alla andra faser i STLC har acceptantestning en uppsättning in- och utgångskriterier som ska vara väldefinierade i Acceptance Test Plan (som beskrivs i den senare delen av denna handledning).

Detta är den fas som börjar direkt efter systemtestning och slutar innan produktionsstart. Så, utgångskriterierna för systemtestning blir en del av inträdeskriterierna för AT. På samma sätt blir AT: s utgångskriterier en del av inträdeskriterierna för produktionslanseringen.

Inträdeskriterier

Nedan följer de villkor som ska uppfyllas innan du börjar:

• Företagskraven bör vara tydliga och tillgängliga.
• Testfasen för system och regression bör vara avslutad.
• Alla kritiska, större och normala buggar ska fixas och stängas (mindre buggar accepteras främst är kosmetiska buggar som inte stör användningen av produkten).
• Listan över kända frågor bör utarbetas och delas med intressenterna.
• Godkännandeprovbädd bör ställas in och högnivåkontroll ska utföras utan miljöfrågor.
• Systemtestfasen bör vara avstängd så att produkten kan flyttas till AT-fasen (vanligtvis görs via e-postkommunikation).

Utgångskriterier

Det finns vissa villkor som AT ska uppfylla för att låta produkten gå för en produktionslansering.

De är som följer:

• Godkännande tester ska utföras och alla tester ska klara.
• Inga kritiska / större defekter kvar öppen. Alla brister bör åtgärdas och verifieras omedelbart.
• AT bör undertecknas av alla inkluderade intressenter med Go / No-Go Beslut om produkten.

Testprocess för godkännande

I V-modell , AT-fasen är parallell med kravfasen.

Den faktiska AT-processen går enligt nedan:

Analys av affärsbehov

Affärsbehov analyseras med hänvisning till alla tillgängliga dokument inom projektet.

Några av dessa är:

• Specifikationer för systemkrav
• Dokument för affärsbehov
• Använd fodral
• Arbetsflödesdiagram
• Designad datamatris

Testplan för designacceptans

Det finns vissa saker som ska dokumenteras i Acceptance Test Plan.

Låt oss ta en titt på några av dem:

unix shell-skriptkommandon med exempel

• Acceptance Testing strategi och strategi.
• Inträdes- och utgångskriterier bör vara väldefinierade.
• Omfattningen av AT bör vara väl nämnd och den måste endast täcka affärsbehovet.
• Tillvägagångssättet för godkännande testdesign bör beskrivas så att alla som skriver tester lätt kan förstå hur det måste skrivas.
• Testbäddsinställning, faktiskt testschema / tidslinjer bör nämnas.
• Eftersom testning utförs av olika intressenter bör detaljer om loggningsfel nämnas eftersom intressenterna kanske inte känner till förfarandet som följts.

Design och granska godkännande tester

Godkännandeprov bör skrivas på scenarionivå med angivande av vad som måste göras (inte detaljerat för att inkludera hur man gör). Dessa bör skrivas endast för de identifierade områdena för affärsbehov, och varje test måste mappas till dess referenskrav.

Alla skriftliga godkännandeprov måste granskas för att uppnå hög täckning av affärsbehov.

Detta för att se till att andra tester förutom det angivna omfattningen inte är inblandade så att testningen ligger inom de schemalagda tidslinjerna.

Acceptance Test Bed Set up

Testbädd ska ställas in liknande en produktionsmiljö. Det krävs mycket höga kontroller för att bekräfta miljöstabilitet och användning. Dela uppgifterna för att endast använda miljön med en intressent som utför denna testning.

Inställningar för godkännandetestdata

Produktionsdata måste förberedas / fyllas ut som testdata i systemen. Det bör också finnas ett detaljerat dokument på ett sådant sätt att data måste användas för testning.

Har inte testdata som TestName1, TestCity1 osv. Istället har Albert, Mexiko etc. Detta ger en rik upplevelse av realtidsdata och testning kommer att vara up-to-the-point.

Godkännande Test utförande

I detta steg måste designade godkännandetester utföras på miljön. Helst bör alla tester klara vid första försöket. Det bör inte finnas några funktionsfel som uppstår till följd av acceptantestning, om någon, bör de rapporteras med hög prioritet för att fixas.

Återigen måste fixade buggar verifieras och stängas som en högprioritetsuppgift. Testutföranderapporten måste delas dagligen.

Fel som är inloggade i denna fas bör diskuteras i ett bug-triage-möte och måste genomgå förfarandet för analys av rotorsaker. Det här är den enda punkten där acceptansprovning bedömer om alla affärsbehov faktiskt uppfylls av produkten eller inte.

Affärsbeslut

Det kommer ut en Go / No-Go beslut om att produkten ska lanseras i produktion. Gå beslutet tar produkten framåt och släpps ut på marknaden. Nej gå beslutet markerar produkten som misslyckande.

Få faktorer av No-Go-beslutet:

• Produktens dåliga kvalitet.
• För många öppna funktionella buggar.
• Avvikelse från affärsbehov.
• Inte upp till marknadsstandarderna och behöver förbättras för att matcha de nuvarande marknadsstandarderna.

Framgångsfaktorer för denna testning

När detta test är planerat, förbered en checklista som ökar framgångsgraden för det. Det finns några åtgärdsposter som ska följas innan acceptantestet startar.

Dom är:

• Ha ett väldefinierat omfång och se till att det finns ett affärsbehov för det utrymme som identifierats för denna testning.
• Utför acceptattester i själva systemtestfasen minst en gång.
• Utför omfattande ad hoc-testning för vart och ett av acceptans-testscenarierna.

Slutsats

I ett nötskal hjälper Acceptance testing till att räkna ut effektiviteten hos utvecklings- och testteam.

Det finns flera verktyg för att genomföra denna aktivitet, men vanligtvis föredras det att göras manuellt eftersom det finns ett engagemang från riktiga användare och olika intressenter som inte har teknisk bakgrund, och det kanske inte är möjligt för dem.

Vad kommer härnäst?

I vår nästa handledning kommer vi att sväva över följande ämnen:

• Exempel på kriterier för godkännande test.
• Hur man skriver en godkännandeplan.
• En lämplig mall för antagningstest.
• Hur man skriver acceptantest med exempel.
• Identifiera acceptans test scenarier.
• Godkännandeprovrapporter.
• Acceptantestning i Agile och testdriven utveckling.

NÄSTA självstudie # 2: Acceptance Test Plan

Har du utfört Acceptance Testing? Vi skulle gärna höra dina erfarenheter !!

Rekommenderad läsning

• Alfatestning och betatestning (En komplett guide)
• Vad är användaracceptansprovning (UAT): En komplett guide
• Byggverifieringstestning (BVT-testning) Komplett guide
• Funktionell testning mot icke-funktionell testning
• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Typer av programvarutestning: Olika testtyper med detaljer
• ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
• Testguide för webbapplikationssäkerhet