Najbolji alati za testiranje čitača crtičnog koda za razvijatelje

Što alat za testiranje čini doista korisnim

Dobar alat ne dokazuje samo da sretni put jednom radi. Pomaže vam brzo napredovati kad nešto zakaže. U testiranju čitača to obično znači četiri stvari:

• brzu postavu
• ponovljiv unos
• uvid u ono što je aplikacija stvarno primila
• dovoljno kontrole za ponavljanje rubnih slučajeva ritma i nastavka

Alate obično ocjenjujem jednim pitanjem: skraćuje li ovo vrijeme između „to je izgledalo krivo“ i „razumijem zašto se pokvarilo“? Ako je odgovor ne, alat vjerojatno dodaje ceremoniju umjesto vrijednosti.

1. Emulator čitača crtičnog koda pripada u zadani alatni kovčeg

Za svakodnevni razvoj emulator crtičnog koda najpraktičniji je početak. Omogućuje simulaciju ponašanja čitača izravno s radne stanice, što je idealno za izradu tijekova obrazaca, testiranje povratka fokusa ili otkrivanje zašto se POS zaslon nakon skeniranja ponaša drukčije nego nakon ručnog unosa.

Zato je alat poput Barcode Scanner Emulator koristan: skraćuje petlju povratne informacije. Možete promijeniti vrijednost, ponovno pokrenuti skeniranje, isprobati drugi nastavak i odmah usporediti rezultate. Za većinu otklanjanja pogrešaka sučelja i tijeka to je vrjednije od čekanja na fizički čitač.

2. Pravi hardverski čitači i dalje su važni

Emulator nije zamjena za svo hardversko testiranje. Prije izdanja i dalje želite barem jedan pravi čitač u petlji, posebno ako podržavate više operacijskih sustava ili zaključane maloprodajne terminale.

Pravi hardver važan je za provjeru:

• ponašanja okidača čitača
• USB veze i posebnosti upravljačkog programa
• ograničenja terminala
• razlika u hardverskoj konfiguraciji
• stvarnog osjećaja operatera

Praktičan pristup je jednostavan: emulator za svakodnevni rad, fizički čitač za provjere pouzdanosti. Ako taj redoslijed okrenete, trošite hardversko vrijeme na pogreške koje su se mogle naći mnogo ranije.

3. Stabilni testni podaci su podcijenjeni

Tijekovi crtičnog koda vrijede onoliko koliko vrijede podaci iza njih. Šifra proizvoda vezana uz zalihu, promocije, logiku paketa ili pravila lokacije mnogo je korisnija od slučajnog broja upisanog u polje.

Držite dokumentirani skup testnih crtičnih kodova za:

• valjan proizvod
• nepoznat crtični kod
• crtični kod s vodećim nulama
• ograničeni artikl ili artikl s dobnom granicom
• proizvod s popustom ili promocijom

To je posebno važno za POS testiranje. Ako se testni podaci mijenjaju svaki dan, na kraju otklanjate pogreške okruženja umjesto softvera.

4. Alati za pregled mreže i API-ja također su dio testiranja crtičnog koda

Iznenađujuće mnogo neuspjeha vezanih uz skeniranje događa se nakon što vrijednost uđe u polje. Crtični kod sleti ispravno, ali je zahtjev za pretragu loše oblikovan, krivo odrezan, loše predmemoriran ili ga pozadina odbije.

Zato su zapisi, mrežni inspektori i API alati i dalje dio najboljeg skupa za testiranje čitača. Ako skeniranje u POS polju za pretragu ne učini ništa, želim znati je li crtični kod ispravno normaliziran, je li se Enter okinuo dvaput i je li poslužitelj vratio očekivani rezultat. Sam alat za čitač na ta pitanja ne može odgovoriti.

5. POS pješčanici i staging okruženja zatvaraju jaz tijeka

Za POS testiranje i blagajničke tijekove staging je važan jer skeniranje nikad nije samo unos teksta. Dotice cijene, poreze, ovlasti, zalihu, dodjelu kupca i logiku računa.

Tu staging ili pješčanik postaje nužan. Simulirano skeniranje može savršeno raditi na demo stranici komponente, a ipak zakazati kad u igru uđu promocije, pravila zalihe i ovlasti blagajnika. To nije razlog da preskočite emulator. To je razlog da ga spojite s boljom provjerom tijeka.

Praktičan skup alata koji odgovara većini timova

Ako trebate laganu, ali pouzdanu postavu, ovo je dobar zadani izbor:

1. emulator crtičnog koda za svakodnevni razvoj i QA ponavljanja
2. jedan pravi čitač za provjeru izdanja
3. stabilni crtični kodovi vezani uz poznate proizvode ili entitete
4. zapisi zahtjeva i aplikacije za otklanjanje pogrešaka
5. staging ili POS pješčanik za pune provjere tijeka

Najbrži timovi ne koriste nužno najviše alata. Koriste pravi mali skup i paze da svaki pokriva drugu vrstu neuspjeha.

Malo odlučno pravilo koje štedi vrijeme

Kad bih većini timova morao izrezati jednu pogrešku, bila bi ova: ne koristite pravi hardver za pitanja koja su jasno o ponašanju softverskog tijeka. Ako je problem fokus, rukovanje Enter, ritam pretrage ili redoslijed provjere, počnite emulacijom i zapisima. Hardver vratite kad suzite problem.

Taj redoslijed drži petlju otklanjanja pogrešaka razumnom. Također sprječava da sam čitač postane isprika zašto je pogreška i nakon pola dana istrage i dalje nejasna.

Gdje to stvarno čini razliku

Najbrži timovi ne oslanjaju se na jedan alat.

Spajaju nekoliko jednostavnih koji im omogućuju brzo kretanje kad se nešto pokvari.

Ako vam postava pomaže ponoviti isto skeniranje, vidjeti što se dogodilo i brzo prilagoditi, već ste ispred.