De positieve uitkomsten van negatief testen
Als softwaretesters en automatiseringsengineers denken we vaak aan het ideale pad: het pad dat de gebruiker waarschijnlijk zal volgen bij het gebruik van onze applicatie. Wanneer we onze geautomatiseerde UI-tests schrijven, willen we ervoor zorgen dat we die ideale paden automatiseren, en wanneer we API-automatisering schrijven, willen we controleren of elk eindpunt een “200 OK” of vergelijkbare succesvolle respons retourneert.
Maar het is belangrijk om bij zowel onze handmatige als geautomatiseerde tests aan negatief testen te denken. Hier zijn enkele redenen waarom.
Onze geautomatiseerde tests kunnen om de verkeerde redenen slagen
Toen ik begon met het schrijven van geautomatiseerde UI-tests in JavaScript, begreep ik het concept van de promise niet. Ik nam gewoon aan dat wanneer ik een verzoek deed om een element te vinden, dat element pas zou worden geretourneerd zodra het daadwerkelijk was gevonden. Ik was zo enthousiast toen mijn tests begonnen terug te komen met het groene resultaat “Geslaagd”, totdat een collega voorstelde om te proberen de test te laten mislukken door een andere waarde te controleren. Ook deze test slaagde, omdat deze in werkelijkheid controleerde tegen de bestaande promise, die altijd “Waar” retourneerde. Dat leerde me een waardevolle les: ga er nooit van uit dat je geautomatiseerde tests correct werken alleen omdat ze slagen. Zorg ervoor dat je scenario’s uitvoert waarin je tests zouden moeten mislukken, en controleer of dat ook gebeurt. Zo weet je zeker dat je echt test wat je denkt dat je test.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Negatief testen kan onjuist afgehandelde fouten aan het licht brengen die gevolgen kunnen hebben voor een gebruiker
Bij API-testen moet elke fout die verband houdt met de client resulteren in een respons op 400-niveau in plaats van een serverfout op 500-niveau. Als je negatief test en ontdekt dat er nu een 500-respons wordt geretourneerd in plaats van een 403-respons, kan dit betekenen dat de code deze situatie niet langer correct afhandelt. Een 500-respons van de server kan ervoor zorgen dat de gebruiker niet de juiste informatie krijgt die nodig is om de fout te herstellen of, erger nog, dat de applicatie crasht.
Negatief testen kan beveiligingslekken vinden
Net zo belangrijk als controleren of een gebruiker bij een applicatie kan inloggen, is controleren of een gebruiker niet bij een applicatie kan inloggen wanneer dat niet is toegestaan. Als je alleen een inlogtest uitvoert met een geldige gebruikersnaam en een geldig wachtwoord, mis je dit cruciale gebied! Ik heb een situatie gezien waarin een gebruiker met om het even wat als wachtwoord kon inloggen, een situatie waarin een gebruiker met een leeg wachtwoord kon inloggen en een situatie waarin een gebruiker met een onjuiste gebruikersnaam en een onjuist wachtwoord kon inloggen.
Het is ook cruciaal om te controleren of bepaalde gebruikers geen toegang hebben tot delen van een applicatie. Een zorgvuldig geteste en goed functionerende beheerpagina betekent niet veel als blijkt dat elke willekeurige gebruiker erbij kan komen.
Negatief testen houdt je database schoon
Zoals ik in hoofdstuk 12 al aangaf, helpt goede, geldige data in je database om je applicatie gezond te houden. Data die niet aan de verwachtingen voldoet, kan ervoor zorgen dat webpagina’s crashen of niet laden, of dat de informatie onjuist wordt weergegeven. Hoe meer negatief testen je op je invoer kunt uitvoeren, hoe beter je kunt garanderen dat je uitsluitend goede data hebt.
Voor elk invoerveld waarvoor ik verantwoordelijk ben, wil ik precies weten welke tekens zijn toegestaan. Vervolgens kan ik een hele reeks negatieve tests uitvoeren om er zeker van te zijn dat invoer met verboden tekens wordt geweigerd.
Soms nemen gebruikers het negatieve pad
Het is zo gemakkelijk, vooral bij een nieuwe functie die onder tijdsdruk wordt ontwikkeld om een deadline te halen, om te vergeten de gebruikerspaden te testen waarin gebruikers op de knop Annuleren of Verwijderen klikken. Maar gebruikers doen dit voortdurend; denk maar aan momenten waarop je een online aankoop wilde doen en vervolgens van gedachten veranderde en een artikel uit je winkelmandje verwijderde. Stel je je frustratie voor als je iets niet uit je winkelmandje kon verwijderen of als een knop Annuleren een formulier niet leegmaakte, zodat je opnieuw kon beginnen. Gebruikerservaring is op dit gebied net zo cruciaal als het ideale pad.
Softwaretesten draait om het zoeken naar onverwacht gedrag, zodat we dit vinden voordat een gebruiker dat doet. Wanneer negatief testen wordt gecombineerd met testen van het ideale pad, kunnen we ervoor zorgen dat onze gebruikers geen onaangename verrassingen krijgen.
Als je je testprocessen verder wilt optimaliseren, overweeg dan de integratie van een eersteklas databasemanagementtool om je complexe databehoeften te beheren.
Het complete boek voor softwaretesters
Toen ik in 2009 mijn liefde voor softwaretesten ontdekte, wilde ik alles leren wat ik kon over softwaretesten, maar ik vond maar weinig boeken die me dat konden leren. Uiteindelijk leerde ik door vallen en opstaan, blogposts te lezen en met mijn collega’s te praten. Tegenwoordig zijn er enkele uitstekende boeken over specifieke gebieden van softwaretesten, zoals verkennend testen, agile testen en testautomatisering, maar ik ken geen enkel boek dat bedoeld is als een complete naslaggids voor testen.
Ik schreef De complete softwaretester omdat ik zowel nieuwe als ervaren testers de ideeën en hulpmiddelen wilde bieden die ze nodig hebben om zo effectief mogelijk te zijn. Abonneer je op de nieuwsbrief van The QA Lead voor snelle QA-tips en meer boekaanbevelingen.
Gerelateerde lectuur: WAT IS ZEPHYR SCALE?
Gerelateerde lijst met tools:
Ook het bekijken waard:
