how tester can think
Prizor : V restavracijo je prispela tričlanska družina - starši in malček. Po naročilu najbolj priljubljene pice se je družina sprostila in malček se je začel igrati s palicami, položenimi na mizo. Všeč so mu bili in odločil se je, da bo večerjo jedel samo s palčkami.
Napovedal je svojo željo in starši, zaposleni v pogovorih, so se strinjali. Ko je bila pica postrežena, je malček začel uporabljati palčke in večkrat ni uspel spraviti pice v usta. Nenadoma so to opazili starši in malčku ukazali, naj ne uporablja palčk. Malček ni prepričal, saj so se starši že prej strinjali z njegovo željo.Ko so starši začeli poučevati o uživanju pice samo z nožem in vilicami, je malček podvomil v to prepričanje, vendar jo želim jesti samo s palčkami in zakaj je narobe? In medtem ko je uporabljal palčke, ko ni mogel pojesti svoje najljubše pice, je postal nestrpen in je na koncu vrgel palčke stran in se odločil, da tudi pice ne bo jedel. Tudi starši, ki so bili razočarani, niso mogli storiti ničesar, čas družinske večerje pa je bil najslabši čas dneva.
Zdaj nadomestite nekaj besed v zgornjem odstavku, kot sledi, in premislite o tem:
Starši: Skupina za vodenje projektov, vključno s poslovnim analitikom, prodajalcem, vodjo razvoja in arhitekturno skupino.
Malček: Stranka / končni uporabnik
Pica: izdelek / aplikacija
Palčke: napaka
Najbolj priljubljena aplikacija je le najljubša, dokler se uporabnik ne zmoti in ne vidi najslabšega vedenja aplikacije. Ko je uporabnik izkušen, se nikoli več ne vrne v aplikacijo. Zato je kot preizkuševalec zelo nujno razumeti miselnost uporabnika , kako naj bi se obnašal, kaj lahko stori z aplikacijo, kaj je lahko najhujša napaka in še veliko več.
Največkrat so me na forumih in tudi internih članih ekipe spraševali, kako ponoviti uporabniško izkušnjo med testiranjem. Moj odgovor je bil vedno preprost - Bodite uporabnik :)
Čeprav je enostavno reči kot implementirati, je pravi čas, da se industrija preizkušanja programske opreme premakne v smer revolucije, kjer so uporabniške izkušnje in povratne informacije pomembnejše od vsega drugega.
Kako preizkuševalec lahko razmišlja kot končni uporabnik?
Predstavljam vam nekaj tipični primeri vedenja kot končni uporabnik in iskanja presenečenj , V zadnjih nekaj dneh sem opazil:
# 1) Ko je uporabnik izbral datumsko polje, ko je uporabnik izbral ali ročno vnesel pravilno datumsko vrednost, je delovalo v redu. Ko pa je uporabnik na koncu vnesel popolnoma napačno vrednost, na primer 12/00 //, in kliknil V redu, se mu je prikazalo sporočilo o napaki glede neveljavne vrednosti datuma.
Zdaj uporabnik ne popravi datuma, ampak osveži stran. Kaj naj se zgodi? No, mnogi od vas lahko ugibate, kaj bi se moralo zgoditi, vendar si lahko omislite, kaj se je zgodilo z aplikacijo? Po osvežitvi strani je bil uporabniku predstavljeno naslednje in enaka vrednost je bila shranjena tudi v zbirki podatkov.
Torej ... tester je repliciral uporabnika sem, se strinjate?
#two) Med testiranjem aplikacije, pri kateri je potek dela v posebnem zaporedju predložiti različne obrazce, če je sledil vrstnemu redu, je delovalo dobro. Kaj pa, če bi se uporabnik poskušal vrniti na obrazec št. 3 iz obrazca št. 5?
Še enkrat, namesto da razmišljamo o tem, kaj bi se moralo zgoditi, poglejmo, kaj se je zgodilo ...
Tester je bil neumen, vendar je bil ponosen, ker se je izkazal za uporabnika ... ..Ali se strinjate?
# 3) Po uspešni prijavi uporabnik klikne gumb za nazaj v brskalniku. Še enkrat, poglejmo, kaj se je zgodilo ...
kakšna je razlika med linuxom in unixom
Poverilnice bi se morale očistiti, a se niso. Če nadaljujemo, na tej strani za prijavo uporabnik klikne povezavo Pozabljeno geslo. Jasno je, da se je uporabnik že prijavil in je bil na prijavni strani s klikom na gumb za nazaj v brskalniku. Klik na Pozabljeno geslo je uporabnika pomaknil na domačo stran aplikacije.
Tester se je obrnil na uporabnika ... ..Ali se strinjate?
# 4) Po ogledu URL-ja za iskalno stran (http: //x.x.x.x: y / # / Search) aplikacije je tester spremenil URL kot http: //x.x.x.x: y / # / Search / test? in ali lahko mislite, kaj bi se zgodilo?
No, aplikacija se je zrušila in tester se je spet obrnil na uporabnika ... .. Upam, da se ne boste strinjali.
Zaključek
Mislim, da sem s temi primeri posredoval dovolj, kar sem hotel.
Resnično testiranje ne pomeni preverjanja poteka dela aplikacije in tudi ne prekinitve aplikacije, vsekakor pa pomeni preverite uporabniško izkušnjo tudi ko dela napake.
O avtorju: To objavo je napisal član ekipe STH Bhumika Mehta. Je vodja projekta in ima več kot 10 let izkušenj s testiranjem programske opreme. Tudi ona ceni dobre ideje in inovacije ter tveganja. In seveda sovraži monotono delo, ljudi in okolje.
In ja, preizkusimo v sebi končnega uporabnika ... Se strinjate? :)
Torej ... .. radi bi slišali več takšnih primerov od vas in bi radi imeli tudi vaša mnenja.
Priporočeno branje
- Vadnica za testiranje grafičnega uporabniškega vmesnika: popoln priročnik za testiranje uporabniškega vmesnika (UI)
- Testiranje piškotkov spletnega mesta in primeri za testiranje piškotkov spletnih aplikacij
- Preverjanje pristnosti uporabnika v MongoDB
- Testiranje preverjanja e-pošte: Kako preizkusiti funkcijo e-pošte aplikacije
- Ustvarjanje denarja, kariera preizkušanja programske opreme in skrivnosti najbogatejšega preizkuševalca
- 5 stvari, ki bi jih začetnik (in preizkuševalec) moral vedeti o preizkušanju programske opreme
- Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
- Ad-hoc testiranje: Kako najti napake brez formalnega postopka testiranja