Paano subukan ang mga sistema ng POS nang walang tunay na hardware

Ano ang masusubok mo nang walang hardware

Higit pa sa inaakala ng marami. Mapapatunayan mo ang paghahanap ng produkto, pagdaragdag sa cart, pagbabago ng dami, mga tuntunin ng diskwento, pagtatalaga ng customer, pagbabalik ng focus, paghawak ng error, at maraming edge case na nakaharap sa kahera nang hindi hinahawakan ang tunay na scanner.

Ang susi ay paghiwalayin ang lohika ng daloy sa pagpapatunay ng hardware. Kung ang problema ay tungkol sa kung paano tumutugon ang POS sa input, mga pagbabago ng estado, o mga resulta ng lookup, karaniwang sapat ang pagsubok na nakabatay sa software para mahanap ito. Kung ang problema ay tungkol sa mga scanner, printer, terminal, o mga restriksyon ng USB, doon nagiging kailangan ang pass ng hardware.

Magsimula sa daloy ng scanner

Sa karamihan ng mga sistema ng POS, ang scanner ang unang dependency na inaalala ng mga tao. Sa kabutihang-palad, isa rin ito sa pinakamadaling gayahin nang maayos dahil maraming scanner ang kumikilos na parang teklado.

Kaya malakas na panimula sa pagsubok ng POS ang kasangkapan na emulator ng pantukoy ng barcode. Maaari mong patakbuhin ang parehong field ng paghahanap o input ng item na ginagamit sa rehistro at patunayan kung paano tumutugon ang screen kapag mabilis dumarating ang mga halaga ng barcode, may kasunod na Enter o wala.

Gumawa ng maliit ngunit makatotohanang matrix ng pagsubok

Ang pinakamadaling paraan para makakuha ng mababaw na saklaw ay ang pagsubok ng iisang produkto sa masayang landas. Mas mabuting paraan ang gumawa ng maliit na matrix ng mga uri ng item na sumasalamin sa kung paano kumikilos ang POS sa mga tunay na daloy ng retail.

Karaniwan gusto ko ng kahit:

• isang normal na produkto na nasa stock
• isang hindi kilalang barcode
• isang item na may nangungunang sero
• isang pinaghihigpitan o may edad na item
• isang produkto na may promosyon o tuntunin ng presyo

Mahalaga ito dahil madalas nagtatago ang mga bug ng POS sa mga tuntunin ng negosyo, hindi sa mismong pagbasa. Kung masyadong simple ang set ng pagsubok, maaaring mukhang matatag ang screen habang hindi ang tunay na daloy.

Gayahin ang ugali ng operator, hindi lang ang ugali ng sistema

Hindi maayos na unit test ang sesyon ng POS. Mabilis kumilos ang mga kahera, pumipindot sa maling field, nagbabasa ulit ng mga item, masyadong maagang isinasara ang mga prompt, at gumagawa sa ilalim ng presyon ng oras. Kung hindi ginagaya ng mga test case mong walang hardware ang realidad na iyon, mas maganda ang magmumukhang saklaw kaysa tunay.

Subukan ang mga senaryo gaya nito:

1. basahin nang mabilis nang dalawang beses ang parehong item
2. magbasa habang bukas ang modal
3. alisin ang item at basahin itong muli
4. i-trigger ang override ng manager at magbasa ulit
5. sadyang mawala ang focus at kumpirmahin na bumabawi ang UI

Makatotohanang mga pagkabigo ang mga ito, at eksaktong uri ng mga kaso na tinutulungan kang ulitin ng emulator ng barcode nang walang pagod.

Gumamit nang sadya ng mga layered na kapaligiran

Para sa pagsubok ng POS, gusto ko ang tatlong layer:

• lokal na paggawa na may seeded na datos at emulator ng barcode
• staging na may tunay na lohika ng presyo, buwis, at imbentaryo
• pagpapatunay ng hardware sa tunay na terminal bago ang release

Pinapanatili nitong nakatuon ang mahal na oras ng hardware sa maliit na hanay ng mga bug na tunay na nangangailangan ng aparato. Maaaring ayusin ng mga developer ang karamihan ng depekto ng daloy nang lokal, mapapatunayan ng QA ang mas malalawak na senaryo sa staging, at makakapagtuon ang mga espesyalista sa hardware sa mga isyu sa antas ng aparato.

Alamin kung ano ang nangangailangan pa rin ng tunay na hardware

Malakas ang pagsubok na walang hardware, ngunit may mga hangganan ito. Kailangan mo pa rin ng tunay na aparato para sa:

• pagpares ng scanner at ugali ng driver
• output ng printer ng resibo at paghawak ng papel
• komunikasyon ng terminal ng bayad
• mga restriksyon ng USB hub at kiosk
• mga hadlang ng network at terminal na partikular sa tindahan

Ang pagiging tapat tungkol sa mga hangganang ito ay nagpapatibay sa iba pang proseso. Hindi ang layunin ang magkunwaring hindi mahalaga ang hardware. Ang layunin ay itigil ang pagsasayang ng oras ng hardware sa mga isyung maaaring nahuli nang mas maaga.

Saan karaniwang nagkakamali ang mga koponan

Ang pinakakaraniwang pagkakamali ay ang paghihintay ng buong linya ng hardware bago subukan ang anumang makabuluhan. Mukhang maingat iyon, ngunit karaniwan nitong inaantala ang mga bug sa halip na pigilan. Kung nabigo ang paghahanap ng produkto dahil nawawala ang focus ng field pagkatapos ng prompt ng diskwento, hindi mahiwagang gagawing mas madaling unawain ng hardware ang bug na iyon.

Isa pang karaniwang isyu ang pagsubok lamang ng isang mahinahong masayang landas. Maingay ang mga tunay na sesyon ng checkout. Mabilis nagbabasa ang mga operator, inuulit ang mga item, umaatras sa mga prompt, at nagpapalit ng daloy. Dapat sumalamin ang pagsubok ng POS na walang hardware sa realidad na iyon, kung hindi ay mamimiss nito ang eksaktong mga isyung unang mapapansin ng mga tauhan.

Praktikal na halimbawa

Isipin ang screen ng checkout kung saan ang pagbasa ng produkto ay dapat magdagdag ng item, i-update ang cart, at agad ibalik ang focus sa input ng paghahanap ng produkto. Mapapatunayan mo ang karamihan niyan nang walang hardware:

• gayahin ang input ng pantukoy ng barcode sa field ng paghahanap
• patunayan na tama ang naidagdag na item
• patunayan na nalalapat ang mga promosyon at tuntunin ng presyo
• kumpirmahin na ang susunod na pagbasa ay napupunta sa parehong field

Pagkatapos lamang nitong pumasa kailangan mo ng pisikal na scanner para sa huling kumpiyansa. Nakakatipid ng oras ang pagkakasunod na ito at karaniwang ginagawang mas kapaki-pakinabang ang sesyon ng hardware.

Mabilis na pagsusuri ng realidad

Mas epektibo mong masusubok ang mga sistema ng POS nang walang tunay na hardware kaysa inaakala ng maraming koponan. Magsimula sa makatotohanang simulation ng scanner, ipares ito sa matatag na test data, at unahin ang ugali ng daloy. Pagkatapos ay gamitin ang tunay na hardware para sa mas makitid na hanay ng mga isyu na tanging mga aparato ang makapagpapakita. Mas mabilis, mas mura, at karaniwang mas disiplinado ang paraang ito kaysa umasa sa hardware mula sa simula.