Wat is het testen van gebruikersacceptatie (UAT): een complete gids

what is user acceptance testing

Lees wat gebruikersacceptatietesten (UAT) zijn, samen met de definitie, typen, stappen en voorbeelden:

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

Als u erachter komt wat dat is, krijgt u er een eerste begrip van en kan ik er mee aan de slag.

runtime polymorfisme in c ++

​ Klik hier voor een complete serie testplannen

Laten we dit concept testen.

​ Lees alle tutorials in onze serie Acceptatietests.

Wat je leert:

• Wat is het testen van gebruikersacceptatie?
  • Wanneer wordt het uitgevoerd?
  • Wie voert UAT uit?
  • Noodzaak voor het testen van gebruikersacceptatie
  • Testproces voor gebruikersacceptatie
  • UAT-beheer
  • UAT-testplanning
  • Testontwerp voor gebruikersacceptatie
  • Testuitvoering
  • Tools en methodologieën
  • UAT in een Agile-omgeving
  • UAT-team - Rollen en verantwoordelijkheden
• 7 uitdagingen van UAT en mitigatieplan
• Systeemtesten versus gebruikersacceptatietesten
• Gevolgtrekking
  • Aanbevolen literatuur

Wat is het testen van gebruikersacceptatie?

Wij weten wat testen is, acceptatie betekent goedkeuring of overeenkomst. De gebruiker in de context van een softwareproduct is ofwel de consument van de software, ofwel degene die verzocht heeft om deze voor hem / haar (opdrachtgever) 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 tests is om de software te valideren op basis van de zakelijke vereisten. Deze validatie wordt uitgevoerd door de eindgebruikers die bekend zijn met de zakelijke vereisten.

UAT, alfa- en bètatesten zijn verschillende soorten acceptatietesten.

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 wordt geaccepteerd. Dit wordt uitgevoerd nadat het product zelf grondig is getest (d.w.z. na systeemtesten ​

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 softwareleverancier of de eindgebruiker als de software aan hen ter beschikking wordt gesteld van tevoren 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.

Noodzaak voor het testen van gebruikersacceptatie

Ontwikkelaars en functionele testers zijn technische mensen die de software valideren tegen 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 alleen bekend zijn bij de eindgebruikers, worden 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 real use cases is dit testen een belangrijk onderdeel van de releasecyclus.

Veel bedrijven die grote verliezen hebben geleden als gevolg van problemen na de release, kennen het belang van een succesvolle User Acceptance Test. De kosten voor het herstellen van de defecten na het loslaten zijn vele malen hoger dan het herstellen ervan.

Is UAT echt nodig?

Na het uitvoeren van een heleboel systeem-, integratie- en regressietests zou men zich afvragen of deze tests noodzakelijk zijn. Dit is eigenlijk de belangrijkste fase van het project, aangezien dit het moment is waarop de gebruikers die het systeem daadwerkelijk gaan gebruiken, het systeem zouden valideren voor zijn geschiktheid voor het beoogde doel.

UAT is een testfase 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 al vrij vroeg bij het project betrokken waren, zodat ze hun mening en bijdragen kunnen geven die een effectief gebruik van het systeem in de echte wereld zouden helpen.

Testproces voor gebruikersacceptatie

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 voordat de planningsfase begint:

# 1) Verzamel de belangrijkste acceptatiecriteria

In eenvoudige bewoordingen zijn acceptatiecriteria een lijst met dingen die zullen worden geëvalueerd voordat het product wordt geaccepteerd.

Dit kunnen 2 soorten zijn:

(i) Toepassingsfunctionaliteit of bedrijfsgerelateerd

Idealiter zouden alle belangrijke zakelijke functies gevalideerd moeten worden, maar 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 oorspronkelijke 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 opgeleverd of niet.

We gaan ons alleen richten op de toepassingsfunctionaliteit.

# 2) Bepaal de reikwijdte van QA-betrokkenheid.

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

(i) Geen betrokkenheid - Dit is erg zeldzaam.

(ii) Helpen bij dit testen - Meest voorkomende. 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 GAT uit en presenteer resultaten - Als dit het geval is, zullen de gebruikers de gebieden van de AUT aanwijzen die ze willen evalueren en wordt de evaluatie zelf 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 belangrijkste 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-beheer

Net als bij systeemtesten, wordt effectief bestuur afgedwongen voor UAT om te zorgen voor sterke kwaliteitspoorten, samen met de gedefinieerde criteria voor binnenkomst en vertrek (hieronder vermeld **).

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

UAT-testplanning

Het proces is bijna hetzelfde als bij de regelmatig 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. Raadpleeg voor meer informatie over het UAT-testplan en een voorbeeld de UAT-secties in het bijgevoegde testplan-document.

Testplan voor gebruikersacceptatie

(Dit is hetzelfde dat u op onze site ook zou vinden voor de QA-trainingsreeks).

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 UAT-sectie.

De data, omgeving, actoren (wie), communicatieprotocollen, rollen en verantwoordelijkheden, sjablonen, resultaten en hun analyseproces, entry-exit-criteria - dit alles en al het andere dat relevant is, zal worden gevonden 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 te plannen en ervoor te zorgen dat alles in overweging wordt genomen.

​ Hier is een voorbeelddocument van een testplan voor gebruikersacceptatie

Testontwerp voor gebruikersacceptatie

De verzamelde acceptatiecriteria van de gebruikers worden in deze stap gebruikt. Monsters kunnen eruitzien zoals hieronder weergegeven.

(Dit zijn fragmenten uit CSTE CBOK ​Dit is een van de beste beschikbare referenties over deze tests.)

Testsjabloon voor 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 moeten de gegevens, sjablonen om testresultaten vast te leggen, administratieve procedures, defectregistratiemechanisme, enz. Aanwezig zijn voordat we naar de volgende fase gaan.

Testuitvoering

Gewoonlijk gebeurt dit testen, indien mogelijk, in een conferentie of een soort opstelling van een oorlogskamer waar de gebruikers, PM, vertegenwoordigers van het QA-team allemaal een dag of twee bij elkaar zitten en alle acceptatietestgevallen doorlopen.

Of in het geval dat het QA-team de tests uitvoert, draaien we de testcases op de AUT.

Zodra alle tests zijn uitgevoerd en de resultaten beschikbaar zijn, wordt het Acceptatiebesluit is gemaakt. Dit wordt ook wel het Go / No-Go-beslissing ​Als de gebruikers tevreden zijn, is het een Go, of anders is het een No-go.

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

Tools en methodologieën

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

Gereedschap:

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 kunnen we echter gebruikmaken van de geautomatiseerde scripts die zijn ontwikkeld tijdens systeemtests.

Net als bij systeemtesten, zouden gebruikers ook een testmanagement- en defectmanagementtool zoals QC, JIRA, enz. Gebruiken. Deze 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, moet in een werkelijk globale wereld zoals vandaag, bij het testen van gebruikersacceptatie soms verschillende klanten uit verschillende landen worden betrokken op basis van het product.

Bijvoorbeeld​ een e-commerce website zou door klanten over de hele wereld worden gebruikt. In scenario's als deze zou crowdtesting de best haalbare optie zijn.

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

Crowd-testplatforms worden 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 kan worden begrepen.

UAT in een Agile-omgeving

De agile omgeving is dynamischer van aard. In een agile wereld zullen zakelijke gebruikers worden betrokken tijdens de projectsprints 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 te voorzien in vereisten, waardoor de productachterstand wordt bijgewerkt. Aan het einde van elke sprint namen zakelijke gebruikers deel aan de sprint-demo en waren ze beschikbaar om feedback te geven.

beste externe desktopsoftware voor Windows

Bovendien zou een UAT-fase worden gepland vóór de voltooiing van de sprint, waarin de zakelijke gebruikers hun validaties zouden doen.

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 en 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 u deel uitmaakt van een release van een miljard dollar of een startup-team, u 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 in een testomgeving met onvolledige testgegevens ​

Voor deze test dient een aparte productie-achtige omgeving te worden ingericht.

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 op de nieuwste versie wordt getest.

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

# 2) Testplanning:

Deze test moet worden gepland met een duidelijk acceptatietestplan in de behoefteanalyse 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 toepassingen in deze testfase. Testen moet worden uitgevoerd door eerst prioriteit te geven aan kritieke bedrijfsdoelstellingen.

Dit testen wordt 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.

Een 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 tests 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 en 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. Indien er niet tijdig een besluit 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:

arrays gebruiken in functies c ++

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 waarde toe aan het project. Weinig tijd om het UAT-personeel op te leiden kan de kans op UAT-succes aanzienlijk vergroten.

# 5) Onjuist communicatiekanaal:

Communicatie tussen ontwikkeling, testen en het UAT-team op afstand 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 test uit te voeren:

Er is geen ergere situatie dan het functionele testteam te vragen om UAT uit te voeren.

Klanten schuiven hun verantwoordelijkheid af bij het testteam vanwege een gebrek aan middelen. Het hele doel van deze tests komt in dergelijke gevallen in het gedrang. Zodra de software live gaat, zullen de eindgebruikers snel de problemen ontdekken die door de functionele testers niet als echte scenario's worden beschouwd.

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

# 7) Het schuldspel

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 om een ​​succesvol plan voor gebruikersacceptatie uit te voeren door verschillende uitdagingen te overwinnen. Een goede planning, communicatie, uitvoering en gemotiveerd team zijn de sleutels tot succesvolle gebruikersacceptatietests.

Systeemtesten versus gebruikersacceptatietesten

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

Gedurende de hele levenscyclus van het project wordt een soort validatie uitgevoerd voor het project, d.w.z. 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 in SIT en UAT zien, is het belangrijk dat we synergieën benutten, maar toch de onafhankelijkheid tussen beide fasen behouden, wat een snellere time-to-market mogelijk zou maken.

Gevolgtrekking

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

#twee) Dit testen gaat over de entiteit die het primaire element in het bedrijf is.

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

Een ander Voorbeeld, als de site een autodealer is, dan ligt de focus op de 'auto en zijn verkoop' en niet echt op de site. Daarom is de kernactiviteit wat wordt geverifieerd en gevalideerd en wie dit beter kan doen dan de bedrijfseigenaren. Daarom is deze test het meest zinvol als de klant er voor een groot deel bij betrokken is.

# 3) UAT is ook een vorm van testen in de kern, wat betekent dat er in deze fase een goede kans is om enkele bugs te identificeren ​Het komt wel eens voor. 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 moeten worden afgehandeld, aangezien er na deze test meestal geen tijd is om te repareren en opnieuw te testen.

De beslissing zou zijn:

• Druk op de go-live-datum, los het probleem eerst op en ga dan 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.

• Alfa-testen is wanneer UAT wordt uitgevoerd in de omgeving van de softwarebouwer en belangrijker is in de context van commerciële standaardsoftware.
• Beta testen is wanneer de GAT 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 UAT in een regulier softwareontwikkelingsproject uitgevoerd in de QA-omgeving als er geen staging- of UAT-omgeving is.

In het kort, 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 met 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 uw 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 een complete serie testplannen

Aanbevolen literatuur

• Alfatesten en bètatesten (een complete gids)
• Wat is acceptatietesten (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)
• GUI-testhandleiding: een complete gebruikersinterface (UI) testhandleiding