Som programvarutestare och automationsingenjörer tänker vi ofta på den lyckliga vägen: den väg som användaren med störst sannolikhet kommer att ta när hen använder vår applikation. När vi skriver våra automatiserade UI-tester vill vi se till att vi automatiserar dessa lyckliga vägar, och när vi skriver API-automation vill vi verifiera att varje slutpunkt returnerar ett ”200 OK” eller liknande lyckat svar.
Men det är viktigt att tänka på negativ testning i både våra manuella och automatiserade tester. Här är några anledningar till varför.
Våra automatiserade tester kan godkännas av fel anledning
När jag först började skriva automatiserade UI-tester i JavaScript förstod jag inte konceptet med ett promise-objekt. Jag antog helt enkelt att när jag gjorde en begäran om att hitta ett element skulle den inte returnera elementet förrän det faktiskt hade hittats. Jag blev så glad när mina tester började ge det gröna resultatet ”Godkänd”, tills en kollega föreslog att jag skulle försöka få testet att misslyckas genom att kontrollera ett annat värde. Det godkändes igen eftersom det faktiskt validerade det promise-objekt som fanns, vilket alltid returnerade ”Sant”. Det lärde mig en värdefull läxa: anta aldrig att dina automatiserade tester fungerar korrekt bara för att de godkänns. Se till att köra några scenarier där dina tester ska misslyckas och kontrollera att de faktiskt gör det. På så sätt kan du vara säker på att du verkligen testar det du tror att du testar.
Negativ testning kan avslöja felaktigt hanterade fel som kan påverka en användare
Vid API-testning bör alla klientrelaterade fel resultera i ett svar på 400-nivå i stället för ett serverfel på 500-nivå. Om du utför negativ testning och upptäcker att ett 403-svar nu kommer tillbaka som ett 500-svar kan det betyda att koden inte längre hanterar det användningsfallet korrekt. Ett 500-svar från servern kan hindra användaren från att få den information hen behöver för att åtgärda sitt fel, eller ännu värre, få applikationen att krascha.
Negativ testning kan hitta säkerhetsluckor
Det är lika viktigt att se till att en användare kan logga in i en applikation som att se till att en användare inte kan logga in när hen inte ska kunna det. Om du bara kör ett inloggningstest med ett giltigt användarnamn och lösenord missar du detta viktiga område! Jag har sett situationer där en användare kunde logga in med vilket lösenord som helst, där en användare kunde logga in med ett tomt lösenord och där en användare kunde logga in med ett felaktigt användarnamn och lösenord.
Det är också avgörande att verifiera att vissa användare inte har åtkomst till delar av en applikation. En noggrant testad och fungerande administrationssida betyder inte mycket om det visar sig att vilken användare som helst kan komma åt den.
Negativ testning håller din databas ren
Som jag nämnde i kapitel 12 hjälper bra och giltiga data i databasen till att hålla applikationen frisk. Data som inte överensstämmer med förväntningarna kan få webbsidor att krascha eller misslyckas med att läsas in, eller leda till att informationen visas felaktigt. Ju mer negativ testning du kan utföra av dina indata, desto mer kan du säkerställa att du endast har bra data.
För varje inmatningsfält som jag ansvarar för att testa vill jag veta exakt vilka tecken som är tillåtna. Sedan kan jag köra en hel mängd negativa tester för att se till att poster med de förbjudna tecknen avvisas.
Ibland väljer användarna den negativa vägen
Det är så lätt, särskilt med en ny funktion som skyndas fram för att hinna till en tidsfrist, att glömma att testa de användarvägar där användaren klickar på knappen Avbryt eller Ta bort. Men användare gör detta hela tiden; tänk bara på de gånger då du har övervägt att göra ett köp på nätet och sedan ändrat dig och tagit bort en vara från kundvagnen. Föreställ dig frustrationen om du inte kunde ta bort något från kundvagnen, eller om en Avbryt-knapp inte rensade ett formulär så att du kunde börja om. Användarupplevelsen på det här området är lika avgörande som den lyckliga vägen.
Programvarutestning handlar om att leta efter oväntade beteenden så att vi hittar dem innan en användare gör det. När negativ testning kombineras med testning av den lyckliga vägen kan vi säkerställa att våra användare inte får några obehagliga överraskningar.
Om du vill optimera dina testprocesser ytterligare kan du överväga att integrera ett förstklassigt databashanteringsverktyg för att hantera dina komplexa databehov.
Den kompletta boken om programvarutestning
När jag upptäckte min kärlek till programvarutestning 2009 ville jag lära mig allt jag kunde om programvarutestning, men jag hittade väldigt få böcker som kunde lära mig det. Till slut lärde jag mig genom att prova mig fram och göra misstag, läsa blogginlägg och prata med mina kollegor. I dag finns det några utmärkta böcker om specifika områden inom programvarutestning, till exempel explorativ testning, agil testning och testautomation, men jag känner inte till någon bok som strävar efter att vara en komplett referens för testning.
Jag skrev Den kompletta programvarutestaren eftersom jag ville ge både nya och erfarna testare de idéer och verktyg de behöver för att vara så effektiva som möjligt. För snabba QA-tips och fler bokrekommendationer kan du prenumerera på nyhetsbrevet The QA Lead.
Relaterad läsning: VAD ÄR ZEPHYR SCALE?
Relaterad lista över verktyg:
Också värt att kolla in:
