A pénteki Safari-hiba, ami megtanított a tesztidőszakra

Egy konferenciaoldalon dolgoztunk, ahol napokon belül indult a regisztráció. A gépeinken tökéletesen futott. Egymás gépén is megnéztük, ott is jó volt. Aztán valaki megnyitotta egy valódi iPhone-on, és az oldal az első betöltésnél másodpercekre megdermedt.

Miért nem vettük észre

Mert mindenki azon nézte, amije volt. Asztali gépen ez a hiba nem létezik. A magyarázat egyszerű: a telefonban sokkal kevesebb a szabad memória, mint egy laptopban. Ami nálunk elfér, az ott már nem.

• A saját géped a legrosszabb tesztkörnyezet, mert ott van a legtöbb erőforrás.
• A fejlesztői eszköz mobilnézete csak a méretet utánozza, a korlátokat nem.
• A Facebook és a Messenger beépített böngészője sem ugyanaz, mint a telefon saját böngészője.

Kétszer is rossz nyomon jártunk

Sorra kivettük a szokásos gyanúsítottakat, és a fagyás csökkent. Kétszer is kijelentettük, hogy megvan az ok. Mindkétszer tévedtünk.

Elvétellel legfeljebb azt tudod meg, hogy valami a levettek közül számított. Azt nem, hogy melyik.

A választ az adta meg, amikor egyesével visszatettük a gyanúsítottakat, és mindig ugyanazzal a kóddal hasonlítottuk össze.

Amit azóta másképp csinálunk

• Élesítés előtt kötelező a próba valódi telefonon, nem elég a fejlesztői eszköz.
• Külön nézzük a telefon saját böngészőjét és a közösségi appok beépített böngészőjét.
• Az élesítés és a valódi forgalom közé hagyunk pár nap tesztidőt.

Ezúttal szerencsénk volt: pénteken derült ki, a regisztráció még nem indult el. Ha ugyanez az első nagy roham közben jön elő, a jelentkezők fele egy befagyott oldalt lát, és nem próbálkozik újra.

A tesztidőszak nem a fejlesztés meghosszabbítása. Az a hely, ahol a hiba még olcsó.