In dit artikel wordt uitgelegd wat de belangrijkste verschillen zijn tussen SIT en UAT. U leert ook over systeemintegratietests en gebruikersacceptatietestmethoden:
In het algemeen wordt het testen gedaan door zowel testers als ontwikkelaars. Ieder van hen volgt zijn eigen patroon om een applicatie te testen.
Systeem Integratie Testen of SIT wordt gedaan door testers terwijl Gebruikers Acceptatie Testen, algemeen bekend als UAT, als laatste wordt gedaan door de eindgebruikers. Dit artikel zal SIT en UAT in detail vergelijken en u helpen de belangrijkste verschillen tussen de twee te begrijpen.
Let’s Explore!!!
SIT Vs UAT: Overzicht
In het algemeen hebben de niveaus van testen de volgende hiërarchie:
- Unit-tests
- Component-tests
- Systeem-tests
- Systeemintegratietests
- Gebruikersacceptatietests
- Productie
Laten we de belangrijkste verschillen analyseren tussen Systeem Integratie Testen (SIT) en Gebruikers Acceptatie Testen (UAT).
Systeemintegratietesten (SIT)
Twee verschillende subsystemen/systemen zullen op een bepaald punt in elk project samenkomen. We moeten dit systeem dan testen als een geheel. Vandaar dat dit Systeem Integratie Testen wordt genoemd.
Werkstappen van SIT
- De afzonderlijke eenheden moeten eerst worden geïntegreerd in afzonderlijke builds.
- Het gehele systeem moet als een geheel worden getest.
- Testgevallen moeten worden geschreven met behulp van de juiste software op basis van de software-eisen.
- De fouten zoals UI fouten, data flow fouten, interface fouten kunnen worden gevonden in dit testen.
Exemplaar:
Laten we overwegen dat een gezondheidszorg site heeft 3 tabbladen aanvankelijk d.w.z. Patiënt Informatie, Onderwijs, Vorige medische dossiers. De zorgsite heeft nu een nieuw tabblad toegevoegd met de naam Injectie-informatie.
Nu moeten de gegevens of database van het nieuwe tabblad worden samengevoegd met de bestaande tabbladen en moet het systeem in zijn geheel worden getest met 4 tabbladen.
We moeten de geïntegreerde site testen die vier tabbladen heeft.
De geïntegreerde site ziet er ongeveer zo uit als hieronder getoond:
Technieken die bij SIT worden gebruikt
- Top-down-benadering
- Bottom-up-benadering
- Big bang-benadering
#1) Top-Down Approach
Zoals de naam zelf al aangeeft, betekent dit dat de uitvoering van boven naar beneden verloopt. Het is een methode waarbij de hoofdfunctionaliteit of module wordt getest, gevolgd door de submodules in volgorde. Hier rijst de vraag wat we doen als de opeenvolgende actuele sub-modules niet onmiddellijk aanwezig zijn voor integratie.
Het antwoord hierop geeft aanleiding tot STUBS.
Stubs staan bekend als zogenaamde programma’s. Zij fungeren als dummy modules en voeren de vereiste module functie op een beperkte manier uit.
Stubs voeren de functionaliteit van een unit/module/sub-module op een gedeeltelijke manier uit totdat de eigenlijke module klaar is voor integraties, omdat de integratie van sub-modules moeilijk is.
De low-level componenten kunnen worden vervangen door stubs om te integreren. De top-down benadering kan dus een gestructureerde of proceduretaal volgen. Nadat een stub is vervangen door de werkelijke component, kan de volgende stub worden vervangen door de werkelijke componenten.
De uitvoering van het bovenstaande diagram zal zijn module A, module B, module C, module D, module E, module F, module G.
Voorbeeld voor stubs:
#2) Bottom-Up Approach
Deze benadering volgt de hiërarchie van onder naar boven. Hierbij worden eerst de onderste modules geïntegreerd en vervolgens de hogere modules geïntegreerd en getest.
De onderste modules of units worden samengevoegd en getest. De set van lagere eenheden worden Clusters genoemd. Bij de integratie van de submodules met de hoofdmodule worden, indien de hoofdmodule niet beschikbaar is, de DRIVERS gebruikt om het hoofdprogramma te coderen.
DRIVERS worden aanroepende programma’s genoemd.
Defectlekkage is bij deze aanpak minder.
Om de submodules te integreren in een hoger niveau of hoofdmodule wordt een driver-module gemaakt zoals te zien is in de bovenstaande figuur.
#3) Big Bang-benadering
In eenvoudige woorden, in de Big Bang-benadering moet u alle eenheden in één keer aansluiten en alle componenten testen. Er wordt hier geen verdeling gemaakt. Defectlekkage mag niet optreden.
Deze aanpak is nuttig voor vers ontwikkelde projecten die vanaf nul zijn ontwikkeld of projecten die grote uitbreidingen hebben ondergaan.
User Acceptance Testing (UAT)
Wanneer een tester het voltooide geteste project aan de klant/eindgebruiker overhandigt, zal de klant/eindgebruiker het project opnieuw testen om te zien of het correct is ontworpen. Dit wordt User Acceptance Testing genoemd.
Er moeten voor beide geschikte testgevallen worden geschreven om het testen te kunnen uitvoeren.
De ontwikkelaars ontwikkelen een code op basis van het Functional Requirement Specification document. De testers testen deze en rapporteren bugs. Maar de klant of eindgebruiker weet alleen hoe het systeem precies werkt. Daarom testen zij het systeem vanaf hun kant.
Werkstappen van UAT
- Het UAT-plan moet worden gemaakt op basis van de requirements.
- De scenario’s moeten worden gebouwd op basis van de requirements.
- De testgevallen en testgegevens moeten worden voorbereid.
- De testgevallen moeten worden uitgevoerd en gecontroleerd op eventuele aanwezige bugs.
- Als er geen bug is en de testcases zijn geslaagd dan kan het project worden afgetekend en verzonden voor productie.
- Als er defecten of bugs worden gevonden dan moet het onmiddellijk worden opgelost om voor te bereiden voor release.
Types van UAT Testing
- Alpha en Beta Testing: Alfa-testen worden gedaan op de ontwikkellocatie terwijl beta-testen worden gedaan in een externe omgeving, d.w.z. een extern bedrijf etc.
- Contract Acceptatie Testen: In een contract moet worden voldaan aan de geaccepteerde specificaties die vooraf zijn vastgesteld.
- Regulation Acceptance Testing: Zoals de naam al zegt wordt er getoetst aan de regelgeving.
- Operational Acceptance Testing: De werking of de ontworpen workflow moet zijn zoals verwacht.
- Black Box Testing: Zonder diep in te gaan moet de software getest worden op zijn vitale doel.
Key Differences Between SIT Vs UAT
| SIT | UAT |
|---|---|
| Dit wordt uitgevoerd door testers en ontwikkelaars. | Dit wordt uitgevoerd door eindgebruikers en klanten. |
| Integratie van de subunits/eenheden wordt hier gecontroleerd. De interfaces worden getest. | Het gehele ontwerp wordt hier gecontroleerd. |
| Het systeem wordt als geheel getest op de hoofdfunctionaliteit van het product zoals de gebruiker die wenst. | |
| Het wordt gedaan op basis van het gebruikersperspectief hoe het product door de eindgebruiker moet worden gebruikt. | |
| UAT wordt tenslotte uitgevoerd vlak voor de productvrijgave. |
Conclusie
Systeemintegratietesten worden vooral gedaan om de interface-eisen van een systeem te testen. Gebruikers acceptatie testen worden gedaan om de functionaliteit van het systeem als geheel te verifiëren door een eindgebruiker. Voor beide testen moeten geschikte testgevallen worden geschreven.
SIT kan worden uitgevoerd met 3 technieken (Top-down, Bottom-up, en Big bang benaderingen). UAT kan worden gedaan met behulp van 5 methodologieën (Alpha en Beta testen, Contract Acceptatie testen, Regelgeving Acceptatie testen, Operationele Acceptatie testen, en Black box testen).
Defecten gevonden tijdens het testen van het systeem kunnen gemakkelijk worden gecorrigeerd. Verschillende builds kunnen worden gemaakt op basis van gebreken. Terwijl defecten gevonden in UAT worden beschouwd als een zwarte vlek voor de testers en worden niet geaccepteerd.
In UAT de zakelijke functionarissen of klanten moeten tevreden zijn dat het ontwikkelde product voldoet aan hun behoeften in de zakelijke omgeving. SIT moet voldoen aan de functionele eisen van het systeem.
We hopen dat dit artikel al uw vragen over SIT Vs UAT heeft verduidelijkt!!