Jak testovat systémy POS bez skutečného hardwaru

Co můžete testovat bez hardwaru

Mnohem víc, než si lidé myslí. Můžete ověřit vyhledání produktu, chování přidání do košíku, změny množství, pravidla slev, přiřazení zákazníka, obnovení fokusu, zpracování chyb a mnoho krajních případů, které vidí pokladní, aniž byste se dotkli skutečné čtečky.

Klíčem je oddělit logiku postupu od ověření hardwaru. Pokud je problém v tom, jak POS reaguje na vstup, změny stavu nebo výsledky vyhledání, testování v softwaru obvykle stačí, aby se našel. Pokud je problém ve čtečkách, tiskárnách, terminálech nebo omezeních USB, tam se kolo hardwaru stává nutným.

Začněte postupem čtečky

Ve většině systémů POS je čtečka první závislost, které se lidé bojí. Naštěstí patří i k těm, které se dobře simulují nejsnáz, protože se mnoho čteček chová jako klávesnice.

Proto je nástroj pro emulaci čtečky čárových kódů silný začátek testování POS. Můžete řídit stejné pole hledání nebo zadání položky, které se používá u pokladny, a ověřit, jak obrazovka reaguje, když hodnoty čárového kódu přijdou rychle, s koncovým Enter nebo bez něj.

Sestavte malou, ale realistickou testovací matici

Nejsnazší cesta k mělkému pokrytí je otestovat jeden produkt na šťastné cestě. Lepší přístup je vytvořit malou matici typů položek, které odrážejí, jak se POS chová ve skutečných maloobchodních postupech.

Obvykle chci aspoň:

• jeden běžný produkt skladem
• jeden neznámý čárový kód
• jednu položku s úvodními nulami
• jednu omezenou položku nebo položku s věkovým omezením
• jeden produkt s akcí nebo cenovým pravidlem

Na tom záleží, protože chyby POS se často schovávají v obchodních pravidlech, ne v samotném skenování. Když je testovací sada příliš jednoduchá, obrazovka může vypadat stabilně, zatímco skutečný postup není.

Simulujte chování obsluhy, ne jen systému

Relace POS není úhledný jednotkový test. Pokladní se pohybují rychle, kliknou do špatného pole, položky naskenují znovu, výzvy zavřou příliš brzy a pracují pod časovým tlakem. Pokud testovací případy bez hardwaru tuhle realitu nemodelují, pokrytí bude vypadat líp, než jaké je.

Zkuste scénáře jako tyto:

1. naskenujte stejnou položku dvakrát rychle
2. skenujte, dokud je otevřené modální okno
3. položku odeberte a naskenujte ji znovu
4. spusťte přepsání vedoucím a skenujte znovu
5. fokus schválně ztraťte a potvrďte, že se rozhraní vzpamatuje

To jsou realistická selhání a přesně takové případy vám emulátor čárového kódu pomáhá opakovat bez únavy.

Vrstvená prostředí používejte schválně

Pro testování POS mám rád tři vrstvy:

• místní vývoj s nasazenými daty a emulátorem čárového kódu
• přípravu se skutečnou logikou cen, daní a zásob
• ověření hardwaru na skutečném terminálu před vydáním

Drahý čas hardwaru tak zůstane soustředěný na malou sadu chyb, které zařízení skutečně vyžadují. Vývojáři mohou většinu vad postupu vyčistit místně, QA může širší scénáře ověřit v přípravě a specialisté na hardware se mohou soustředit na problémy na úrovni zařízení.

Vědět, co pořád vyžaduje skutečný hardware

Testování bez hardwaru je silné, ale má meze. Skutečná zařízení pořád potřebujete pro:

• párování čtečky a chování ovladače
• výstup tiskárny účtenek a zacházení s papírem
• komunikaci s platebním terminálem
• omezení USB rozbočovače a kiosku
• síťová a terminálová omezení konkrétní prodejny

Upřímnost k těmto mezím zbytek procesu posiluje. Cílem není předstírat, že hardware nezáleží. Cílem je přestat plýtvat časem hardwaru na problémy, které šlo chytit dřív.

Kde se týmy obvykle mýlí

Nejčastější chyba je čekat na celou hardwarovou linku, než se otestuje něco smysluplného. Zní to opatrně, ale obvykle to chyby zdržuje, místo aby jim bránilo. Když vyhledání produktu selže, protože pole hledání ztratí fokus po výzvě ke slevě, hardware tu chybu kouzlem nesnadní pochopit.

Další častý problém je testovat jen jednu klidnou šťastnou cestu. Skutečné pokladní relace jsou hlučné. Obsluha skenuje rychle, opakuje položky, couvá z výzev a přepíná mezi postupy. Testování POS bez hardwaru by tuhle realitu mělo odrážet, jinak mine právě problémy, kterých si personál všimne jako prvních.

Praktický příklad

Představte si pokladní obrazovku, kde má skenování produktu přidat položku, aktualizovat košík a hned vrátit fokus do pole hledání produktu. Většinu z toho můžete ověřit bez hardwaru:

• simulujte vstup čtečky čárových kódů do pole hledání
• ověřte, že se položka přidala správně
• ověřte, že se uplatní akce a cenová pravidla
• potvrďte, že další skenování dopadne do stejného pole

Teprve až to projde, potřebujete fyzickou čtečku pro konečnou jistotu. Tohle pořadí šetří čas a hardwarovou relaci obvykle dělá užitečnější.

Rychlá kontrola reality

Systémy POS můžete bez skutečného hardwaru testovat mnohem účinněji, než mnoho týmů předpokládá. Začněte realistickou simulací čtečky, spojte ji se stabilními testovacími daty a nejdřív se soustřeďte na chování postupu. Pak použijte skutečný hardware pro užší sadu problémů, které odhalí jen zařízení. Ten přístup je rychlejší, levnější a obvykle ukázněnější než spoléhat se na hardware od začátku.