Herproefopstelling Tutorial: Een uitgebreid Handboek met Voorbeelden en Beste Praktijken

Retesten is een proces van valideren van een specifieke functie waarvan de werking tijdens de vorige test faalde. Het wordt gedaan om te verifiëren of de testgevallen die tijdens de uitvoeringsperiode met bepaalde fouten zijn gerapporteerd, zijn opgelost.

In het software ontwikkelingslevenloop, zijn de belangrijkste cruciale elementen het testen van de functionaliteit, prestaties, beveiliging en andere aspecten van de software, waarbij de software wordt gecontroleerd op eventuele fouten. Echter, de grootste uitdaging is het valideren van de werking van de software in lijn met het doelpubliek. Het is cruciaal om de effectiviteit en betrouwbaarheid van de ontwikkelde software te waarborgen, en hier duikt retesten op als de redder.

Het primaire doel van software testen is het identificeren van de fout of bugs in de software applicatie. Testingenineurs zijn verantwoordelijk voor het bepalen van die en rapporteren aan het ontwikkelingsteam voor verdere evaluatie. Vervolgens worden zulke problemen opgelost en teruggestuurd naar de testingenieur voor herverificatie.

Retests zorgen ervoor dat geen extra problemen optreden tijdens de software release. Zo’n proces kan handmatig worden uitgevoerd met behulp van een specifieke testgevallenset. Ook al is er sprake van complexiteit bij retests, we moeten dit begrijpen als de basisdeel van software testen om hoogwaardige producten af te leveren.

Wat Is Retesten?

Je moet gewend zijn aan het feit dat het vinden van bugs tijdens het testen van de software de taakrol is van testingenineurs. Onder zulke ondernemingen zijn ze verantwoordelijk voor het repareren en het terugsturen van de fout of het probleem naar de ontwikkelaars, waarbij ze ervoor zorgen dat zulke fout of probleem wordt opgelost. Hier komt retesten. Laten we dit duidelijker begrijpen.

Bij softwareontwikkeling is retesten het proces om een door ontwikkelaars verstrekte build te valideren om ervoor te zorgen dat de fout is gefixt. In eenvoudige termen, stel dat je software test die “Build Number 1” is, en als er een fout wordt aangetroffen, is de ID bijvoorbeeld A1. Vervolgens test de tester zo’n fout en wordt het “Build Number 2” genoemd.

Met andere woorden, de fout die is geïdentificeerd in Build Number 1 wordt opnieuw getest in Build Number 2 om te controleren of de ontwikkelaar de fout heeft gefixt. De tester retest hier de mislukte gevallen om de oplossing die door de ontwikkelaars is gedaan te valideren.

Het maakt deel uit van het defectlevenscyclus waarbij het testen van mislukte testgevallen wordt uitgevoerd, die ten tijde van de eerdere test niet-functioneel was gefixt door ontwikkelaars.

Volg deze punten voor meer informatie over een retestproces:

• Mislukte testgevallen die corresponderen met gerapporteerde fouten worden opnieuw getest.
• Een andere naam voor retesten is bevestigingstesten.
• Voor de gerapporteerde fout in de nieuwe build, moeten soortgelijke testgegevens en processen worden gebruikt om de reproduceerbaarheid ervan te valideren.

A comprehensive example of the retest process will help you get a clearer picture.

Waarom is Retesten Belangrijk?

Retesten als onderdeel van het softwaretestlevenscyclus omvat verschillende betekenissen met betrekking tot de effectieve levering van het product. Het is ongetwijfeld het belangrijkste onderdeel van het standaardsoftwaretestproces. Maar bovendien biedt het het product een extra laag van zekerheid, waarbij zowel de technische als functionele prestaties worden gecontroleerd voordat het wordt vrijgegeven aan de eindgebruikers.

Bedrijven moeten hoogwaardige digitale applicaties garanderen in deze sterk concurrerende softwareontwikkelingsmarkt. Dit vereist geen compromis in de kwaliteit van het eindproduct.

Automatiseringstestplatforms kunnen vaak helpen je een betere ROI te realiseren voor je vrijgegeven product. Een retest geeft echter meer vertrouwen door elke bug te verifiëren. In vergelijking met het initiële testproces, voegt het geen extra kosten toe aan testbronnen of brengt het grote tijdsinvesteringen met zich mee. Het is bekend dat het uitgevoerd wordt in dezelfde omgeving met soortgelijke gegevens die verband houden met mislukte testgevallen.

Bovendien richt het retestproces zich op specifieke problemen of bugs die zijn genoteerd in specifieke applicatiemodules. Daarom hoef je geen nieuwe testomgeving op te zetten en meer moeite te doen om de kwaliteit van het product te verifiëren met end-to-end testing.

Voorbeeld van Retest

Hoewel het bovenstaande voorbeeld je oppervlakkige informatie kan geven, gaan we hieronder met een vergelijkbaar voorbeeld in detail zitten.

Scenario

Als onderdeel van het softwareontwikkelingsproces wordt Build 2.0 uitgebracht. Tijdens het testen werd een geïdentificeerde en vrijgegeven fout (laten we zeggen, Fout 2.0.1) vastgesteld. Dezelfde Fout 2.0.1 moet worden getest in Build 2.1 (op voorwaarde dat deze fout vermeld staat in de Release Notes van Build 2.1) om ervoor te zorgen dat de fout is opgelost.

Uitvoeringsproces

Volgens het Bug Life Cycle wordt de bug direct gedeeld of gerapporteerd aan het ontwikkelingsteam nadat deze is vastgelegd. Daarna wordt de status ervan gemarkeerd als “Nieuw”. Nu is het aan het ontwikkelingsteam om de bug te accepteren of te weigeren.

Bij acceptatie van de bug zal de ontwikkelaar deze oplossen en vervolgens in de volgende fase vrijgeven. De status wordt gemarkeerd als “Klaar voor QA”. Momenteel valideren de testers de bug om erachter te komen hoe deze is opgelost. Daarom kun je zeggen dat een retest een geplande test is.

De tester gebruikt dezelfde testcases en testgegevens in de vorige build. Als er geen bug wordt gevonden, wordt de status gemarkeerd als “Opgelost”. Anders blijft de status “Niet Opgelost”. Vervolgens wordt het Defect Retesting Document gedeeld met het ontwikkelingsteam.

Om goed inzicht te hebben in retests, moet je de belangrijkste kenmerken ervan kennen. Dit zal niet alleen helpen om je test te diversifiëren, maar ook de dimensies te vergroten voor de kwaliteitsopbouw van software.

Kenmerken van Retest

Een top-niveau gebruikerservaring bij softwaretesten volgt een iteratief proces. Dit kan bereikt worden door informatie te behouden over de belangrijkste aspecten van een retestproces, wat leidt tot betere applicatie-levering.

Hieronder staan de belangrijkste kenmerken:

• Het wordt geïmplementeerd in een soortgelijk document als de vorige en processen in de nieuwe build.
• Uitvoering gebeurt wanneer specifieke testcases als mislukt worden beschouwd.
• Het vindt plaats wanneer een volledige software retests nodig heeft om de kwaliteit ervan te valideren.
• Het is onmogelijk om de testscenario’s die opnieuw getest worden te automatiseren.
• Het proces van opnieuw testen is afhankelijk van het ontwikkelingsteam, dat verantwoordelijk is voor het accepteren of afwijzen van de bug.
• Gedetailleerde aspecten worden door de tester in overweging genomen voor de gewijzigde functionaliteit.

Wanneer moet je opnieuw testen?

Als tester is het belangrijk om te beslissen wanneer je opnieuw moet testen. Het antwoord hierop is eenvoudig. Ten eerste moet je rekening houden met de omvang en de kenmerken van je project die getest moeten worden.

Bijvoorbeeld, opnieuw testen wordt normaal als een organisatie een uitgebreid productassortiment heeft dat verspreid is over verschillende producten. De reden hiervoor is de noodzaak van de tijdige release van de softwaretoepassing, aangezien dit ook andere delen van systemen op verschillende manieren kan beïnvloeden.

Er zijn verschillende scenario’s waarin we opnieuw testen als proces kunnen gebruiken. Enkele daarvan worden hieronder uitgelegd:

Bij Detectie van de Afgewezen Bug

Het kan meerdere keren gebeuren dat de bug die de tester meldt wordt afgewezen door de ontwikkelaar en gemarkeerd als “Niet Reproduceerbaar”. In dergelijke gevallen wordt opnieuw getest voor dezelfde bug om de ontwikkelaar te informeren dat het probleem reproduceerbaar en geldig is.

Behoefte aan Bug Fix in Release Note

In het proces van software ontwikkeling, wanneer het ontwikkelingsteam een nieuwe build uitbrengt, is opnieuw testen van toepassing. Hier test de tester de eerder gemelde bugs opnieuw om ervoor te zorgen dat ze zijn opgelost.

Klantenverzoek

Softwarekwaliteit is een grote zorg voor elke organisatie. Om dit te waarborgen, kan een klant vragen om een hertest uit te voeren voor specifieke gebruiksscenario’s om de kwaliteit van het product te garanderen.

Andere scenario’s

Het is belangrijk op te merken dat telkens wanneer een bug wordt gefixt, extra testgevallen worden gecreëerd door ontwikkelaars. Dit geeft aan dat er meer tijd besteed moet worden aan het schrijven van testgevallen in plaats van ze te herstellen. Toch is het, ook al bent u zeker van uw codebase, nog steeds essentieel om cruciale delen van de applicatie te hertesten bij elke release.

Bijvoorbeeld, een nieuwe functionaliteit veroorzaakt onverwacht gedrag en uitdagingen bij het detecteren van bugs bij de eerste instantie. Dit zou alleen mogelijk kunnen zijn wanneer zulke problemen duidelijk worden tijdens het testen of op basis van gebruikersfeedback. Deze situatie vereist dat u “hertesten” uitvoert om scepticisme over nieuw geïdentificeerde bugs te overwinnen.

Voordelen van Hertesten

De kwaliteit van een softwareapplicatie hangt af van het succes van het hertestproces. Het waarborgt de stabiliteit van de applicatie in het software ontwikkelingsleven.

Enkele van de belangrijkste voordelen worden hieronder benadrukt:

• Zorgt ervoor of de bug is gefixt of niet.
• Verbetert de kwaliteit van het product en de ontwikkelde applicatie.
• Zorgt ervoor dat het functioneren van de applicatie of het product overeenkomt met de verwachtingen van de gebruiker.
• Kost minder tijd om de bugs te herstellen omdat het specifieke probleem wordt aangepakt.
• Werkt met dezelfde gegevens en processen met een nieuwe build voor zijn werking.
• Heeft geen nieuwe testomgeving-setup nodig.

Ondanks verschillende voordelen, heeft het hertestproces ook enkele nadelen. Laten we dit begrijpen aan de hand van het onderstaande gedeelte.

Nadelen van Herstesten

A retest process also has some drawbacks, which can hamper or create challenges in the testing process. Knowing such limitations will help you address those while retesting to avoid any issues.

Laten we begrijpen wat ze zijn:

• Een nieuwe build nodig voor de authenticatie van gebreken.
• Herstest-testgevallen kunnen alleen worden opgehaald wanneer het is gestart.
• Het is niet mogelijk om de testgevallen voor hertesten te automatiseren.
• Het hertesten van mislukte testgevallen vereist extra tijd en inspanning.
• Herstesten kan niet gegarandeerd worden als onderdeel van het testproces, behalve in gevallen waar een bug wordt geïdentificeerd of gecorrigeerd.

Wat betreft de nadelen van herstesten, kan worden gezegd dat een hertest misschien uitdagend is voor sommige testers. Vooral de nieuwe tester probeert vaak een alternatieve manier te vinden om het probleem op te lossen. Hier verwarren ze echter de term regressietesten. Echter, regressietesten en hertesten hebben significante verschillen.

Wat Is Het Verschil Tussen Regressietesten En Herstesten?

Als je nieuw bent in softwaretesten, zou je kunnen denken dat de termen “herstesten” en “regressietesten” gelijk zijn. Echter, het is een feit dat ze beide verschillend zijn, hoewel gerelateerd. We zullen in dit gedeelte onderzoeken hoe het hertestproces zich onderscheidt van regressietesten.

Eerst, regressie en retest zijn onderdelen van softwarevalidatie in het software ontwikkelingsproces. Retest wordt voornamelijk uitgevoerd aan het einde van een specifieke fase van ontwikkeling. Met andere woorden, als je wilt zorgen dat een werkend product niet door bugs uit eerdere tests wordt overladen, doe je een retest. In tegenstelling tot regressie-testen kan worden uitgevoerd in elke ontwikkelingsfase om ervoor te zorgen dat een specifiek aspect van de codes correct werkt.

In sommige situaties kunnen testers retests uitvoeren door gewoon eerdere testuitvoer of rapporten te lezen om eventuele problemen en hun oplossing te controleren. Een grondige onderzoek kan ook worden gedaan door individueel te controleren op eerdere gevallen om ervoor te zorgen dat ze worden afgehandeld. Regressie-testen wordt echter voornamelijk gedaan via een testplan en het uitvoeren ervan op elke applicatieversie, beginnend met de nieuwste. In een dergelijke aanpak moet je ervoor zorgen dat elke wijziging in de applicatie goed wordt getest.

Hieronder vindt u enkele belangrijke aandachtspunten over het verschil tussen regressie- en retestprocessen:

Begrijpen van Regressie-testen en Retest met een voorbeeld

Het verschil tussen regressie-testen en retesten kan worden uitgelegd met het onderstaande voorbeeld.

Stel, er is een probleem met de aanmeldingspagina van een internetbankiersysteem waar klanten geen toegang hebben tot hun accountgegevens. Ondanks dat ze werden gevraagd om zich opnieuw aan te melden, faalden ze om in te loggen op hun account. Het ondersteunings team heeft het probleem onderzocht en ervoor gezorgd dat zoiets niet meer gebeurt.

Het ontwikkelaarsteam heeft code-niveau wijzigingen aangebracht om succesvol in te loggen op de accountpagina in elke browser. Het testen hier betreft echter niet alleen een aanmeldingspagina, maar zorgt er ook voor dat codewijzigingen geen invloed hebben op andere functionaliteit van internetbankier-webtoepassingen. Hier wordt de toepassing getest op wijzigingen. Dit wordt regressietesten genoemd.

Bij het opnieuw controleren van het probleem ten aanzien van de aangebrachte wijziging probeerde het testteam in te loggen op de pagina, maar faalde. Het ondersteunings team communiceerde met de betrokken ontwikkelaar en legde het probleem uit. De ontwikkelaar informeerde ons echter dat ze het probleem hadden opgelost. Het QA-team test de werking van de webtoepassing om te controleren of het probleem is opgelost, dit wordt retesten genoemd.

Daarom is een retest essentieel in het softwaretestproces en is een voorwaarde om ervoor te zorgen dat het werkt.

We hebben het belang van het retestproces aangekaart, wat een idee geeft van de relatie met softwaretesten. Laten we eerst enkele van zijn typische toepassingen in softwaretesten begrijpen. Hier zijn enkele toepassingen van retests in softwaretesten:

• Toegepast om eventuele specifieke fouten of bugs te corrigeren, die verificatie vereisen.
• Controleert de werking van het volledige systeem om de uiteindelijke functionaliteit te valideren.
• Controleert de kwaliteit van een bepaald deel van het systeem.

Fasen van Retesten

Het retestproces betrekt een manuele aanpak. Het beschouwt ook de primaire fasen voor het testen van de softwaretoepassing.

Hieronder staan de fasen die betrokken zijn bij een retestproces:

1. Selectie van Test Cases 

Testselectie is een methode waarbij specifieke testcases uit de testsuite worden uitgevoerd om te controleren of de correctie van fouten in software is uitgevoerd of niet. Over het algemeen worden testcases onderscheiden in herbruikbaar en verouderd, waarbij herbruikbare testcases worden gebruikt om opnieuw te testen.

2. Toepassing van Test Cases

Het belangrijkste doel van het opnieuw testen is om het verwachte resultaat van de testcases te vergelijken. Daarom moeten testcases met standaard voorgeëxploiteerde resultaatvellen worden toegepast.

3. Schatting van Tijd

Bij het identificeren van de testcases, moeten testers rekening houden met de totale uitvoeringstijd die betrokken is bij opnieuw testen. Factoren zoals evaluatie van testcases kunnen extra tijd toevoegen.

4. Module Volgen

In situaties waarin testcases falen, is het een grote uitdaging om de corresponderende modules voor de fout te identificeren. Daarom wordt het softwaregedeelte onderverdeeld in verschillende individuele modules.

Hiervoor worden kleine testcases geïmplementeerd voor specifieke individuele modules. Modules die niet de verwachte uitkomsten laten zien, worden gemarkeerd als defecte modules. Op deze manier wordt het volgen van defecte modules voltooid.

5. Opnieuw Testen van de Module

Test de defecte module totdat deze is gefixt.

6. Reïntegratie van de Module

Na het fiksen van de defecte module, wordt volledige integratie van de testcases toegepast op de software. Verder wordt de werking van de software gecontroleerd.

Hoe uit te voeren retests?

Retests van de softwaretoepassing kunnen alleen via een handmatige aanpak worden uitgevoerd. Zoals hierboven aangegeven, is de belangrijkste reden dat het zich alleen richt op het specifieke gebrek. Daarom is het geschikt voor de handmatige testaanpak omdat het nauwkeuriger kan worden uitgevoerd in plaats van met de geautomatiseerde methode.

Om een retest uit te voeren, moet het testteam een goed begrip hebben van de huidige status van de softwaretoepassing. Deze kennis van het werking van de software en hoe het te verbeteren door fouten te herstellen, vereenvoudigt de handmatige aanpak.

De tester voert de testscenario’s handmatig uit om de wijzigingen in de toepassing te valideren. Dit wordt gedaan om ervoor te zorgen dat deze wijzigingen geen extra gebreken veroorzaken en dat mislukte gevallen die zijn geïdentificeerd, worden uitgeschakeld in de nieuwe release. U kunt handmatige retests uitvoeren na het wijzigen van de wijzigingen in de software, het herstellen van de gebreken en het voltooien van de softwaretestcyclus.

U kunt de volgende stappen volgen om een retest handmatig uit te voeren:

1. Bepaal de wijzigingen in de softwaretoepassing en het gebied dat retests vereist.
2. Beoordelen en bijwerken van de testscenario’s die retests vereisen in lijn met de wijzigingen.
3. De ontwikkelde testscenario’s moeten handmatig worden uitgevoerd.
4. Analyseer de werkelijke uitvoer met het verwachte resultaat om te beoordelen of de wijzigingen geen nieuwe gebreken veroorzaken.
5. Als het gebrek wordt geïdentificeerd, documenteer het en rapporteer het aan het ontwikkelingsteam.
6. Herhaal het proces van de handmatige retest totdat alle gebreken zijn opgelost.

Echter, je zou je misschien afvragen waarom hertesten niet kan worden uitgevoerd via een geautomatiseerde aanpak. Er zijn verschillende redenen voor dit. Laten we een idee krijgen uit het onderstaande gedeelte:

Kan Hercontrole Niet Geautomatiseerd Worden?

Je kunt een toepassing niet hertesten met een geautomatiseerde aanpak. Enkele veelvoorkomende redenen worden hieronder gemarkeerd:

• Intricatie: Sommige van de mislukte gevallen kunnen te wijten zijn aan de complexiteit van de software. Daarom zijn dergelijke mislukte gevallen moeilijk te automatiseren.
• Onverwacht resultaat: De wijzigingen aangebracht in de software kunnen onverwachte resultaten opleveren. Mislukte gevallen in dergelijke situaties vereisen handmatige testen om het resultaat te verifiëren.
• Kosten en middelen: Het automatiseren van het hertestproces kan duur zijn omdat dit het gebruik van extra hardware en software inhoudt. Het is problematisch om de kosten van kleine wijzigingen in de software te rechtvaardigen.
• Beperking van tijd: Het automatiseren van het hertestproces kost veel tijd en omdat er misschien druk staat op een tijdige release, is een handmatige aanpak de beste optie.

Aspecten Om In Gedachten Te Houden Bij Het Doen Van Hercontrole

Tot nu toe hebben we de betekenis van een hertestproces en hoe het uit te voeren begrepen. Echter, de aanwezigheid van geldige overwegingen in hertests vereist aandacht. Hieronder vind je enkele punten die in aanmerking moeten worden genomen.

• Het hertestproces vereist de vorming van een nieuwe softwarebuild wanneer het probleem is opgelost op basis van de eerste rapportage.
• Er is de mogelijkheid dat software die voor hertests wordt verzonden, code-niveau wijzigingen ondergaat. Daarom is het essentieel om regressietests uit te voeren vóór de release van de applicatie.
• De retestdekking en omvang kunnen alleen bekend worden nadat het probleem is opgelost. Als gevolg hiervan kan automatisering niet worden uitgevoerd voor retesten zoals bij regressie.
• De ontwikkeltijd van de applicatie kan toenemen als problemen die bij retest worden gevonden, blijven bestaan. Een meer uitgebreide en strategische evaluatie is nodig om de oorzaak van het probleem te onderzoeken.

Toch, ondanks de uitdagingen die worden ondervonden in een retestproces, moet de organisatie zich richten op testmethoden bewust. Dit kan beter worden gedaan door retests uit te voeren op de cloud. Laten we dit nader bekijken.

Hoe uit te voeren Retesting op de Cloud?

Automatisering van het retestproces is niet altijd haalbaar en er is handmatige testen nodig om de kwaliteit van software te garanderen. Het kan echter tijdrovend zijn in sommige gevallen en geen schaalbare proces. Cloud testplatforms helpen je te overwinnen test infrastructuur-gerelateerde uitdagingen.