Kada treba da počne QA provera sajta?
Najskuplje greške često nastaju iz nejasnog zahteva, a ne iz loše napisane linije koda. Zato provera počinje pregledom ciljeva, korisničkih scenarija, dizajna i kriterijuma prihvatanja. Tim unapred definiše šta mora da se dogodi kada osoba pošalje formu, promeni jezik, doda proizvod u korpu ili otvori stranicu na telefonu. Kada su očekivanja zapisana, dizajner, programer i tester proveravaju isti rezultat. Problemi se tada otkrivaju dok ih je još jednostavno ispraviti.
Kako test plan prati poslovni rizik?
Nije svaki deo sajta podjednako važan. Greška u dekorativnoj animaciji i greška u plaćanju nemaju istu posledicu. Test plan zato prvo pokriva glavne tokove: dolazak na odredišnu stranicu, pronalaženje usluge, unos podataka, kupovinu, rezervaciju ili kontakt. Zatim se proveravaju granični slučajevi, kao što su prazna polja, pogrešan format email adrese, dugačak naslov ili prekinuta mrežna veza. Prioriteti pomažu timu da ograničeno vreme uloži tamo gde kvar može izgubiti kupca ili podatke.
Koje uloge imaju manuelno i automatizovano testiranje?
Manuelno testiranje je korisno kada treba proceniti razumljivost sadržaja, ponašanje interfejsa i situacije koje nisu potpuno predvidive. Automatizovani testovi brzo ponavljaju stabilne provere, na primer prijavu, obračun cene ili slanje forme posle svake izmene koda. TestingMVP takođe opisuje kombinovanje manuelnog i automatizovanog testiranja, kao i funkcionalne, UI, performansne, kompatibilne, regresione, integracione i API provere. Izbor zavisi od proizvoda, rizika i učestalosti promena, a ne od želje da se automatizuje svaki ekran.
Kako proveriti sajt u stvarnim uslovima?
Pregled samo na računaru programera nije dovoljan. Sajt treba otvoriti na različitim veličinama ekrana, u glavnim pregledačima i na uređajima koje publika zaista koristi. Proveravaju se dodirne mete, tastatura, vidljiv fokus, kontrast, čitanje poruka o grešci i ponašanje pri sporijoj vezi. Slike, fontovi i skripte moraju da se učitaju bez blokiranja važnog sadržaja. Ovakva provera otkriva kvarove koji se ne vide u idealnom razvojnom okruženju, ali direktno utiču na stvarnog posetioca.
Kako dobra prijava greške ubrzava popravku?
Prijava treba da omogući drugoj osobi da ponovi problem. Korisno je navesti stranicu, uređaj, pregledač, tačne korake, očekivani rezultat i ono što se zaista dogodilo. Snimak ekrana ili kratak video pomaže kada je problem vizuelan, dok zapis iz konzole može biti važan za tehnički kvar. Ozbiljnost opisuje posledicu za korisnika, a prioritet određuje redosled rada. Jasna prijava smanjuje dopisivanje i ostavlja više vremena za popravku i ponovnu proveru.
Zašto je objava kontrolna tačka, a ne kraj provere?
Pre objave tim prolazi dogovorene kriterijume: glavni tokovi rade, kritične greške su zatvorene, kontakt podaci su tačni, rezervna kopija postoji i produkciona konfiguracija je proverena. Posle objave sledi kratka provera najvažnijih funkcija na pravom domenu. Greške iz praćenja rada, poruke korisnika i promene u pregledačima zatim ulaze u naredni ciklus testiranja. Tako QA postaje deo održavanja proizvoda i svaka nova izmena dobija proveru pre nego što ugrozi ono što je ranije radilo.