how tester can think
Scene : I en restaurant ankom en familie på 3 - foreldre og et småbarn. Etter å ha bestilt den mest favorittpizzaen, slapp familien av og småbarn begynte å leke med spisepinnene som var lagt på bordet. Han likte dem og bestemte seg for å spise middagen kun med spisepinner.
Han kunngjorde sitt ønske og foreldre, opptatt med å snakke, ble enige om det. Da pizzaen ble servert, begynte smårollingen å bruke spisepinner og mislyktes flere ganger med å få pizzaen i munnen. Plutselig la foreldrene merke til det og beordret smårollingen å ikke bruke spisepinner. Småbarn overbeviste ikke ettersom foreldrene allerede var enige om ønsket hans tidligere.Da foreldre begynte å lære om å spise pizza bare med kniv og gaffel, spurte smårollingen troen, men jeg vil bare spise den med spisepinner, og hvorfor er det galt? Og mens han brukte spisepinner når han ikke klarte å spise sin favorittpizza, ble han utålmodig og kastet til slutt spisepinnene og bestemte seg for å ikke spise pizza også. Foreldre, frustrerte også, kunne ikke gjøre noe, og familiens middagstid viste seg å være den verste tiden på dagen.
Nå, erstatt noen ord i para ovenfor som følgende, og tenk på det på nytt:
Foreldre: Prosjektledelse team inkludert forretningsanalytiker, selger, utviklingsleder og arkitektonisk team.
Småbarn: Kunde / sluttbruker
Pizza: produkt / applikasjon
Spisepinner: feil
Den mest favoritt applikasjonen er bare favoritt til brukeren ikke gjør feil og ikke ser applikasjonens verste oppførsel. Når brukeren er erfaren, kommer den aldri tilbake til applikasjonen. Og derfor, som en tester, er det veldig nødvendig å forstå brukerens tankesett , hvordan det forventes at han oppfører seg, hva galt han kan gjøre med applikasjonen, hva som kan være den verste feilen og mye mer.
Det meste av tiden har jeg blitt spurt i fora så vel som av interne teammedlemmer om hvordan man kan gjenskape brukeropplevelsen mens man tester. Svaret mitt har alltid vært enkelt - Vær en bruker :)
Selv om det er lett å si enn å implementere, er det et riktig tidspunkt for programvaretestingsindustrien å bevege seg i retning av revolusjonen der brukeropplevelse og tilbakemelding er viktigere enn noe annet.
Hvordan en tester kan tenke som sluttbruker?
Presentere herved noen typiske eksempler på å oppføre seg som sluttbruker og finne overraskelser , Har jeg observert de siste dagene:
#1) Mens en bruker valgte eller manuelt angav riktig datoverdi, testet et datofelt, det fungerte bra. Men da brukeren endte med å skrive inn en helt feil verdi som 12/00 // og klikket på OK, ble han presentert for en feilmelding om ugyldig datoverdi.
Nå korrigerer ikke brukeren datoen, men oppdaterer siden. Hva skal skje? Mange av dere kan gjette hva som skal skje, men kan dere tenke på hva som skjedde med applikasjonen? Etter å ha oppdatert siden, ble en bruker presentert følgende og den samme verdien ble også lagret i en database.
Så ... testeren har replikert brukeren her, enig?
#to) Mens du testet en søknad, der arbeidsflyten skal sende inn forskjellige skjemaer i spesiell rekkefølge hvis du fulgte ordren, fungerte den bra. Men hva om brukeren prøvde å gå tilbake til skjema nr. 3, fra skjema nr. 5?
Igjen, i stedet for å tenke på hva som skal skje, la oss se hva som skjedde ...
Tester var forbauset, men følte stolthet over å vise seg selv som bruker ... ..Godt?
# 3) Etter vellykket pålogging klikker brukeren på tilbakeknappen i nettleseren. Igjen, la oss se hva som skjedde ...
hva du skal gjøre med torrentfil
Legitimasjonserklæringen burde ha ryddet opp, men det gjorde det ikke. Når du går videre på denne påloggingssiden, klikker en bruker på Glemt passordkoblingen. Vær tydelig på at brukeren allerede hadde logget på og hadde vært på innloggingssiden ved å klikke på tilbakeknappen i nettleseren. Klikket på Glemt passordet navigerte brukeren til hjemmesiden til applikasjonen.
Testeren vendte seg til brukeren ... ..Godt?
# 4) Etter å ha observert URL-en for søkesiden (http: //x.x.x.x: y / # / Search) for applikasjonen, endret testeren URL-en som http: //x.x.x.x: y / # / Søk / test? og kan du tenke hva som hadde skjedd?
Programmet krasjet og testeren vendte seg til brukeren igjen ... Jeg håper du ikke er uenig.
Konklusjon
Jeg antar at jeg via disse eksemplene har formidlet nok av det jeg ønsket.
Virkelig, testing betyr ikke å sjekke arbeidsflyten til applikasjonen, og det betyr heller ikke å bryte applikasjonen, men det betyr det absolutt sjekk brukeropplevelsen selv når han gjør feilene.
Om forfatteren: Dette innlegget er skrevet av STH-teammedlem Bhumika Mehta. Hun er prosjektleder, med 10+ års erfaring innen programvaretesting. Hun setter pris på gode ideer og innovasjoner og risikoer også. Og hater selvfølgelig monotont arbeid, mennesker og miljø.
Og ja, la oss vende testeren i oss selv til sluttbruker .... :)
Så ... vi vil gjerne høre flere eksempler som disse fra deg og vil også ha dine meninger.
Anbefalt lesing
- GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide
- Testing og testtilfeller for nettsider for testing av webapplikasjonskapsler
- Brukergodkjenning i MongoDB
- E-postvalideringstesting: Hvordan teste e-postfunksjonaliteten til et program
- Money Making, Software Testing Career And Secrets of a Richest Tester
- 5 ting en nybegynnerutvikler (og tester) bør vite om programvaretesting
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Ad-hoc-testing: Hvordan finne feil uten en formell testprosess