Som programvaretestere og automatiseringsingeniører tenker vi ofte på den lykkelige stien: stien brukeren mest sannsynlig vil følge når de bruker applikasjonen vår. Når vi skriver våre automatiserte UI-tester, vil vi sørge for at vi automatiserer disse lykkelige stiene, og når vi skriver API-automatisering, vil vi verifisere at hvert endepunkt returnerer et «200 OK» eller en tilsvarende vellykket respons.
Men det er viktig å tenke på negativ testing i både de manuelle og automatiserte testene våre. Her er noen grunner til hvorfor.
De automatiserte testene våre kan bestå av feil grunner
Da jeg først begynte å skrive automatiserte UI-tester i JavaScript, forsto jeg ikke konseptet med et løfte. Jeg antok bare at når jeg sendte en forespørsel om å finne et element, ville den ikke returnere elementet før det faktisk var funnet. Jeg ble så begeistret da testene mine begynte å komme tilbake med det grønne resultatet «Bestått», helt til en kollega foreslo at jeg skulle prøve å få testen til å feile ved å validere en annen verdi. Den besto igjen fordi den faktisk validerte mot løftet som eksisterte, og som alltid returnerte «Sant». Det lærte meg en verdifull lekse: Anta aldri at de automatiserte testene dine fungerer riktig bare fordi de består. Sørg for å kjøre noen scenarier der testene dine skal feile, og pass på at de faktisk gjør det. På denne måten kan du være sikker på at du virkelig tester det du tror du tester.
Have an account? Log In
Negativ testing kan avdekke feilbehandlede feil som kan påvirke en bruker
Ved API-testing bør alle klientrelaterte feil resultere i en respons på 400-nivå i stedet for en serverfeil på 500-nivå. Hvis du utfører negativ testing og oppdager at en 403-respons nå kommer tilbake som en 500, kan det bety at koden ikke lenger håndterer dette brukstilfellet riktig. En 500-respons fra serveren kan hindre brukeren i å få den riktige informasjonen de trenger for å løse feilen, eller enda verre: den kan få applikasjonen til å krasje.
Negativ testing kan avdekke sikkerhetshull
Det er like viktig å sørge for at en bruker kan logge inn i en applikasjon, som å sørge for at en bruker ikke kan logge inn i en applikasjon når de ikke skal kunne det. Hvis du bare kjører en innloggingstest med gyldig brukernavn og passord, går du glipp av dette avgjørende området! Jeg har sett en situasjon der en bruker kunne logge inn med hva som helst som passord, en situasjon der en bruker kunne logge inn med et tomt passord, og en situasjon der en bruker kunne logge inn med feil brukernavn og passord.
Det er også avgjørende å verifisere at bestemte brukere ikke har tilgang til deler av en applikasjon. Det hjelper lite å ha en nøye testet og velfungerende administratorside hvis det viser seg at hvilken som helst tilfeldig bruker kan få tilgang til den.
Negativ testing holder databasen ryddig
Som jeg nevnte i kapittel 12, vil gode og gyldige data i databasen bidra til å holde applikasjonen sunn. Data som ikke samsvarer med forventningene, kan føre til at nettsider krasjer eller ikke lastes inn, eller føre til at informasjonen vises feil. Jo mer negativ testing du kan utføre av inndataene dine, desto bedre kan du sikre at du bare har gode data.
For hvert inndatafelt jeg er ansvarlig for å teste, liker jeg å vite nøyaktig hvilke tegn som er tillatt. Deretter kan jeg kjøre en hel rekke negative tester for å sikre at oppføringer med de forbudte tegnene blir avvist.
More Articles
Noen ganger velger brukerne den negative stien
Det er så lett, særlig med en ny funksjon som blir presset frem for å rekke en tidsfrist, å glemme å teste brukerforløpene der brukerne klikker på knappen Avbryt eller Slett. Men brukere gjør dette hele tiden. Tenk bare på ganger du har vurdert å gjennomføre et kjøp på nettet, men så ombestemt deg og fjernet en vare fra handlekurven. Forestill deg frustrasjonen hvis du ikke kunne fjerne noe fra handlekurven, eller hvis en Avbryt-knapp ikke tømte et skjema slik at du kunne begynne på nytt. Brukeropplevelsen på dette området er like avgjørende som den lykkelige stien.
Programvaretesting handler om å lete etter uventet atferd, slik at vi finner den før en bruker gjør det. Når negativ testing kombineres med testing av den lykkelige stien, kan vi sørge for at brukerne våre ikke får noen ubehagelige overraskelser.
Hvis du ønsker å optimalisere testprosessene dine ytterligere, bør du vurdere å integrere et førsteklasses verktøy for databaseadministrasjon for å håndtere de komplekse databehovene dine.
Den komplette boken for programvaretestere
Da jeg oppdaget kjærligheten min til programvaretesting i 2009, ønsket jeg å lære alt jeg kunne om programvaretesting, men jeg fant svært få bøker som kunne lære meg det. Jeg endte opp med å lære gjennom prøving og feiling, ved å lese blogginnlegg og snakke med kollegene mine. I dag finnes det noen utmerkede bøker om spesifikke områder innen programvaretesting, som utforskende testing, smidig testing og testautomatisering, men jeg kjenner ikke til noen bok som har som mål å være en komplett referanse for testing.
Jeg skrev Den komplette programvaretesteren fordi jeg ønsket å gi både nye og erfarne testere ideene og verktøyene de trenger for å være så effektive som mulig. For raske QA-tips og flere bokanbefalinger kan du abonnere på nyhetsbrevet fra QA Lead.
Relatert lesning: HVA ER ZEPHYR SCALE?
Relatert verktøyliste:
Også verdt å sjekke ut:
