Hogyan tesztelj POS-rendszereket valódi hardver nélkül

Mit tesztelhetsz hardver nélkül

Sokkal többet, mint sokan gondolják. Ellenőrizheted a termékkeresést, a kosárba tételt, a mennyiségváltást, a kedvezményszabályokat, a vevőhozzárendelést, a fókusz visszaállását, a hibakezelést és sok pénztáros felé néző szélső esetet anélkül, hogy a valódi olvasóhoz nyúlnál.

A kulcs a folyamatlogika és a hardveres ellenőrzés szétválasztása. Ha a gond az, hogyan reagál a POS a bemenetre, az állapotváltozásra vagy a keresési eredményre, a szoftveres teszt általában elég a megtalálásához. Ha a gond az olvasó, a nyomtató, a terminál vagy az USB-korlátozás, ott válik szükségessé a hardveres kör.

Kezdd az olvasó folyamatával

A legtöbb POS-rendszerben az olvasó az első függőség, ami miatt az emberek aggódnak. Szerencsére ez az egyik legkönnyebben jól szimulálható is, mert sok olvasó billentyűzetként viselkedik.

Ezért erős kiindulópont a POS-teszteléshez egy vonalkódolvasó-emulátor eszköz. Ugyanazt a keresőmezőt vagy tételbevitelt vezérelheted, amelyet a pénztárnál használnak, és megnézheted, hogyan reagál a képernyő, ha a vonalkódértékek gyorsan érkeznek, záró Enterrel vagy anélkül.

Építs kicsi, de valósághű tesztmátrixot

A sekély lefedettség legkönnyebb útja egyetlen boldog úti termék tesztelése. Jobb megközelítés a tételtípusok kis mátrixa, amely azt tükrözi, hogyan viselkedik a POS a valódi kiskereskedelmi folyamatokban.

Általában legalább ezeket akarom:

• egy normál, készleten lévő terméket
• egy ismeretlen vonalkódot
• egy vezető nullás tételt
• egy korlátozott vagy életkorhoz kötött tételt
• egy akcióval vagy árszabállyal rendelkező terméket

Ez számít, mert a POS-hibák gyakran az üzleti szabályokban bújnak meg, nem magában a beolvasásban. Ha a tesztkészlet túl egyszerű, a képernyő stabilnak tűnhet, miközben a valódi folyamat nem az.

A kezelő viselkedését szimuláld, ne csak a rendszerét

Egy POS-munkamenet nem rendezett egységteszt. A pénztárosok gyorsan mozognak, rossz mezőre kattintanak, újraolvassák a tételeket, túl korán zárják be a kérdéseket, és időnyomás alatt dolgoznak. Ha a hardver nélküli teszteseteid nem modellezik ezt a valóságot, a lefedettség jobbnak látszik, mint amilyen.

Próbálj ki ilyen helyzeteket:

1. olvasd be kétszer gyorsan ugyanazt a tételt
2. olvass be, miközben egy modális ablak nyitva van
3. vedd ki a tételt, és olvasd be újra
4. indíts vezetői felülírást, majd olvass be megint
5. szándékosan veszítsd el a fókuszt, és erősítsd meg, hogy a felület helyreáll

Ezek valós kudarcok, és pontosan olyan esetek, amelyeket egy emulátor fáradtság nélkül segít ismételni.

Használj szándékosan réteges környezeteket

POS-teszteléshez három réteget szeretek:

• helyi fejlesztés feltöltött adatokkal és vonalkód-emulátorral
• staging valódi ár-, adó- és készletlogikával
• hardveres ellenőrzés valódi terminálon a kiadás előtt

Így a drága hardveridő arra a kis hibahalmazra összpontosul, amelyhez tényleg eszköz kell. A fejlesztők a folyamat hibáinak nagy részét helyben elháríthatják, a QA szélesebb helyzeteket ellenőrizhet stagingen, a hardverspecialisták pedig az eszközszintű gondokra koncentrálhatnak.

Tudd, mihez kell még mindig valódi hardver

A hardver nélküli tesztelés erős, de vannak határai. Valódi eszköz kell még:

• az olvasó párosításához és az illesztőprogram viselkedéséhez
• a bizonylatnyomtató kimenetéhez és a papírkezeléshez
• a fizetési terminál kommunikációjához
• USB-elosztó és kioszk korlátozásaihoz
• az üzletre jellemző hálózati és terminálkorlátokhoz

E határok őszinte kimondása erősebbé teszi a folyamat többi részét. A cél nem az, hogy úgy tegyünk, mintha a hardver nem számítana. A cél az, hogy ne pazaroljunk hardveridőt olyan gondokra, amelyeket korábban el lehetett volna kapni.

Ahol a csapatok általában elrontják

A leggyakoribb hiba teljes hardversorra várni, mielőtt bármi érdemit tesztelnénk. Ez óvatosnak hangzik, de általában késlelteti a hibákat, nem megelőzi őket. Ha egy termékkeresés azért bukik, mert a mező elveszíti a fókuszt egy kedvezménykérdés után, a hardver nem teszi varázsütésre érthetőbbé a hibát.

Másik gyakori gond csak egy nyugodt boldog út tesztelése. A valódi pénztári munkamenetek zajosak. A kezelők gyorsan olvasnak, ismétlik a tételeket, visszalépnek a kérdésekből, és folyamatot váltanak. A hardver nélküli POS-tesztelésnek ezt a valóságot kell tükröznie, különben pont azokat a gondokat hagyja ki, amelyeket a személyzet először észrevesz.

Gyakorlati példa

Képzelj el egy pénztári képernyőt, ahol a termék beolvasásának hozzá kell adnia a tételt, frissítenie a kosarat, és azonnal vissza kell adnia a fókuszt a keresőmezőnek. Ennek nagy részét hardver nélkül ellenőrizheted:

• szimuláld az olvasó bemenetét a keresőmezőbe
• ellenőrizd, hogy a tétel helyesen került-e be
• ellenőrizd, hogy az akciók és az árszabályok érvényesülnek-e
• erősítsd meg, hogy a következő beolvasás ugyanabba a mezőbe kerül

Csak ezután kell a fizikai olvasó a végső bizalomhoz. Ez a sorrend időt spórol, és általában hasznosabbá teszi a hardveres munkamenetet.

Gyors valóságellenőrzés

A POS-rendszereket valódi hardver nélkül sokkal hatékonyabban lehet tesztelni, mint sok csapat feltételezi. Kezdd valósághű olvasószimulációval, párosítsd stabil tesztadattal, és először a folyamat viselkedésére figyelj. Utána a valódi hardvert arra a szűkebb gondhalmazra használd, amelyet csak az eszközök tudnak feltárni. Ez a megközelítés gyorsabb, olcsóbb, és általában fegyelmezettebb, mint az elejétől a hardverre hagyatkozni.