Kako testirati aplikaciju prije lansiranja: praktičan plan

Da testirate aplikaciju prije lansiranja, zapišite nekoliko tokova koje korisnik mora moći da završi, prođite svaki kao potpuno nov korisnik na laptopu i telefonu, pa isprobajte načine na koje mogu poći po zlu: prazni podaci, loš unos, drugi nalog, spora veza. Testirajte sve što uključuje novac ili privatne podatke s posebnom pažnjom, i ponovite glavne tokove na živom URL-u nakon objavljivanja. Na kraju posmatrajte nekoga ko nikada nije vidio aplikaciju dok pokušava da je koristi.

Za ovo vam ne treba tim za kvalitet ili okvir za testiranje. Potrebna vam je lista, sat-dva i disciplina da je zaista prođete.

Korak 1: Zapišite tokove koji su bitni

Tok je zadatak od početka do kraja koji korisnik dolazi da obavi. Većina aplikacija ima tri do šest koji su zaista važni. Za aplikaciju za zakazivanje:

Registrujte se i potvrdite nalog
Pronađite čas i zakažite ga
Otkažite zakazivanje
Platite paket časova
Osoblje: pogledajte današnja zakazivanja

Ako ste pisali korisničke priče, njihovi kriterijumi prihvatanja su već vaši testni slučajevi. Ako niste, napišite po jednu liniju za svaki tok s tim šta znači „uspjeh".

Rangirajte ih. Tokovi koji zarađuju novac ili koje svaki korisnik koristi (registracija, prijava, glavna radnja) testiraju se prvi i najviše.

Korak 2: Testirajte sretnu putanju kao novi korisnik

„Sretna putanja" je tok koji ide tačno onako kako je zamišljen. Testirajte ga kako bi ga doživio neznanac:

Koristite privatni prozor pregledača, da niste prijavljeni i nemate sačuvane podatke.
Koristite svjež nalog s pravom e-adresom koju možete provjeriti.
Počnite s početne stranice ili linka, a ne sa stranice koju ste označili dok ste pravili aplikaciju.

Novi korisnici nemaju podatke. Mnoge greške se pojave tek kada je lista prazna, profil nema fotografiju ili ništa još nije kupljeno. Vaš nalog, pun testnih podataka, sakriva ih.

Korak 3: Pokušajte da je srušite

Sada ponovite svaki tok i namjerno uradite pogrešnu stvar.

Pokušajte ovo	Šta provjeravate
Pošaljite prazne formulare ili samo razmake	Obavezna polja su provjerena, uz jasnu poruku
Veoma dug tekst, emoji, imena s dijakritikom	Raspored ostaje ispravan, podaci se ispravno čuvaju
Pogrešni formati: slova u polju za telefon, datum u prošlosti	Validacija i na stranici i na serveru
Dva puta kliknite dugme za slanje	Nema dupliranih narudžbi ili zakazivanja
Dugme nazad usred toka	Nema pokvarenog stanja ni izgubljenih podataka
Osvježite svaku stranicu	Podaci ostaju; nema prazne stranice ni greške 404
Odjavite se, pa pritisnite nazad	Privatne stranice se ne prikazuju
Dva taba koja mijenjaju istu stvar	Posljednje čuvanje tiho ne briše prvo

Osvježavanje vrijedi posebno naglasiti: ako aplikacija radi kad kliknete kroz nju, ali osvježavanje dublje stranice daje 404, pogledajte kako popraviti greške 404 nakon objavljivanja.

Korak 4: Testirajte dozvole s dva naloga

Ovo je najvažniji test za svaku aplikaciju s nalozima, a najčešće se preskače.

Napravite dva obična korisnika, A i B, i (ako aplikacija ih ima) administratora.

Kao A kreirajte zapis. Prijavite se kao B. Da li B može da ga vidi, izmijeni ili obriše? Ne bi trebalo, osim ako je tako zamišljeno.
Kao A kopirajte URL jednog od vaših zapisa. Prijavite se kao B i direktno otvorite taj URL.
Kao obični korisnik pokušajte otvoriti administratorske stranice ukucavanjem njihovih URL-ova.
Potpuno se odjavite i isprobajte iste URL-ove.

Ako nađete problem ovdje, nemojte lansirati dok ga ne popravite. Provjera se mora dogoditi na serveru, a ne samo sakrivanjem dugmeta. Naša sigurnosna lista za aplikacije napravljene uz AI ide dublje.

Korak 5: Testirajte na pravim uređajima

Otvorite aplikaciju na stvarnom telefonu, a ne samo u uskom prozoru pregledača.

Možete li dodirnuti svako dugme bez zumiranja?
Da li tastatura prekriva polje u koje kucate?
Da li tabele i široki sadržaj skroluju ili se prelamaju, umjesto da guraju stranicu u stranu?
Da li je tekst čitljiv bez raširivanja prstima?

Isprobajte barem jedan iPhone (Safari) i jedan Android telefon (Chrome) ako možete posuditi. Safari naročito ima svoje osobenosti s datumima, videom i elementima fiksne pozicije.

Korak 6: Testirajte novac i e-poštu od početka do kraja

Sve što naplaćuje kartice ili šalje e-poštu treba potpuni prolazak.

Plaćanja. Koristite test režim vašeg provajdera plaćanja i probne brojeve kartica. Provjerite uspješno plaćanje, odbijenu karticu i otkazanu kupovinu. Potvrdite da se narudžba ili pretplata pojavljuje u aplikaciji nakon plaćanja, a ne samo na kontrolnoj tabli provajdera. Ako vaša aplikacija koristi webhook-ove (poruke koje provajder plaćanja šalje vašem serveru), provjerite da stižu na objavljenoj aplikaciji, a ne samo u razvoju. Zatim, prije lansiranja, prebacite se na žive ključeve i napravite jednu malu pravu kupovinu koju refundirate.

E-pošta. Registrujte se s pravim adresama kod dva ili tri različita provajdera. Provjerite da poruke stižu, da nisu u spamu i da svaki link u njima vodi na živi domen, a ne na adresu pregleda.

Korak 7: Provjerite brzinu i greške

Otvorite alate za developere u pregledniku (desni klik → Inspect) i pogledajte karticu Console na svakoj glavnoj stranici. Crvene greške vrijedi popraviti čak i kad ništa ne izgleda pokvareno.
Učitajte sajt na telefonu preko mobilnih podataka, a ne Wi-Fi-ja. Ako prvi ekran traje nekoliko sekundi, prvo pogledajte veličine slika.
Pokrenite besplatnu reviziju kao što je Lighthouse u Chrome alatima za developere za brzu sliku performansi i pristupačnosti.

Korak 8: Testirajte objavljenu aplikaciju, a ne samo pregled

Pregled i objavljena aplikacija nisu isto okruženje. Prije nego što o lansiranju obavijestite ljude, ponovite glavne tokove na živom URL-u:

Da li su sve varijable okruženja i tajne postavljene za objavljenu aplikaciju?
Da li koristi pravu bazu, s podacima koje očekujete?
Da li preusmjeravanja nakon prijave i linkovi u e-pošti koriste živi domen?
Da li se osvježavanje dublje stranice ispravno učitava?

Korak 9: Posmatrajte nekoga dok koristi aplikaciju

Dajte jednoj ili dvije osobe cilj („zakažite čas joge za subotu"), a ne uputstva. Posmatrajte, ne pomažite, i zapisujte gdje oklijevaju. To je najbrži način da pronađete zbunjujuće tekstove i skrivena dugmad. Za veću verziju ovoga pogledajte kako sprovesti beta testiranje.

Kada naiđu na grešku, zapišite je kako treba, s koracima, očekivanim i stvarnim rezultatom. Naš vodič kako napisati dobar izvještaj o grešci pokazuje format.

Korištenje AI-ja za testiranje

Ako pravite aplikaciju uz AI, možete ga zamoliti da pomogne u planiranju i izvođenju testova:

Navedi glavne tokove korisnika u ovoj aplikaciji i, za svaki, rubne slučajeve koji su najvjerovatnije da pucaju: prazna stanja, loš unos, dozvole i osvježavanje. Stavi to u kontrolnu listu koju mogu proći.

Prijavi se kao dva različita testna korisnika i provjeri može li korisnik B vidjeti ili mijenjati bilo šta što je korisnik A kreirao, uključujući i direktno otvaranje URL-ova zapisa od A. Prijavi šta nađeš prije nego što išta popraviš.

Izvještaj AI-ja o testiranju tretirajte kao prvi prolaz. Ipak sami prođite kroz tokove s novcem i dozvolama.

Testiranje u Mythexu

U Mythexu komanda /test pokreće App Testing: agent upravlja pregledačem nad vašim pregledom uživo, klika kroz stranice, pravi snimke ekrana i prijavljuje pokvarene tokove u chatu. Najbolje radi s konkretnim tokom, poput „testiraj registraciju i zakazivanje časa". Ispravite ono što nađe pomoću /fix ili običnom porukom, pa ponovo pokrenite /test. App Testing koristi pregled, zato glavne tokove na objavljenom URL-u provjerite sami nakon objavljivanja. Pogledajte App Testing u dokumentaciji i naš vodič kako debagovati aplikaciju napravljenu uz AI za slučaj da nešto pukne.

Česte greške

Testiranje samo kao vi. Vaš admin nalog s puno podataka sakriva greške praznih stanja i dozvola.
Testiranje samo na laptopu. Mnogi posjetioci sajtova dolaze s telefona.
Preskakanje drugog naloga. Curenje podataka između korisnika je najozbiljnija greška s kojom aplikacija može da se lansira.
Vjerovanje pregledu. Živa aplikacija ima drugačija podešavanja; testirajte i nju.
Popravljanje grešaka bez ponovnog testiranja obližnjih dijelova. Popravka jednog formulara može pokvariti drugi koji dijeli isti kod.

Kontrolna lista prije lansiranja

Glavni tokovi zapisani i rangirani
Svaki tok prolazi kao potpuno novi korisnik u privatnom prozoru
Prazan, loš, dug i duplirani unos je obrađen
Osvježavanje radi na svakoj stranici
Korisnici ne mogu vidjeti ni mijenjati tuđe podatke, ni preko URL-a
Administratorske stranice blokirane za obične korisnike i odjavljene posjetioce
Radi na pravom iPhone-u i Android telefonu
Plaćanja testirana: uspjeh, odbijanje, otkazivanje, i aplikacija se nakon toga ažurira
E-pošta stiže, izbjegava spam i vodi na živi domen
Nema crvenih grešaka u konzoli na glavnim stranicama
Glavni tokovi ponovljeni na objavljenom URL-u
Najmanje jedna spoljašnja osoba je isprobala dok ste posmatrali

Pitanja

Koliko testiranja treba mala aplikacija prije lansiranja?

Dovoljno da budete sigurni da glavni tokovi rade za potpuno novog korisnika na telefonu i laptopu, da korisnici ne mogu vidjeti podatke jedni drugih i da sve što uključuje novac radi od početka do kraja. Za većinu malih aplikacija to je nekoliko fokusiranih sati, a ne sedmice.

Da li su mi potrebni automatski testovi za MVP?

Nisu nužno. Ručno testiranje osnovnih tokova uhvati većinu grešaka koje blokiraju lansiranje. Automatski testovi počinju da se isplaćuju kada često mijenjate aplikaciju i želite brzo da znate da niste pokvarili ono što je ranije radilo.

Da li da testiram na pregledu ili na živoj aplikaciji?

Oboje. Temeljno testirajte u pregledu, a zatim ponovite glavne tokove na objavljenoj aplikaciji, jer nedostajuće varijable okruženja, druga baza ili podešavanja rutiranja mogu učiniti da se živa verzija ponaša drugačije.

Ko treba da testira moju aplikaciju, osim mene?

Barem jedna osoba koja je nikada nije vidjela. Dajte joj cilj, a ne uputstva, i posmatrajte bez pomaganja. Graditelji nesvjesno izbjegavaju putanje koje pucaju.