9 na minutong pagbasa
Ang pinakamahusay na setup ng pagsubok ng pantukoy ng barcode ay hindi ang may pinakamaraming hardware sa mesa. Ito ang tumutulong sa iyong mabilis na ulitin ang mga bug na hinihimok ng scanner, malinaw na suriin ang mga pagkabigo, at ulitin ang parehong daloy nang walang hadlang. Para sa karamihan ng mga koponan, nangangahulugan iyon ng pagsasama ng ilang praktikal na kasangkapan sa halip na umasa sa iisang aparato o kapaligiran.
Hindi lang pinatutunayan ng mabuting kasangkapan na minsang gumagana ang masayang landas. Tinutulungan ka nitong kumilos nang mabilis kapag may nabigo. Sa pagsubok ng pantukoy ng barcode, karaniwan itong apat na bagay:
Karaniwan kong hinuhusgahan ang mga kasangkapan sa isang tanong: pinaiikli ba nito ang oras sa pagitan ng „mukhang mali iyon“ at „naiintindihan ko kung bakit nasira“? Kung hindi, malamang nagdadagdag ang kasangkapan ng seremonya sa halip na halaga.
Sa araw-araw na paggawa, ang emulator ng barcode ang pinakapraktikal na panimula. Hinahayaan ka nitong gayahin ang ugali ng pantukoy ng barcode mula mismo sa workstation mo, na angkop kapag gumagawa ng mga daloy ng form, sumusubok ng pagbabalik ng focus, o nagde-debug kung bakit iba ang ugali ng screen ng POS pagkatapos ng pagbasa kaysa pagkatapos ng manu-manong pagpasok.
Ito rin ang dahilan kung bakit kapaki-pakinabang ang kasangkapan gaya ng Barcode Scanner Emulator: pinaiikli nito ang feedback loop. Maaari mong baguhin ang halaga ng barcode, ulitin ang pagbasa, sumubok ng ibang hulapi, at ihambing agad ang mga resulta. Para sa karamihan ng pag-debug ng frontend at daloy, mas mahalaga ito kaysa maghintay ng access sa pisikal na scanner.
Hindi kapalit ng lahat ng pagsubok ng hardware ang emulator. Gusto mo pa ring kahit isang tunay na scanner sa loop bago ang release, lalo na kung sumusuporta ka ng maraming operating system o ng mga naka-lock na terminal ng retail.
Mahalaga ang tunay na hardware para mapatunayan ang:
Simple ang praktikal na paraan: gamitin ang emulator para sa araw-araw na gawain at ang pisikal na scanner para sa mga pagsusuri ng kumpiyansa. Kung babaligtarin mo iyon, masasayang ang oras ng hardware sa mga bug na maaaring natuklasan nang mas maaga.
Kasinghusay lamang ng datos sa likod nito ang mga daloy ng barcode. Mas kapaki-pakinabang ang code ng produkto na nakaugnay sa imbentaryo, promosyon, lohika ng bundle, o mga tuntunin ng lokasyon kaysa sa random na numerong tina-type sa field.
Magtabi ng dokumentadong hanay ng mga test barcode para sa:
Lalong mahalaga ito sa pagsubok ng POS. Kung araw-araw nagbabago ang test data, nauuwi kang nagde-debug ng kapaligiran sa halip na ng software.
Nakakagulat na maraming pagkabigo na may kaugnayan sa pagbasa ang nangyayari pagkatapos pumasok ang halaga sa field. Tama ang landing ng barcode, ngunit mali ang anyo ng lookup request, mali ang pagputol, masama ang cache, o tinanggihan ng backend.
Kaya bahagi pa rin ng pinakamahusay na stack ng pagsubok ng pantukoy ng barcode ang mga log, inspector ng network, at mga kasangkapan ng API. Kung walang nangyayari sa pagbasa sa field ng paghahanap ng POS, gusto kong malaman kung tama ang na-normalize na barcode, kung dalawang beses nag-fire ang Enter, at kung ibinalik ng server ang inaasahang resulta. Hindi masagot ng kasangkapan ng scanner lamang ang mga tanong na iyon.
Sa pagsubok ng POS at mga daloy ng checkout, mahalaga ang staging dahil hindi kailanman teksto lamang ang pagbasa. Hinahawakan nito ang presyo, buwis, pahintulot, imbentaryo, pagtatalaga ng customer, at lohika ng resibo.
Dito nagiging mahalaga ang staging o sandbox. Maaaring perpekto ang gumagana ng ginayang pagbasa sa demo page ng isang component ngunit mabigo kapag pumasok ang mga promosyon, tuntunin ng stock, at pahintulot ng kahera. Hindi iyon dahilan para laktawan ang emulator. Dahilan iyon para ipares ito sa mas mahusay na pagpapatunay ng daloy.
Kung kailangan mo ng magaan ngunit maaasahang setup, magandang default ito:
Hindi kinakailangang pinakamaraming kasangkapan ang ginagamit ng pinakamabilis na mga koponan. Ginagamit nila ang tamang maliit na hanay at tinitiyak na iba-ibang uri ng pagkabigo ang sinasaklaw ng bawat isa.
Kung may isang pagkakamali akong aalisin sa karamihan ng mga koponan, ito iyon: huwag gumamit ng tunay na hardware para sa mga tanong na malinaw na tungkol sa ugali ng daloy ng software. Kung ang isyu ay focus, paghawak ng Enter, timing ng paghahanap, o pagkakasunod ng validation, magsimula sa emulation at mga log. Ibalik ang hardware kapag napaliit mo na ang problema.
Pinapanatili ng pagkakasunod na iyon na matino ang loop ng pag-debug. Pinipigilan din nito na ang scanner mismo ang maging dahilan kung bakit malabo pa rin ang bug pagkatapos ng kalahating araw na pagsisiyasat.
Hindi umaasa sa iisang kasangkapan ang pinakamabilis na mga koponan.
Pinagsasama nila ang ilang simple na nagpapahintulot sa kanilang kumilos nang mabilis kapag may nasira.
Kung tinutulungan ka ng setup na ulitin ang parehong pagbasa, suriin ang nangyari, at mabilis na mag-adjust, nauuna ka na.
Kapaki-pakinabang na susunod na hakbang
Kung nais mong subukan ang mga daloy na ito sa praktika, magsimula sa kasangkapang Barcode Scanner Emulator at pagkatapos ay bumalik sa iba pang bahagi ng blog para sa higit pang mga padron ng pagsubok.
8 minutong pagbasa
Praktikal na hakbang-hakbang na gabay sa paggamit ng emulator ng pantukoy ng barcode para sa pagsubok ng scanner, mga daloy ng QA, at pagsubok ng POS nang walang tunay na hardware.
9 na minutong pagbasa
Praktikal na gabay sa pagsubok ng POS nang walang tunay na hardware, kasama ang pagsubok ng pantukoy ng barcode, mga daloy na may yugto, at ang mga hangganan ng pagpapatunay na walang hardware.
9 na minutong pagbasa
Kumpletong gabay sa mga emulator ng barcode, kasama kung paano gumagana ang mga ito, sino ang gumagamit, saan sila nababagay sa pagsubok ng pantukoy ng barcode, at saan hindi.
