how tester can think
Scen : I en restaurang anlände en familj på 3 personer - föräldrar och ett barn. Efter att ha beställt den mest favoritpizzan slappnade familjen av och småbarn började leka med ätpinnarna som låg på bordet. Han gillade dem och bestämde sig för att bara äta middagen med ätpinnar.
Han meddelade sin önskan och föräldrar, upptagna i att prata, gick med på det. När pizzan serverades började barnet använda ätpinnar och misslyckades flera gånger med att få pizza i munnen. Plötsligt såg föräldrarna det och beordrade att barnet inte skulle använda ätpinnar. Småbarn övertygade inte eftersom föräldrarna redan hade kommit överens om hans önskan tidigare.När föräldrar började lära sig att äta pizza endast med kniv och gaffel ifrågasatte småbarnet tron, men jag vill bara äta den med ätpinnar och varför är det fel? Och medan han använde ätpinnar när han inte kunde äta sin favoritpizza, blev han otålig och slängde slutligen ätpinnarna och bestämde sig för att inte äta pizza också. Föräldrar, frustrerade också, kunde inte göra någonting och familjens middagstid visade sig vara den värsta tiden på dagen.
Byt nu ut några ord i ovanstående para som följande och tänk igen om det:
Föräldrar: Projektledningsgrupp inklusive affärsanalytiker, säljare, utvecklingschef och arkitektgrupp.
Småbarn: Kund / slutanvändare
Pizza: produkt / applikation
Ätpinnar: misstag
Den mest favoritapplikationen är bara favorit tills användaren inte gör misstag och inte ser programmets värsta beteende. En gång erfaren, kommer användaren aldrig tillbaka till applikationen. Och därför, som testare, är det mycket nödvändigt att förstå användarens tänkesätt , hur han förväntas uppträda, vad fel han kan göra med applikationen, vad som kan vara det värsta misstaget och mycket mer.
För det mesta har jag blivit tillfrågad i forum såväl som av egna teammedlemmar om hur man kan replikera användarens upplevelse under testningen. Mitt svar har alltid varit enkelt - Var en användare :)
Även om det är lätt att säga än att implementera är det rätt tid för mjukvarutestningsindustrin att gå in i revolutionens riktning där användarupplevelse och feedback är viktigare än någonting annat.
Hur en testare kan tänka som slutanvändare?
Presenterar härmed några typiska exempel på att bete sig som slutanvändare och hitta överraskningar , Jag har observerat de senaste dagarna:
# 1) När man testade ett datumfält, när en användare valde eller manuellt angav korrekt datumvärde, fungerade det bra. Men när användaren slutade ange ett helt felaktigt värde som 12/00 // och klickade på OK fick han ett felmeddelande om ogiltigt datumvärde.
Nu korrigerar inte användaren datumet men uppdaterar sidan. Vad ska hända? Många av er kan gissa vad som ska hända, men kan ni tänka på vad som hände med applikationen? Efter uppdatering av sidan presenterades en användare med följande och samma värde sparades också i en databas.
Så ... testaren har replikerat användaren här, kom överens?
#två) När du testade en applikation, där arbetsflödet ska skicka in olika formulär i särskild ordningsföljd om de följde ordern, fungerade det bra. Men tänk om användaren försökte gå tillbaka till formulär nr 3, från formulär nr 5?
Återigen, snarare än att tänka på vad som ska hända, låt oss se vad som hände ...
Tester var förbluffad men kände sig stolt över att visa sig själv som användare ... .. Överens?
# 3) Efter lyckad inloggning klickar användaren på webbläsarens bakåtknapp. Återigen, låt oss se vad som hände ...
Autentiseringsuppgifterna borde ha rensat men det gjorde det inte. På denna inloggningssida klickar en användare på Glömt ditt lösenordslänk. Var tydlig att användaren redan hade loggat in och varit på inloggningssidan genom att klicka på bakåtknappen i webbläsaren. Klicket på Glömt ditt lösenord navigerade användaren till programmets startsida.
Testaren vände sig till användaren ... ..God?
spionapp för iPhone och Android
# 4) Efter att ha observerat webbadressen för söksidan (http: //x.x.x.x: y / # / Sök) för applikationen ändrade testaren webbadressen som http: //x.x.x.x: y / # / Sök / test? och kan du tänka vad som skulle ha hänt?
Tja, applikationen kraschade och testaren vände sig igen till användaren ... Jag hoppas att du inte håller med.
Slutsats
Jag antar att jag via dessa exempel har förmedlat tillräckligt med vad jag ville.
Verkligen betyder testning inte att kontrollera arbetsflödet för applikationen och det betyder inte heller att bryta applikationen men det betyder verkligen att kolla användarens upplevelse även när han gör misstagen.
Om författaren: Detta inlägg är skrivet av STH-teammedlem Bhumika Mehta. Hon är projektledare med 10+ års erfarenhet av programvarutestning. Hon uppskattar också bra idéer och innovationer och risker. Och naturligtvis hatar monotont arbete, människor och miljö.
Och ja, låt oss vända testaren i oss själva till slutanvändaren .... :)
Så ... ... vi skulle vilja höra fler sådana exempel från dig och skulle vilja ha dina åsikter också.
Rekommenderad läsning
- GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide
- Testning av webbplatsens kakor och testfall för testning av webbapplikationskakor
- Användarautentisering i MongoDB
- Test av e-postvalidering: Hur man testar e-postfunktionaliteten för en applikation
- Tjäna pengar, testa karriärprogramvara och hemligheter från en rikaste testare
- 5 saker en nybörjare (och testare) borde veta om programvarutestning
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Ad-hoc-testning: Hur man hittar fel utan en formell testprocess