Wat is User Acceptance Testing (UAT): een complete gids

Leer wat is User Acceptance Testing (UAT) , Samen met de definitie, typen, stappen en voorbeelden:

Mijn regel nummer één wanneer ik een nieuw concept probeer te begrijpen, is dat: de naam altijd relevant zal zijn en meestal een letterlijke betekenis heeft (in de technische context).

Als je erachter komt wat dat is, krijg je er een eerste begrip van en kan ik ermee aan de slag.

= > Klik hier voor een complete serie testplannen met tutorials

Laten we dit concept testen.

= > Lees alle tutorials in onze Acceptance Testing-serie.

Wat is User Acceptance Testing?

We weten wat testen is, acceptatie betekent goedkeuring of overeenkomst. De gebruiker in de context van een softwareproduct is ofwel de gebruiker van de software of de persoon die verzocht heeft om het voor hem / haar (cliënt) te bouwen.

Dus, volgens mijn regel – de definitie zal zijn :

User Acceptance Testing (UAT), ook wel bèta- of eindgebruikerstest genoemd, wordt gedefinieerd als het testen van de software door de gebruiker of klant om te bepalen of deze kan worden geaccepteerd of niet. Dit is de laatste test die wordt uitgevoerd nadat de functionele, systeem- en regressietests zijn voltooid.

Het belangrijkste doel van deze test is om de software te valideren tegen de zakelijke vereisten. Deze validatie wordt uitgevoerd door de eindgebruikers die bekend zijn met de zakelijke vereisten.

UAT-, alfa- en bètatests zijn verschillende soorten acceptatietests.

Aangezien de gebruikersacceptatietest de laatste test is die wordt uitgevoerd voordat de software live gaat, is dit uiteraard de laatste kans voor de klant om de software te testen en te meten of deze geschikt is voor het doel.

Wanneer wordt het uitgevoerd?

Dit is doorgaans de laatste stap voordat het product live gaat of voordat de levering van het product is geaccepteerd. Dit wordt uitgevoerd nadat het product zelf grondig is getest (dwz na systeemtest).

Wie voert UAT uit?

Gebruikers of klant – Dit kan iemand zijn die een product koopt ( in het geval van commerciële software) of iemand die software op maat heeft laten bouwen via een softwareprovider of de eindgebruiker als de software van tevoren aan hen ter beschikking wordt gesteld en wanneer hun feedback wordt gevraagd.

Het team kan bestaan uit bètatesters of de klant moet intern UAT-leden selecteren uit elke groep van de organisatie, zodat elke gebruikersrol dienovereenkomstig kan worden getest.

Need For User Acceptance Testing

Ontwikkelaars en functionele testers zijn technische mensen die de software valideren aan de hand van de functionele specificaties. Ze interpreteren de vereisten op basis van hun kennis en ontwikkelen / testen de software (hier is het belang van domeinkennis).

Deze software is compleet volgens de functionele specificaties, maar er zijn enkele zakelijke vereisten en processen die die alleen bekend zijn bij de eindgebruikers worden ofwel gemist om te communiceren of worden verkeerd geïnterpreteerd.

Deze tests spelen een belangrijke rol bij het valideren of aan alle zakelijke vereisten is voldaan of niet voordat de software wordt vrijgegeven voor marktgebruik. Door het gebruik van live data en echte use cases is dit testen een belangrijk onderdeel van de releasecyclus.

Veel bedrijven die grote verliezen hebben geleden als gevolg van post-release issues, weten hoe belangrijk een succesvolle User Acceptance Test is. De kosten voor het repareren van de defecten na de release zijn vele malen hoger dan het voorheen repareren.

Is UAT echt nodig?

Na het uitvoeren van veel systeem-, integratie- en regressietests zou je je afvragen de noodzaak van dit testen. Eigenlijk is dit de belangrijkste fase van het project, aangezien dit het moment is waarop de gebruikers die het systeem daadwerkelijk gaan gebruiken, het systeem zouden valideren op zijn geschiktheid voor het beoogde doel.

UAT is een test fase die grotendeels afhangt van het perspectief van de eindgebruikers en de domeinkennis van een afdeling die de eindgebruikers vertegenwoordigt.

In feite zou het voor de bedrijfsteams echt nuttig zijn als ze waren al vrij vroeg bij het project betrokken, zodat ze hun mening en bijdragen konden geven die een effectief gebruik van het systeem in de echte wereld zouden helpen.

Testproces voor gebruikersacceptatie

Het De eenvoudigste manier om dit proces te begrijpen, is door dit te beschouwen als een autonoom testproject – wat betekent dat het de plan-, ontwerp- en uitvoeringsfasen zal hebben.

Hieronder volgen de vereisten vóór de planningsfase begint:

# 1) Verzamel de belangrijkste acceptatiecriteria

In eenvoudige bewoordingen is acceptatiecriteria een lijst van deze ngs die worden geëvalueerd voordat het product wordt geaccepteerd.

Dit kunnen 2 typen zijn:

(i) Applicatiefunctionaliteit of Zakelijk gerelateerd

Idealiter zouden alle belangrijke bedrijfsfunctionaliteit gevalideerd moeten worden, maar vanwege Om verschillende redenen, waaronder tijd, is het niet praktisch om alles te doen. Daarom kan een ontmoeting of twee met de klant of de gebruikers die bij deze tests betrokken zullen worden, ons een idee geven van hoeveel tests er nodig zullen zijn en welke aspecten zullen worden getest.

(ii) Contractueel – We gaan hier niet op in en de betrokkenheid van het QA-team bij dit alles is bijna niets. Het eerste contract dat wordt opgesteld nog voordat de SDLC begint, wordt herzien en er wordt overeenstemming bereikt over de vraag of alle aspecten van het contract zijn geleverd of niet.

We gaan ons alleen richten op de functionaliteit van de applicatie .

# 2) Bepaal de reikwijdte van QA-betrokkenheid.

De rol van het QA-team is een van de volgende:

(i) Geen betrokkenheid – dit is zeer zeldzaam.

(ii) Assisteren bij deze tests – De meeste gemeenschappelijk. In dit geval zou onze betrokkenheid kunnen bestaan uit het trainen van de UAT-gebruikers in het gebruik van de applicatie en stand-by staan tijdens deze tests om ervoor te zorgen dat we de gebruikers kunnen helpen in geval van problemen. Of in sommige gevallen, naast het feit dat we stand-by staan en assisteren, kunnen we hun antwoorden delen en de resultaten registreren of bugs registreren enz., Terwijl de gebruikers de daadwerkelijke tests uitvoeren.

(iii) Voer UAT uit en huidige resultaten – Als dit het geval is, zullen de gebruikers de gebieden van de AUT aanwijzen die ze willen evalueren en de evaluatie zelf wordt uitgevoerd door het QA-team. Eenmaal gedaan, worden de resultaten gepresenteerd aan de klanten / gebruikers en zullen ze een beslissing nemen of de resultaten die ze in handen hebben voldoende zijn of niet en in overeenstemming met hun verwachtingen om de AUT te accepteren. De beslissing is nooit die van het QA-team.

Afhankelijk van het geval, beslissen we welke aanpak het beste is.

De primaire doelstellingen en verwachtingen:

Gewoonlijk wordt de UAT uitgevoerd door een Subject Matter Expert (MKB) en / of een zakelijke gebruiker, die mogelijk de eigenaar of klant is van een te testen systeem. Net als bij de systeemtestfase, omvat de UAT-fase ook religieuze fasen voordat deze wordt afgesloten.

De belangrijkste activiteiten van elke UAT-fase worden hieronder gedefinieerd:

UAT Governance

Net als bij systeemtesten, wordt effectief bestuur afgedwongen voor UAT om ervoor te zorgen dat sterke kwaliteitspoorten samen met de gedefinieerde ingangs- en uitgangscriteria (hieronder vermeld **).

** Houd er rekening mee dat dit zo is slechts een richtlijn. Dit kan worden aangepast op basis van de projectbehoeften en -vereisten.

UAT-testplanning

Het proces is bijna hetzelfde als bij het reguliere testplan in de systeemfase.

De meest gebruikelijke benadering die in de meeste projecten wordt gevolgd, is om zowel de systeem- als de UAT-testfase samen te plannen. Voor meer informatie over het UAT-testplan, samen met een voorbeeld, kunt u de UAT-secties van het bijgevoegde testplan-document raadplegen.

Testplan voor gebruikersacceptatie

(Dit is hetzelfde dat u zou doen vind ook op onze site voor de QA-trainingsserie).

Klik op de onderstaande afbeelding en scroll naar beneden om het voorbeeld van het testplan-document in verschillende formaten te vinden. Controleer in dat sjabloon de sectie UAT.

De datums, omgeving, actoren (wie), communicatieprotocollen, rollen en verantwoordelijkheden, sjablonen, resultaten en hun analyseproces, entry-exit-criteria – allemaal dit en al het andere dat relevant is, vindt u in het UAT-testplan.

Of het QA-team nu deelneemt, gedeeltelijk of helemaal niet deelneemt aan deze test, het is onze taak om deze fase en zorg ervoor dat alles in overweging wordt genomen.

= > Hier is een voorbeelddocument van het testplan voor gebruikersacceptatie

Ontwerp van het testen van gebruikersacceptatie

De verzamelde acceptatiecriteria van de gebruikers worden in deze stap gebruikt. Voorbeelden kunnen er als volgt uitzien.

(Dit zijn fragmenten uit CSTE CBOK. Dit is een van de beste beschikbare referenties over dit testen.)

Sjabloon voor het testen van gebruikersacceptatie:

Op basis van de criteria geven wij (QA-team) de gebruikers een lijst met UAT-testgevallen. Deze testcases zijn niet anders dan onze reguliere systeemtestcases. Ze zijn slechts een subset, aangezien we alle applicaties testen in plaats van alleen de belangrijkste functionele gebieden.

Daarnaast zijn de gegevens, sjablonen om testresultaten vast te leggen, administratieve procedures, defectregistratiemechanisme, etc., moeten aanwezig zijn voordat we naar de volgende fase gaan.

Testuitvoering

Meestal, indien mogelijk, vinden deze tests plaats in een conferentie of een oorlogsruimte opgezet waar de gebruikers, PM, QA-teamvertegenwoordigers allemaal een dag of twee bij elkaar zitten en alle acceptatietestcases doorlopen.

Of in het geval dat het QA-team de tests uitvoert, voeren we de test uit zaken over de AUT.

Zodra alle tests zijn uitgevoerd en de resultaten bekend zijn, wordt de acceptatiebeslissing genomen. Dit wordt ook wel het Go / No-Go-besluit genoemd. Als de gebruikers tevreden zijn, is het een go, of anders een no-go.

Het bereiken van de acceptatiebeslissing is meestal het einde van deze fase.

Tools & Methodologieën

Doorgaans is het type softwaretools dat wordt gebruikt tijdens deze testfase vergelijkbaar met de tools die worden gebruikt tijdens het uitvoeren van functionele tests.

Tools:

Aangezien deze fase het valideren van de volledige end-to-end-stromen van de applicatie inhoudt, kan het moeilijk zijn om één tool te hebben om deze validatie volledig te automatiseren. Tot op zekere hoogte zouden we echter in staat zijn om gebruik te maken van de geautomatiseerde scripts die zijn ontwikkeld tijdens het testen van het systeem.

Net als bij systeemtesten zouden gebruikers ook testbeheer en defectbeheerprogrammas zoals QC, JIRA, enz. tools kunnen worden geconfigureerd om gegevens te verzamelen voor de gebruikersacceptatiefase.

Methodologieën:

Hoewel conventionele methodologieën zoals specifieke zakelijke gebruikers die UAT van het product uitvoeren nog steeds relevant zijn, in een werkelijk wereldwijde wereld zoals vandaag, moet bij het testen van gebruikersacceptatie soms verschillende klanten in verschillende landen betrokken zijn op basis van het product.

Een e-commerce website wordt bijvoorbeeld gebruikt door klanten over de hele wereld. In scenarios als deze zou crowdtesten de best haalbare optie zijn.

Crowd-testen is een methodologie waarbij mensen van over de hele wereld kunnen deelnemen en het gebruik van het product kunnen valideren en suggesties en aanbevelingen kunnen doen.

Crowd-testplatforms zijn gebouwd en worden nu door veel organisaties gebruikt. Een website of een product dat crowdtest moet worden, wordt gehost op het platform en de klanten kunnen zichzelf nomineren om de validatie uit te voeren. De gegeven feedback wordt vervolgens geanalyseerd en geprioriteerd.

De methodologie van Crowd Testing blijkt effectiever te zijn omdat de hartslag van de klant over de hele wereld gemakkelijk te begrijpen is.

UAT In Agile Environment

De agile omgeving is dynamischer van aard. In een wendbare wereld zullen zakelijke gebruikers tijdens de projectsprints worden betrokken en het project zou worden verbeterd op basis van de feedbackloops van hen.

Aan het begin van het project zouden zakelijke gebruikers de belangrijkste belanghebbenden zijn om voorzien in vereiste waardoor de productachterstand wordt bijgewerkt. Aan het einde van elke sprint zouden zakelijke gebruikers deelnemen aan de sprint-demo en beschikbaar zijn om feedback te geven.

Bovendien zou een UAT-fase worden gepland voordat de sprint is voltooid, waarin de zakelijke gebruikers hun validaties.

De feedback die wordt ontvangen tijdens de sprintdemo en sprint UAT, wordt verzameld en weer toegevoegd aan de product backlog die voortdurend wordt herzien en geprioriteerd. Dus in een agile wereld zijn de zakelijke gebruikers dichter bij het project en evalueren ze hetzelfde voor het gebruik ervan vaker in tegenstelling tot de traditionele watervalprojecten.

UAT Team – Rollen & Verantwoordelijkheden

Een typische UAT-organisatie zou de volgende rollen en verantwoordelijkheden hebben. Het UAT-team zou worden ondersteund door de projectmanager, ontwikkelings- en testteams op basis van hun behoeften.

7 uitdagingen van UAT En mitigatieplan

Het maakt niet uit of je deel uitmaakt van een release van een miljard dollar of een startup-team, je moet al deze uitdagingen overwinnen om succesvolle software voor de eindgebruiker te leveren.

# 1) Omgeving instellen en implementatieproces:

Het uitvoeren van deze test in dezelfde omgeving die wordt gebruikt door het functionele testteam zal zeker de praktijkgevallen over het hoofd zien. Bovendien kunnen cruciale testactiviteiten zoals prestatietests niet worden uitgevoerd op een testomgeving met onvolledige testgegevens.

Voor deze test moet een aparte productie-achtige omgeving worden opgezet.

Zodra de UAT-omgeving is gescheiden van de testomgeving, moet u de releasecyclus effectief beheersen. Ongecontroleerde release-cyclus kan leiden tot verschillende softwareversies in test- en UAT-omgeving. Waardevolle acceptatietesttijd wordt verspild als de software niet wordt getest op de nieuwste versie.

Ondertussen is de tijd die nodig is voor het opsporen van problemen met een onjuiste softwareversie hoog.

# 2) Test Planning:

Deze test moet worden gepland met een duidelijk acceptatietestplan in de vereistenanalyse en ontwerpfase.

Bij strategieplanning moet de set van praktijkvoorbeelden worden geïdentificeerd voor uitvoering. Het is erg belangrijk om de testdoelstellingen voor deze test te definiëren, aangezien een volledige testuitvoering niet mogelijk is voor grote applicaties in deze testfase. Testen moet worden uitgevoerd door eerst prioriteit te geven aan kritieke bedrijfsdoelstellingen.

Deze tests worden uitgevoerd aan het einde van de testcyclus. Het is duidelijk de meest kritieke periode voor de softwareversie. Vertraging in een van de voorgaande stadia van ontwikkeling en testen zal de UAT-tijd opeten.

Onjuiste testplanning leidt in het ergste geval tot een overlap tussen het testen van het systeem en de UAT. Door minder tijd en druk om deadlines te halen, wordt de software in deze omgeving ingezet, zelfs als de functionele tests niet zijn voltooid. De kerndoelen van deze test kunnen in dergelijke situaties niet worden bereikt.

Het UAT-testplan moet worden opgesteld en aan het team worden gecommuniceerd ruim voordat met deze test wordt begonnen. Dit zal hen helpen bij het plannen van testen, het schrijven van testcases & testscripts en het creëren van een UAT-omgeving.

# 3) Omgaan met nieuwe zakelijke vereisten als incidenten / defecten:

Onduidelijkheden in vereisten worden gevangen in de UAT-fase. UAT-testers vinden problemen die ontstaan als gevolg van onduidelijke vereisten (door te kijken naar de volledige gebruikersinterface die niet beschikbaar was tijdens het verzamelen van vereisten) en registreren deze als een defect.

De klant verwacht dat deze in de huidige release worden opgelost zonder rekening te houden met de tijd voor de wijzigingsverzoeken. Als er geen tijdige beslissing wordt genomen door het projectmanagement over deze last-minute wijzigingen, kan dit leiden tot het mislukken van de release.

# 4) Ongeschoolde testers of testers zonder zakelijke kennis:

Als er geen vast team is, selecteert het bedrijf UAT-personeel van verschillende interne afdelingen.

Zelfs als het personeel goed bekend is met de zakelijke behoeften, of als ze niet zijn opgeleid voor de nieuwe vereisten die worden ontwikkeld, kunnen ze geen effectieve UAT uitvoeren. Ook kan een niet-technisch zakelijk team veel technische problemen ondervinden bij het uitvoeren van de testcases.

Ondertussen voegt het toewijzen van testers aan het einde van de UAT-cyclus geen enkele waarde toe aan het project. Weinig tijd om het UAT-personeel te trainen kan de kans op UAT-succes aanzienlijk vergroten.

# 5) Onjuist communicatiekanaal:

Communicatie tussen ontwikkeling op afstand, testen en het UAT-team is moeilijker . E-mailcommunicatie is vaak erg moeilijk als u een offshore technisch team heeft. Een kleine onduidelijkheid in incidentrapporten kan de oplossing een dag vertragen.

Een goede planning en effectieve communicatie zijn cruciaal voor effectieve teamsamenwerking. Projectteams moeten een webgebaseerde tool gebruiken om defecten en vragen vast te leggen. Dit zal helpen om de werklast gelijkmatig te verdelen en dubbele problemen te voorkomen.

# 6) Functioneel testteam vragen om deze tests uit te voeren:

Er is geen slechtere situatie dan het vragen van de functionele test team om UAT uit te voeren.

Klanten schuiven hun verantwoordelijkheid af bij het testteam vanwege een gebrek aan middelen. In dergelijke gevallen komt het hele doel van deze tests in gevaar. Zodra de software live gaat, zullen de eindgebruikers snel de problemen ontdekken die door de functionele testers niet als real-world scenarios worden beschouwd.

Een oplossing hiervoor is om deze tests toe te wijzen aan toegewijde en ervaren mensen. testers met zakelijke kennis.

# 7) The Blame Game

Soms proberen zakelijke gebruikers redenen te vinden om de software te weigeren. Het kan hun eigenwaarde zijn om te laten zien hoe superieur ze zijn, of geef het ontwikkel- en testteam de schuld om respect te krijgen in het zakelijke team. Dit is zeer zeldzaam, maar gebeurt in teams met interne politiek.

Het is erg moeilijk om met dergelijke situaties om te gaan. Het opbouwen van een positieve relatie met het zakelijke team zou echter zeker helpen om het schuldspel te vermijden.

Ik hoop dat deze richtlijnen je zeker zullen helpen bij het uitvoeren van een succesvol gebruikersacceptatieplan door verschillende uitdagingen te overwinnen. Een goede planning, communicatie, uitvoering en een gemotiveerd team zijn de sleutels tot succesvolle gebruikersacceptatietests.

Systeemtest versus gebruikersacceptatietest

De betrokkenheid van het testteam begint al vrij vroeg in de project vanaf de fase van de vereistenanalyse.

Gedurende de hele levenscyclus van het project wordt er een soort validatie uitgevoerd voor het project, dwz statisch testen, unit testen, systeem testen, integratietesten, end-to-end testen of regressietesten. Dit geeft ons een beter begrip van de tests die zijn uitgevoerd in de UAT-fase en hoe verschillend deze is van de andere tests die eerder zijn uitgevoerd.

Hoewel we de verschillen zien in SIT en UAT, is het belangrijk dat we synergieën benutten maar behoud toch de onafhankelijkheid tussen beide fasen, wat een snellere time-to-market mogelijk zou maken.

Conclusie

# 1) UAT gaat niet over de paginas, velden of knoppen. De onderliggende veronderstelling, zelfs voordat deze test begint, is dat al die basisspullen worden getest en goed werken. God verhoede, de gebruikers vinden een bug zo basaal – het is heel slecht nieuws voor het QA-team. 🙁

# 2) Deze test gaat over de entiteit die het primaire element in het bedrijf is.

Laat me je een voorbeeld geven: Als de AUT een ticketingsysteem is, UAT gaat niet over het zoeken naar het menu dat een pagina opent, etc. Het gaat om de tickets en hun reservering, de staten die het kan nemen, de reis door het systeem, etc.

Een ander voorbeeld: als de site een autodealer is, dan ligt de focus op de “auto en de verkoop ervan” en niet echt op de site. Daarom is de kernactiviteit wat wordt geverifieerd en gevalideerd en wie kan dat beter doen dan de bedrijfseigenaren. Daarom is deze test het meest zinvol wanneer de klant er in grote mate bij betrokken is.

# 3) GAT is ook een vorm van testen in de kern, wat betekent dat er een goede kans is op het identificeren van enkele bugs in deze fase. Het gebeurt soms. Afgezien van het feit dat het een grote escalatie is voor het QA-team, betekenen de UAT-bugs meestal een vergadering om te zitten en te bespreken hoe ze als volgt kunnen worden aangepakt Bij deze tests is er meestal geen tijd om het probleem op te lossen en opnieuw te testen.

De beslissing zou zijn:

• Push de go-live-datum, los het probleem eerst op en vervolgens ga verder.
• Laat de bug zoals hij is.
• Beschouw het als een onderdeel van het wijzigingsverzoek voor toekomstige releases.

# 4) UAT is geclassificeerd als alfa- en bètatests, maar die classificatie is niet zo belangrijk in de context van typische softwareontwikkelingsprojecten in een servicegerichte industrie.

• Alfatesten is wanneer UAT wordt uitgevoerd in de omgeving van de softwarebouwer en is belangrijker in de context van commerciële off-the-shelf software.
• Beta testen is wanneer de UAT wordt uitgevoerd in de productieomgeving of de omgeving van de klant. Dit komt vaker voor bij klantgerichte applicaties. De gebruikers hier zijn de daadwerkelijke klanten zoals jij en ik in deze context.

# 5) Meestal wordt in een regulier softwareontwikkelingsproject de UAT uitgevoerd in de QA-omgeving als er is geen staging- of UAT-omgeving.

Kortom, de beste manier om erachter te komen of uw product acceptabel en geschikt is voor het beoogde doel, is door het daadwerkelijk aan de gebruikers voor te stellen.

Organisaties beginnen aan de Agile-manier van leveren, zakelijke gebruikers raken meer betrokken en de projecten worden verbeterd en opgeleverd via feedbackloops. Alles wat gedaan is, wordt de fase van gebruikersacceptatie beschouwd als de poort om in implementatie en productie te komen.

Wat was je UAT-ervaring? Stond u stand-by of heeft u voor uw gebruikers getest? Hebben de gebruikers problemen ontdekt? Zo ja, hoe ging u ermee om?

= > Lees hier ook ALLE tutorials in deze serie

= > Bezoek hier voor complete testplan-tutorialserie