Meny

Godkännandedokumentation med realtidsscenarier

acceptance testing documentation with real time scenarios

Prova Vårt Instrument För Att Eliminera Problem

Dokumentation av godkännandeprovning (del II):

Föregående handledning | NÄSTA självstudie

Denna handledning är en fortsättning på vår tidigare handledning där vi diskuterade vad som är acceptantestning, när det måste göras, vem som gör det, dess betydelse, typer, process, inverkan på olika team etc.

ado.net intervjufrågor och svar för erfarna

Dokument spelar en mycket viktig roll i Acceptance Testing och eventuella problem med dokumentet har en enorm negativ inverkan. När en korrekt kontroll inte utövas kan det till och med leda till att produkten misslyckas.

=> Klicka här för en fullständig handledningsserie för testplan

I den här handledningen kommer vi att lära oss mer om de olika dokumentationen som är involverade i Acceptance Testing, dvs Acceptance Test Plan, Test Plan Review Review Checklist, Acceptance Test Template, exempel baserade på realtidsscenarier, hur man identifierar och skriver acceptansprov etc. .

Godkännandedokumentation

Vad du kommer att lära dig:

Godkännandeprovplan

Liksom alla andra testplaner innehåller acceptansplanen också vissa komponenter som omfattning, tillvägagångssätt, testmiljö, resurser, ansvar, acceptantestreferenser, ingångskriterier, utgångskriterier, verktyg etc.

Det enda som skiljer Acceptance-testplanen från en vanlig testplan är dess faktorer som leder till affärsbeslut. Acceptance Test Plan är en av de viktigaste dokumentationerna som ger vägledning om hur man utför acceptantestning för ett visst projekt.

Acceptans testplan måste granskas och godkännas innan Acceptance Test Execution utförs. Alla efterföljande ändringar måste igenom granskas och godkännas och måste vara i spår.

Acceptance Test Plan review görs vanligtvis av chefer / affärsanalytiker / kunder.

Viktiga punkter som ska övervägas vid utformningen av Acceptance Test Plan:

  • Det borde vara Detaljerad och specifik. Får endast innehålla vad som krävs för testning och vilken information som krävs för att teamet ska kunna testa.
  • Det borde vara Tydlig och kortfattad . Ingen tvetydighet. Om det alls finns något som kan leda till förvirring, så utarbeta det, men håll det kort och effektivt.
  • Varje komponent i dokumentet bör skrivas genom att endast ha företagskraven i åtanke.
  • Pålitlig och anpassningsbar - Det bör uppdateras enligt behov i framtida utgåvor.
  • Konsekvent - Det borde inte ha fler förändringar i framtiden.
  • Följ mallen som tillhandahålls av organisationen eller kunden.

Mall för godkännandeprovplan

Här tar vi en titt på en gemensam mall för Acceptance Test Plan som kan finjusteras ytterligare enligt projektkraven.

Titel

Mål

Till exempel: Om projektet ska tjäna tjänster för bankanställda / säljare / utbildningsinstitut etc. måste det tydligt nämnas. Det bör också nämna anledningen till att det specifika kravet har valts

Revisionshistorik / ändringslogg

< Detta bör vara i tabellform med nedanstående information:

  • Datum - Datum då dokumentet ändrades.
  • Modifierad av - Vem som har ändrat innehållet i dokumentet.
  • Ändamål - Varför ändrades dokumentet.
  • Version - Aktuell version av dokumentet efter modifieringar (går som 1.0, 1.1, 1.2, 1.3, ... för en viss release. Nästa release börjar från 2, 2.1, 2.2, 2.3, ..., Listan fortsätter).
  • Godkänd av - Vem som har godkänt ändringarna (implicit innebär att dokumentet har granskats och godkänts).

Den allra första raden i denna tabell bör vara de dokument som skapats. Därefter följer detaljerna i de ändringar som gjorts

Innehållsförteckning

Referenser

Omfattning

Exempel : Alla affärsscenarier).>

Introduktion

Negativ testning (inte alltid), etc.>

Testföremål

Exempel : Client Application, Server Application, etc.)>

Funktioner som ska testas

Exempel : Sök med olika nyckelord, navigering mellan moduler och undermoduler etc.), Säkerhetsfunktioner ( Exempel : Registrering till webbplats, inloggning på webbplats, transaktioner, etc.)>

Funktioner som inte ska testas

Närma sig

Exempel : När alla godkännandeprov har utförts, utforskande testning kommer att utföras under en mycket kort varaktighet för att bedöma produktens lätthet och användning. Varje fel som påträffas loggas i bugghanteringsverktyget och diskuteras i bug triage-möten för RCA: s ...)>

Testmiljöinformation

Se acceptantestning - del 1 ).>

Inträdeskriterier

Tester - Om det inte finns några separata godkännandeprov skrivna

Varje test måste innehålla:

  • Test #.
  • En beskrivning av vad som testas ( Exempel : Kontrollera om en användare kan skapa ett konto framgångsrikt).
  • Företagskrav som testet kartlägger ( Spårbarhetsmatris ) - Väldigt viktigt.
  • Förutsättningar:
    • Produktens status innan testet påbörjas (Användaren ska registreras framgångsrikt men inte aktivera kontot, användaren borde ha åtkomst till produkten för minst 30 dagar sedan, etc.)
    • Eventuella serverförhållanden - Skulle servern vara nere under en tid.
  • Teststeg: Detaljerat numrerat flöde ( Exempel: se nedan
    • Öppna applikationen.
    • Försök att logga in med giltiga referenser med kryssrutan Kom ihåg mig).
  • Förväntat resultat : Vad är stegets förväntade beteende>

Godkännande tester - Om det finns separata godkännande tester skrivna

Utgångskriterier

Resurser

Roller och ansvar

Verktyg

Faktorer för affärsbeslut

Go eller No-Go .>

Inloggningsförfarande

Kontaktpunkt

Godkännandeprovplan betraktas som Master Test Plan för fasen .

Granska godkännandeprovplanen

När planen är klar måste den granskas för fullständighet, tvetydighet, tydlighet, kvalitet osv. Ingen tvekan om att hela innehållet i Acceptance-testplanen måste granskas grundligt för korrekt information, men det måste granskas mot några andra punkter, låt oss säga att checklistapoäng.

Låt oss här kategorisera innehållet och se checklistan pekar mot dem.

KategoriChecklista poäng
Godkännande tester Är testerna numrerade

Är förutsättningarna numrerade

Är teststegen tydliga att förstå

Är teststegen färdiga

Är det förväntade resultatet komplett

Finns det någon öppen fråga i testerna (om någon, följ upp och slutföra den)

Är hänvisningen till godkännandestest (om den skrivs separat) giltig och existerande

Är spårbarheten korrekt

Finns det något affärskrav som missas för att täcka testet
Titel Är titeln som matchar projektets titel som hänvisas överallt

Är titeln efter Projektets namnkonventioner
Revisionshistorik, innehållsförteckning Spåras alla modifieringar av versionen ordentligt för planen

Har varje versionändring genomgått korrekt granskning och nämns

Är versionskonventionen korrekt

Matchar innehållsförteckningen det faktiska innehållet i planen

Är sidnumret för varje innehåll korrekt

Uppdateras sidnumret om ändringarna i planen ändrade sidnumret på innehållet
Referenser Är referenserna existerande och giltiga

Stämmer de överens med omfattningen

Är de fullständiga och övervägs för identifiering av test
Testartiklar, funktioner som ska testas, funktioner som inte ska testas Är de numrerade

Kommer varje funktion / modul / undermodul till omfattning

Kan det planerade schemat täcka alla identifierade testobjekt inom
Inträdeskriterier, utgångskriterier Är de numrerade

Är varje kriterium nämnt i detalj
Testmiljöinformation Har den alla nödvändiga konfigurationer som nämns

Är versionen för varje konfiguration specifik eller senaste som ska övervägas

Finns de virtuella datorerna, miljön (om inte, ange eventuellt datum för tillgänglighet)

Är referensdelningsmetoden för särskild miljöåtkomst nämnd
Resurser, roller och ansvar Är ansvaret för varje roll numrerad

Kan ansvar uppnås

Kan den identifierade resursen hantera nämnda ansvarsområden
Verktyg Nämns alla verktyg

Är alla verktyg numrerade

Är alla verktyg versionerade

Behöver något av verktyget licens eller den befintliga licensen giltig under fasen

Är vägledningen till verktygsanvändningen korrekt och tillräcklig
Faktorer för affärsbeslut Har alla nämnda faktorer

Är alla faktorer numrerade
Inloggningsförfarande Är proceduren giltig

Är proceduren acceptabel

Är förfarandet klart att förstå
Kontaktpunkt Är resursen identifierad som kontaktpunkt tillgänglig i organisationen under fasen

Kan den identifierade resursen hantera fasen

Alla testplaner som uppfyller ovanstående checklistdokument kommer också att fungera som ett starkt dokument för interna revisioner.

Godkännande tester

Acceptansprov var tidigare kända som Functional tests. För att göra namnet mer lämpligt för Acceptance-testfasen och för att tjäna syftet döptes det om till Godkännande tester. Ibland kallas det också som Kundtest.

Acceptansprov härleds alltid från användarberättelser, acceptanskriterier och användningsfall. Det här är systemtester i svart rutan och representerar endast de affärstester som måste verifieras. Dessa bör huvudsakligen vara avsedda för produktbeteende, användning och flöden.

De utformade acceptansproven kan också tas i beaktande för systemtestfasen i regressionscyklerna för att få förtroende för produkten innan den överlämnas till godkännandeprovningsfasen.

Godkännande tester

Viktiga punkter att komma ihåg innan du skriver godkännandeprov:

  • Håll alla referensdokument på plats: Specifikation av programvarukrav, affärskravdokument, användningsfall, användarberättelser, datamatris (vid logik).
  • Fokusera bara på företagskrav (testbara affärskrav).
  • Rensa alla tvivel, frågor om affärskraven tidigast.
  • Se till att det inte finns några ändringar av kraven för den aktuella versionen åtminstone.

Allmän och enkel mall för att skriva godtagningstester:

Mall för godkännande test

Den här mallen kan igen justeras enligt projektets behov och med mer information att inkludera.

Låt oss nu ta några vanliga scenarier och se hur acceptansprovsscenarier kan skrivas på dem.

Fall 1: Användarkontohantering

Detta är scenariot där användarna får skapa, visa, uppdatera och avaktivera sitt konto. I allmänhet är det en CRUD-operation (Skapa, läsa, uppdatera och ta bort). Så direkt får vi fyra stora scenarier att testa.

Tillsammans med detta har vi i realtid hantering av användarkonton många områden när det gäller visning och uppdatering.

Fortsätter med att skriva godkännandeprov:

Test 1: Registrering / Registrering / Skapa konto, verifiera om en användare kan:

  • Skapa kontot.
  • Aktivera kontot.
  • Aktivera kontot bara en gång (här måste aktiveringslänken testas för 2ndÄven om detta är negativ testning är det en av de viktigaste verifieringspunkterna som ska övervägas).

Test 2: För att komma åt och visa kontoinformation, verifiera om en användare kan:

  • Logga in på kontot.
  • Visa olika sektioner i profilen (Om profilavsnittet är kategoriserat bör varje kategori kunna visas).
  • Kontrollera att informationen som visas i profilen är korrekt enligt användarens inmatning.

Test 3: För att uppdatera kontoinformation, verifiera om en användare kan:

  • Uppdatera kontoinformation (profil):
    • Uppdatera varje kategori i profilen.
  • Kontrollera att uppdateringsinformationen återspeglas korrekt i profilen.
  • Kontrollera om användaren inte kan uppdatera informationen i profilen (i vissa applikationer får förnamn, efternamn, användarnamn etc. inte uppdateras. Även om detta är negativ testning är det en av de viktigaste verifieringspunkterna att betraktas).
  • Avbryt uppdateringsflödet (även om detta är negativ testning är det också en av de viktigaste verifieringspunkterna som ska övervägas).

Test 4: Om avaktivering av konto är tillåtet ska du verifiera om en användare kan:

  • Avaktivera kontot.
  • Avbryt avaktiveringsflödet (även om detta är negativ testning är det en av de viktigaste verifieringspunkterna som ska övervägas).
  • Åtkomst till konto efter att avbryta avaktiveringen.

Test 5: Om verifieringar krävs för en e-postadress eller telefonnummer, kontrollera sedan om en användare kan:

vad är integrationstest med exempel
  • Uppdatera e-postadressen till den andra giltiga.
  • Verifiera ”uppdaterad e-postadress.
  • Verifiera om uppdaterad och 'verifierad' e-postadress övervägs ytterligare - Skicka några e-postmeddelanden från applikationen och kontrollera om den har kommit till den uppdaterade e-postadressen. Den gamla ska inte ta emot mejl.
  • Lägg till det nya telefonnumret.
  • Verifiera tillagt telefonnummer via Ring.
  • Verifiera tillagt telefonnummer via SMS.
  • Kontrollera att det tillagda och 'verifierade' telefonnumret återspeglas i kontot.
  • Uppdatera telefonnumret.
  • Verifiera uppdaterat telefonnummer genom att ringa.
  • Verifiera ”uppdaterat telefonnummer via SMS.
  • Kontrollera om uppdaterat och 'verifierat' telefonnummer återspeglas i kontot.

Fall 2: Inköpsprodukt

Inköp av produkten har vanligtvis det generella flödet.

Här visas några allmänna scenarier som slutanvändarna tittar på:

Förutsättning: Användaren ska vara inloggad på applikationen.

Test 1: Produktinformation, verifiera om en användare kan:

  • Se sidan Produktinformation.
  • Visa alla underavsnitt på sidan Produktinformation (beskrivning, funktion, varumärkesinformation etc.).
  • Välj produktens kvantitet, färg, storlek etc. som finns på sidan Produktinformation.
  • Navigera till kategori, underkategorisidor från sidan Produktinformation (om tillgängligt på sidan Produktinformation).
  • Navigera till den andra produkts informationssida (om relevant produktavsnitt anges).
  • Visa kommentarer och betyg på produkten.
  • Sortera produktens kommentarer baserat på betyg.
  • Visa produktens totala betyg.
  • Lägg till kommentar om produkten.
  • Uppdatera hans / hennes kommentar om produkten.
  • Ta bort hans / hennes kommentar om produkten (om sådan finns).

Test 2: Lägg i kundvagn, verifiera om en användare är:

  • Kan lägga till produkten i kundvagnen:
    • Genom produktinformationssidan.
    • Genom sidan med produktlistor.
  • Kunna lägga till önskad kvantitet i kundvagnen (1 till maxgräns inställd).
  • Det går inte att lägga till produkten i kundvagnen om det inte finns i lager.

Test 3: Kontrollera om en användare har möjlighet att:

  • Se produkten i kundvagnen med prisinformation för extra kvantitet.
  • Uppdatera kvantitet (1 till maxgräns inställd).
  • Ta bort produkten från kundvagnen.
  • Navigera tillbaka till shopping.
  • Fortsätt till kassan.
  • Visa Tom kundvagn när ingen produkt har lagts till,

Test 4: Kontrollera om en användare kan på sidan Kontoinformation:

  • Fortsätt med befintlig leveransinformation.
  • Uppdatera leveransadress.
  • Lägg till ny leveransadress.
  • Fortsätt med befintligt telefonnummer.
  • Uppdatera telefonnumret för beställningen.
  • Lägg till ett nytt telefonnummer för beställningen.
  • Gå tillbaka till varukorgssidan.
  • Navigera till sidan Betalning.

Test 5: På betalningssidan kontrollerar du om en användare kan:

  • Kontrollera att det belopp som ska faktureras är korrekt.
  • Behandla beställningen med alla tillgängliga alternativ (ett alternativ för varje separat beställning).
  • Behandla transaktionen framgångsrikt. Gå till sidan Beställningsbekräftelse.
  • Transaktionsfel (även om detta är negativ testning, bör det betraktas som ett stort scenario).
  • Använd kuponger:
    • Giltiga kuponger - framgång. Kontrollera här ändringen av det belopp som ska faktureras.
    • Ogiltiga kuponger - misslyckande
  • Utgångna kuponger - misslyckande.
  • Gå tillbaka till sidan Kontoinformation.

Granska godkännandetester

Granskning av acceptantest är en viktig uppgift eftersom den måste vara korrekt och punktlig i förhållande till affärsbehovet. Eftersom dessa kan genomföras av kunderna själva och / eller slutanvändare är det mycket nödvändigt att vara fullständig, tvetydig, korrekt och detaljerad nog för att någon ska kunna förstå och utföra.

Granskning av acceptantest måste göras av affärsanalytiker, kunder och eventuella granskningskommentarer bör införlivas med hög prioritet.

På individuell testnivå bör granskningen göras mot nedanstående:

  • Oavsett om testet täcker företagets krav eller inte.
  • Är förutsättningarna klara?
  • Är teststegen lätta att förstå och detaljerade?
  • Är det förväntade resultatet korrekt och tydligt?
  • Kartläggs det till företagets krav på spårbarhet?
  • Är testet tillräckligt komplett för att täcka det specifika flödet eller användningen?
  • Krävs det specifika testet som en del av godkännandeprovningen.
  • Finns det någon verifieringspunkt som inte behövs för godkännandeprovning.
  • Är det rent funktionellt eller är något GUI täckt av det (det ska bara vara funktionellt).
  • Är den speciella inmatningsdata nödvändig? Om ja, tillhandahålls det för uppgifter?

På det hela taget bör hela granskningen av Acceptance-testerna omfatta:

  • Dubbelriktad spårbarhet: Affärskrav för tester OCH tester för företagskrav.
  • Täcks varje affärsbehov?
  • Täcks varje affärsbehov av ett eller flera tester?
  • Täcks affärsreglerna?
  • Behandlas det speciella datafallen?
  • Hur många tester skrivs för att täcka varje krav eller regel?
  • Kan testerna grupperas tillsammans och klassificeras för flöden.
  • Är sekvenserna ordentligt ordnade så att utförandet är effektivt?

Slutsats

I ett nötskal, som tidigare nämnts, spelar dokument en mycket drastisk roll i Acceptance testing.

Därför bör alla godkännandeprov som skrivs vara välstrukturerade och följa dess användning, så att det håller acceptantestarna att vara intresserade av vad de testar och hur de gör det. Detta skulle i sin tur automatiskt leda till framgång.

=> Besök här för en komplett testplan-handledningsserie

Föregående handledning | NÄSTA självstudie

Håll dig uppdaterad och se upp den kommande Acceptance Testing-guiden för att veta mer om Acceptance Testing Reports tillsammans med några generiska mallar. Låt oss också veta om du har några frågor.

Rekommenderad läsning

^