Wat is acceptatietesten (een complete gids)

what is acceptance testing

Inleiding tot acceptatietesten (deel I):

In deze tutorialserie leer je:

1. Wat is acceptatietesten
2. Acceptatietests en testplan
3. Acceptatietests Status- en overzichtsrapporten
4. Wat is User Acceptance Testing (UAT)

Bent u klaar met systeemtesten? Zijn de meeste van uw bugs verholpen? Zijn de bugs geverifieerd en gesloten? Dus wat nu?

De volgende in de lijst is acceptatietesten, de laatste fase van het softwaretestproces ​ Dit is de fase waarin de klant beslist Wel of niet doorgaan voor het product en moet verplicht worden gevolgd voordat het product op de markt wordt gebracht. De gezamenlijke inspanningen van het ontwikkelingsteam en het testteam worden beloond door de klant door het ontwikkelde product te accepteren of af te wijzen.

Deze unieke tutorial over acceptatietesten geeft je op een eenvoudige en gemakkelijke manier een compleet overzicht van de betekenis, typen, toepassingen en verschillende andere factoren die betrokken zijn bij acceptatietesten voor een beter begrip.

Wat je leert:

• Wat is acceptatietesten?
• Waarom acceptatietests?
• Soorten
  • # 1) Testen van gebruikersacceptatie (UAT)
  • # 2) Business Acceptance Testing (BAT)
  • # 3) Contractacceptatietesten (CAT)
  • # 4) Regelgeving / Compliance Acceptance Testing (RAT)
  • # 5) Operationele acceptatietests (OAT)
  • # 6) Alfatesten
  • # 7) Beta-testen / veldtesten
• Wie doet acceptatietesten?
• Kwaliteiten van acceptatietesters
• Gebruik
• Verschillen tussen systeemtesten, acceptatietesten en gebruikersacceptatietesten
• Acceptatietests
• Acceptatietestbed
• In- en uitstapcriteria voor AT
  • Toelatingscriteria
  • Criteria afsluiten
• Acceptatietestproces
• Succesfactoren voor deze test
• Gevolgtrekking
• Aanbevolen literatuur

Wat is acceptatietesten?

Zodra het Systeemtestproces wordt ingevuld door het testteam en afgetekend, het volledige product / applicatie wordt overgedragen aan de klant / enkele gebruikers van klanten / beide, om te testen op aanvaardbaarheid, dwz het product / de applicatie moet foutloos zijn in het voldoen aan zowel de kritische als belangrijke zakelijke vereisten. Ook worden end-to-end bedrijfsstromen geverifieerd op dezelfde manier als in een realtime scenario.

De productie-achtige omgeving zal de testomgeving zijn voor het accepteren van testen (gewoonlijk aangeduid als Staging, Pre-Prod, Fail-Over, UAT-omgeving).

Dit is een black-box testtechniek waarbij alleen de functionaliteit wordt geverifieerd om ervoor te zorgen dat het product voldoet aan de gespecificeerde acceptatiecriteria (geen kennis van ontwerp / implementatie nodig).

Waarom acceptatietests?

Hoewel de systeemtest met succes is afgerond, wordt de acceptatietest door de klant geëist. Tests die hier worden uitgevoerd, zijn repetitief, omdat ze zouden zijn behandeld in Systeemtests.

Waarom worden deze tests dan uitgevoerd door klanten?

Dit is zo omdat:

• Om vertrouwen te krijgen in het product dat op de markt komt.
• Om ervoor te zorgen dat het product werkt zoals het moet.
• Om ervoor te zorgen dat het product voldoet aan de huidige marktnormen en voldoende concurrerend is met de andere vergelijkbare producten op de markt.

Soorten

Er zijn verschillende soorten tests.

Weinigen van hen worden hieronder vermeld:

# 1) Testen van gebruikersacceptatie (UAT)

UAT is om te beoordelen of het product voor de gebruiker werkt, correct voor het gebruik. Specifieke eisen die vrij vaak door de eindgebruikers worden gehanteerd, worden primair uitgekozen voor testdoeleinden. Dit wordt ook wel End-User Testing genoemd.

De term “Gebruiker” duidt hier de eindgebruikers aan voor wie het Product / de applicatie bedoeld is en daarom wordt er getest vanuit het perspectief van de eindgebruiker en vanuit hun standpunt.

=> Ook Lezen: Wat is User Acceptance Testing (UAT)?

# 2) Business Acceptance Testing (BAT)

Dit is om te beoordelen of het product voldoet aan de zakelijke doelen en doeleinden of niet.

BAT richt zich voornamelijk op zakelijke voordelen (financiën) die behoorlijk uitdagend zijn vanwege de veranderende marktomstandigheden / voortschrijdende technologieën, zodat de huidige implementatie mogelijk veranderingen moet ondergaan die resulteren in extra budgetten.

hoe jar-bestand te openen met java runtime-omgeving

Zelfs het product dat aan de technische vereisten voldoet, kan om deze redenen niet voldoen aan de BAT.

# 3) Contractacceptatietesten (CAT)

Dit is een contract dat bepaalt dat zodra het Product live gaat, binnen een vooraf bepaalde periode, de acceptatietest moet worden uitgevoerd en dat het alle acceptatiegebruiksgevallen moet doorstaan.

Het contract dat hier wordt ondertekend, wordt genoemd als Service Level Agreement (SLA), die de voorwaarden omvat waarin de betaling alleen zal plaatsvinden als de productservices in overeenstemming zijn met alle vereisten, wat betekent dat aan het contract is voldaan.

Soms kan dit contract plaatsvinden voordat het product live gaat. Hoe dan ook, een contract moet goed worden gedefinieerd in termen van de testperiode, testgebieden, voorwaarden voor problemen die zich in latere stadia voordoen, betalingen, enz.

# 4) Regelgeving /NakomingAcceptatietest (RAT)

Dit is om te beoordelen of het product in strijd is met de regels en voorschriften die zijn gedefinieerd door de overheid van het land waar het wordt vrijgegeven. Dit kan onbedoeld zijn, maar heeft een negatieve invloed op het bedrijf.

Gewoonlijk moet het ontwikkelde product / de applicatie die bedoeld is om over de hele wereld te worden uitgebracht, RAT ondergaan, aangezien verschillende landen / regio's verschillende regels en voorschriften hebben die zijn gedefinieerd door de bestuursorganen.

Als een van de regels en voorschriften voor een land wordt overtreden, mag dat land of de specifieke regio in dat land het product niet gebruiken en wordt dit als een storing beschouwd. Verkopers van het product zijn rechtstreeks verantwoordelijk als het product wordt vrijgegeven, ook al is er sprake van een overtreding.

# 5) Operationele acceptatietests (OAT)

Dit is om de operationele gereedheid van het product te beoordelen en is een niet-functionele test. Het omvat voornamelijk het testen van herstel, compatibiliteit, onderhoudbaarheid, beschikbaarheid van technische ondersteuning, betrouwbaarheid, failover, lokalisatie enz.

OAT verzekert voornamelijk de stabiliteit van het product voordat het wordt vrijgegeven voor de productie.

# 6) Alfatesten

Dit is om het product in de ontwikkel- / testomgeving te beoordelen door een gespecialiseerd testerteam, gewoonlijk alfatesters genoemd. Hier helpen de feedback en suggesties van de testers om het gebruik van het product te verbeteren en ook om bepaalde bugs op te lossen.

Hier gebeurt het testen op een gecontroleerde manier.

=> Lees ook: Wat is alfatesten?

# 7) Beta-testen / veldtesten

Dit is bedoeld om het product te beoordelen door het bloot te stellen aan de echte eindgebruikers, meestal bètatesters / bètagebruikers genoemd, in hun omgeving. Er wordt continue feedback van de gebruikers verzameld en de problemen worden opgelost. Dit helpt ook bij het verbeteren / verbeteren van het product om een ​​rijke gebruikerservaring te bieden.

Het testen gebeurt op een ongecontroleerde manier, wat betekent dat een gebruiker geen beperkingen heeft op de manier waarop het product wordt gebruikt.

=> Lees ook: Wat is bètatesten?

Al deze soorten hebben een gemeenschappelijk doel:

• Zorg ervoor dat u het vertrouwen in het product wint / verrijkt.
• Zorg ervoor dat het product klaar is om door de echte gebruikers te worden gebruikt.

Wie doet acceptatietesten?

Voor het alfatype voeren alleen de leden van de organisatie (die het product hebben ontwikkeld) de tests uit. Deze leden maken niet direct deel uit van het project (Projectmanagers / leads, developers, testers). Management-, verkoop- en ondersteuningsteams voeren meestal de tests uit en geven dienovereenkomstig feedback.

Behalve het Alpha-type, worden alle andere acceptatietypes over het algemeen uitgevoerd door verschillende belanghebbenden. Zoals klanten, klanten van klanten, gespecialiseerde testers van de organisatie (niet altijd).

Het is ook goed om Business Analisten en Subject Matter Expertise te betrekken bij het uitvoeren van deze tests op basis van het type.

Kwaliteiten van acceptatietesters

Testers met onderstaande kwaliteiten worden gekwalificeerd als Acceptatietesters:

• Logisch en analytisch kunnen denken.
• Goede domeinkennis.
• In staat om de concurrerende producten op de markt te bestuderen en deze in het ontwikkelde product te analyseren.
• Perceptie van de eindgebruiker hebben tijdens het testen.
• Begrijp de zakelijke behoefte voor elke vereiste en test dienovereenkomstig.

Impact van problemen die tijdens deze test zijn gevonden

Eventuele problemen die zich voordoen in de acceptatietestfase moeten als een hoge prioriteit worden beschouwd en onmiddellijk worden opgelost. Dit vereist ook dat een Root Cause Analysis wordt uitgevoerd op elk probleem dat wordt aangetroffen.

Het testteam speelt een belangrijke rol bij het leveren van RCA's voor acceptatieproblemen. Deze helpen ook bij het bepalen hoe efficiënt het testen wordt uitgevoerd.

Ook zullen geldige problemen in de acceptatietest zowel de test- als de ontwikkelingsteam-inspanningen treffen in termen van indruk, beoordelingen, klantonderzoeken, enz. Soms, als er enige onwetendheid van het testteam over validaties wordt gevonden, leidt dit ook tot escalaties.

Gebruik

Deze test is nuttig vanuit verschillende aspecten.

Enkele daarvan zijn:

• Om de gemiste problemen tijdens de functionele testfase te achterhalen.
• Hoe goed het product is ontwikkeld.
• Een product is wat de klant eigenlijk nodig heeft.
• Uitgevoerde feedbacks / enquêtes helpen bij het verbeteren van de productprestaties en gebruikerservaring.
• Verbeter het proces dat wordt gevolgd door RCA's als input te hebben.
• Minimaliseer of elimineer de problemen die voortvloeien uit het productieproduct.

Verschillen tussen systeemtesten, acceptatietesten en gebruikersacceptatietesten

Hieronder staan ​​de belangrijkste verschillen tussen deze 3 soorten acceptatietests.

Acceptatietests

Net als bij producttestcases, hebben we acceptatietests. Acceptatietests zijn afgeleid van de acceptatiecriteria van User stories. Dit zijn meestal de scenario's die op hoog niveau worden geschreven en waarin wordt beschreven wat het product onder verschillende omstandigheden moet doen.

Het geeft geen duidelijk beeld over het uitvoeren van tests, zoals in testgevallen. Acceptatietests worden geschreven door testers die volledige grip hebben op het product, meestal Subject Matter Expertise. Alle geschreven tests worden beoordeeld door een klant en / of bedrijfsanalisten.

Deze tests worden uitgevoerd tijdens een acceptatietest. Naast acceptatietests moet er een gedetailleerd document worden opgesteld over alle uit te voeren instellingen. Het moet details van elke minuut bevatten met de juiste schermafbeeldingen, instellingswaarden, voorwaarden, enz.

Acceptatietestbed

Testbed voor deze test is vergelijkbaar met een gewone testbed, maar is een aparte. Platform met alle benodigde hardware, software, besturingsproducten, netwerkinstellingen en configuraties, serverinstellingen en configuraties, database-instellingen en configuraties, licenties, plug-ins, enz., Moeten op dezelfde manier worden opgezet de productieomgeving.

Acceptatietestbed is een platform / omgeving waar de ontworpen acceptatietesten zullen worden uitgevoerd. Voordat u de acceptatietestomgeving aan de klant overhandigt, is het een goede gewoonte om te controleren op eventuele milieukwesties en de stabiliteit van het product.

Als er geen aparte omgeving voor acceptatietesten is ingericht, kan daarvoor een reguliere testomgeving worden gebruikt. Maar hier wordt het rommelig omdat de testgegevens van reguliere systeemtests en de realtime gegevens van acceptatietests in één omgeving worden bewaard.

Acceptatietestbed wordt meestal aan de klantzijde (d.w.z. in het laboratorium) opgezet en heeft beperkte toegang tot de ontwikkel- en testteams.

Teams hebben toegang tot deze omgeving nodig via VM's / of specifiek ontworpen URL's met speciale toegangsreferenties, en alle toegang hiertoe wordt bijgehouden. Niets in deze omgeving hoeft te worden toegevoegd / gewijzigd / verwijderd zonder toestemming van de klant, en de klant moet op de hoogte worden gesteld van de aangebrachte wijzigingen.

In- en uitstapcriteria voor AT

Net als elke andere fase in de STLC, heeft acceptatietesten een set entry- en exitcriteria die goed moeten worden gedefinieerd in het acceptatietestplan (dat wordt behandeld in het laatste deel van deze tutorial).

Dit is de fase die begint direct na het testen van het systeem en eindigt voordat de productie wordt gestart. De exitcriteria van systeemtesten worden dus een onderdeel van de toegangscriteria voor AT. Evenzo worden de exitcriteria van AT een onderdeel van de toegangscriteria voor de productiestart.

Toelatingscriteria

Hieronder staan ​​de voorwaarden waaraan moet worden voldaan voordat u begint:

• Zakelijke vereisten moeten duidelijk en beschikbaar zijn.
• De systeem- en regressietestfase moeten worden voltooid.
• Alle kritieke, grote en normale bugs moeten worden opgelost en gesloten (kleine bugs die worden geaccepteerd, zijn voornamelijk cosmetische bugs die het gebruik van het product niet verstoren).
• De lijst met bekende problemen moet worden opgesteld en gedeeld met de belanghebbenden.
• Er moet een acceptatietestbed worden opgesteld en er moet een controle op hoog niveau worden uitgevoerd zonder milieuproblemen.
• De systeemtestfase moet worden afgetekend om het product naar de AT-fase te laten gaan (meestal gedaan via e-mailcommunicatie).

Criteria afsluiten

AT moet aan bepaalde voorwaarden voldoen om het product voor een productielancering te laten gaan.

Ze zijn als volgt:

• Acceptatietests moeten worden uitgevoerd en alle tests moeten slagen.
• Geen kritieke / grote defecten opengelaten. Alle defecten moeten onmiddellijk worden verholpen en geverifieerd.
• AT moet worden ondertekend door alle betrokken belanghebbenden Wel of niet doorgaan Besluit over het product.

Acceptatietestproces

In V-model , AT-fase loopt parallel aan de Requirements-fase.

Het werkelijke AT-proces verloopt zoals hieronder weergegeven:

Analyse van bedrijfsvereisten

Zakelijke vereisten worden geanalyseerd door alle beschikbare documenten binnen het project te raadplegen.

Enkele daarvan zijn:

• Specificaties systeemvereisten
• Document met zakelijke vereisten
• Gebruik cases
• Werkstroomdiagrammen
• Ontworpen datamatrix

Ontwerp Acceptatie Test Plan

Er zijn bepaalde items die in het acceptatietestplan moeten worden gedocumenteerd.

Laten we er een paar bekijken:

• Acceptatie Teststrategie en aanpak.
• In- en uitstapcriteria moeten goed worden gedefinieerd.
• De reikwijdte van AT moet goed worden vermeld en moet alleen betrekking hebben op de zakelijke vereisten.
• De ontwerpaanpak voor acceptatietests moet gedetailleerd zijn, zodat iedereen die tests schrijft gemakkelijk kan begrijpen op welke manier deze moet worden geschreven.
• Testbed opgezet, het actuele testschema / tijdlijnen moeten worden vermeld.
• Aangezien het testen wordt uitgevoerd door verschillende belanghebbenden, moeten details over logboekfouten worden vermeld, aangezien de belanghebbenden mogelijk niet op de hoogte zijn van de gevolgde procedure.

Acceptatietests ontwerpen en beoordelen

Acceptatietests moeten worden geschreven op een scenarioniveau waarin wordt vermeld wat er moet worden gedaan (niet in detail om op te nemen hoe te doen). Deze mogen alleen worden geschreven voor de geïdentificeerde toepassingsgebieden voor zakelijke vereisten, en elke test moet worden toegewezen aan de verwijzingsvereiste.

Alle schriftelijke acceptatietests moeten worden herzien om een ​​hoge dekking van zakelijke vereisten te bereiken.

Dit is om er zeker van te zijn dat er geen andere tests dan de genoemde scope bij betrokken zijn, zodat het testen binnen de geplande tijdlijnen valt.

Acceptatietestbed opgezet

Testbed moet op dezelfde manier worden opgezet als een productieomgeving. Controles op zeer hoog niveau zijn vereist om de stabiliteit en het gebruik van de omgeving te bevestigen. Deel de aanmeldingsgegevens om de omgeving alleen te gebruiken met een belanghebbende die deze test uitvoert.

Acceptatietestgegevens instellen

Productiegegevens moeten worden voorbereid / ingevuld als testgegevens in de systemen. Ook moet er een gedetailleerd document zijn zodat de gegevens gebruikt moeten worden voor testen.

Heb niet de testgegevens zoals TestName1, TestCity1, enz., In plaats daarvan Albert, Mexico, enz. Dit geeft een rijke ervaring met real-time gegevens en testen zullen up-to-the-point zijn.

Acceptatietest uitvoering

Ontworpen Acceptatietests moeten bij deze stap op de omgeving worden uitgevoerd. Idealiter zouden alle tests bij de eerste poging zelf moeten slagen. Er mogen geen functionele bugs zijn die voortvloeien uit Acceptatietests, indien aanwezig, en dan moeten ze met een hoge prioriteit worden gerapporteerd om te worden opgelost.

Nogmaals, opgeloste bugs moeten worden geverifieerd en gesloten als een taak met hoge prioriteit. Het testuitvoeringsrapport moet dagelijks worden gedeeld.

Bugs die in deze fase zijn geregistreerd, moeten worden besproken in een bug-triage-bijeenkomst en moeten de Root Cause Analysis-procedure ondergaan. Dit is het enige punt waarop acceptatietests beoordelen of aan alle zakelijke vereisten wordt voldaan door het product of niet.

Zakelijke beslissing

Er komt een Wel of niet doorgaan beslissing voor het product dat in Productie wordt gelanceerd. Gaan besluit zal ervoor zorgen dat het product op de markt wordt gebracht. Niet gaan beslissing markeert het product als mislukt.

Enkele factoren van een no-go-beslissing:

• Slechte kwaliteit van het product.
• Te veel open functionele bugs.
• Afwijking van zakelijke vereisten.
• Niet aan de marktnormen en moet worden verbeterd om aan de huidige marktnormen te voldoen.

Succesfactoren voor deze test

Zodra deze test is gepland, stelt u een checklist op die het slagingspercentage ervan verhoogt. Er zijn enkele actiepunten die moeten worden gevolgd voordat de acceptatietest begint.

Zij zijn:

• Zorg voor een goed gedefinieerde scope en zorg ervoor dat er een zakelijke behoefte is aan de scope die voor deze tests is vastgesteld.
• Voer acceptatietests in de systeemtestfase zelf minimaal één keer uit.
• Voer uitgebreid uit ad-hoc testen voor elk van de acceptatietestscenario's.

Gevolgtrekking

Kortom, acceptatietesten helpen bij het achterhalen van de efficiëntie van ontwikkel- en testteams.

Er zijn verschillende tools om deze activiteit uit te voeren, maar meestal heeft het de voorkeur om handmatig te worden gedaan, aangezien er een betrokkenheid is van de echte gebruikers en verschillende belanghebbenden die geen technische achtergrond hebben, en het is misschien niet haalbaar voor hen.

goede websites om gratis anime te kijken

Wat is het volgende?

In onze volgende tutorial gaan we over de onderstaande onderwerpen:

• Voorbeelden van acceptatietestcriteria.
• Hoe u een acceptatietestplan schrijft.
• Een geschikt sjabloon voor het schrijven van acceptatietests.
• Hoe acceptatietests te schrijven met voorbeelden.
• Acceptatietestscenario's identificeren.
• Acceptatietestrapporten.
• Acceptatietesten in Agile en testgestuurde ontwikkeling.

VOLGENDE Tutorial # 2: Acceptatietestplan

Heeft u een acceptatietest uitgevoerd? We horen graag uw ervaringen !!

Aanbevolen literatuur

• Alfatesten en bètatesten (een complete gids)
• Wat is het testen van gebruikersacceptatie (UAT): een complete gids
• Build Verification Testing (BVT Testing) Complete Guide
• Functioneel testen versus niet-functioneel testen
• Beste softwaretesttools 2021 (QA Test Automation Tools)
• Soorten softwaretests: verschillende testtypen met details
• ETL-testen Tutorial datawarehouse-testen (een complete gids)
• Handleiding voor het testen van webapplicaties