Bästa verktygen för test av streckkodsläsare för utvecklare

Vad som gör ett testverktyg genuint användbart

Ett bra verktyg bevisar inte bara att den lyckade vägen fungerar en gång. Det hjälper dig att röra dig snabbt när något fallerar. För test av streckkodsläsare betyder det vanligtvis fyra saker:

• snabb uppsättning
• upprepningsbar inmatning
• insyn i vad appen faktiskt tog emot
• tillräcklig kontroll för att återskapa kantfall kring timing och suffix

Jag brukar bedöma verktyg med en fråga: förkortar det här tiden mellan ”det såg fel ut” och ”jag förstår varför det gick sönder”? Om svaret är nej lägger verktyget troligen till ceremoni i stället för värde.

1. En emulator för streckkodsläsare hör hemma i standardverktygslådan

För den dagliga utvecklingen är en streckkodsemulator den mest praktiska startpunkten. Den låter dig simulera beteendet hos en streckkodsläsare direkt från arbetsstationen, vilket är idealiskt när du bygger formulärflöden, testar återställning av fokus eller felsöker varför en POS-skärm beter sig annorlunda efter en skanning än efter manuell inmatning.

Därför är ett verktyg som Barcode Scanner Emulator användbart: det förkortar återkopplingsslingan. Du kan ändra streckkodsvärdet, köra om skanningen, prova ett annat suffix och jämföra resultaten direkt. För det mesta av felsökningen i frontend och flöden är det mer värdefullt än att vänta på tillgång till en fysisk skanner.

2. Riktiga hårdvaruskannrar spelar fortfarande roll

En emulator ersätter inte all hårdvarutestning. Du vill fortfarande ha minst en riktig skanner i slingan före release, särskilt om du stöder flera operativsystem eller låsta butiksterminaler.

Riktig hårdvara är viktig för att validera:

• skannerns avtryckarbeteende
• USB-anslutning och egenheter i drivrutiner
• terminalbegränsningar
• skillnader i hårdvarukonfiguration
• hur det känns för en riktig operatör

Det praktiska tillvägagångssättet är enkelt: använd emulatorn för det dagliga arbetet och den fysiska skannern för förtroendekontroller. Om du vänder på det slösar du hårdvarutid på fel som kunde ha hittats mycket tidigare.

3. Stabila testdata är underskattade

Streckkodsflöden är bara så bra som datat bakom dem. En produktkod som mappar till lager, kampanjer, paketlogik eller platsregler är mycket mer användbar än ett slumptal som skrivs in i ett fält.

Håll en dokumenterad uppsättning teststreckkoder för:

• en giltig produkt
• en okänd streckkod
• en streckkod med inledande nollor
• en begränsad vara eller en vara med åldersgräns
• en produkt med rabatt eller kampanj

Det är särskilt viktigt för POS-test. Om testdatat ändras varje dag slutar du med att felsöka miljön i stället för programvaran.

4. Verktyg för nätverk och API-inspektion är också en del av streckkodstest

Ett förvånande antal skanningsrelaterade fel inträffar efter att värdet har hamnat i fältet. Streckkoden landar korrekt, men uppslaget är felaktigt utformat, felaktigt trimmat, dåligt cacheat eller avvisas av backend.

Därför är loggar, nätverksinspektorer och API-verktyg fortfarande en del av den bästa uppsättningen för test av streckkodsläsare. Om en skanning i ett POS-sökfält inte gör något vill jag veta om streckkoden normaliserades korrekt, om ENTER utlöstes två gånger och om servern returnerade det förväntade resultatet. Ett skannerverktyg ensamt kan inte svara på de frågorna.

5. POS-sandlådor och förproduktionsmiljöer sluter flödesgapet

För POS-test och kassaflöden spelar förproduktion roll eftersom skanning aldrig bara handlar om textinmatning. Den rör priser, skatter, behörigheter, lager, kundkoppling och kvittologik.

Här blir en förproduktions- eller sandlådemiljö nödvändig. En simulerad skanning kan fungera perfekt på en demosida för en komponent och ändå fallera när kampanjer, lagerregler och kassörsbehörigheter kommer in i bilden. Det är inte ett skäl att hoppa över emulatorn. Det är ett skäl att para ihop den med bättre flödesvalidering.

En praktisk verktygsuppsättning som fungerar för de flesta team

Om du behöver en lätt men tillförlitlig uppsättning är det här en bra standard:

1. streckkodsemulator för daglig utveckling och QA-omkörningar
2. en riktig skanner för validering inför release
3. stabila streckkodsfixturer kopplade till kända produkter eller entiteter
4. förfrågnings- och applikationsloggar för felsökning
5. en förproduktions- eller POS-sandlådemiljö för kontroller av hela flödet

De snabbaste teamen använder inte nödvändigtvis flest verktyg. De använder rätt liten uppsättning och ser till att varje verktyg täcker en annan sorts fel.

En liten bestämd regel som sparar tid

Om jag var tvungen att ta bort ett misstag hos de flesta team skulle det vara det här: använd inte riktig hårdvara för frågor som uppenbart handlar om programvarans flödesbeteende. Om problemet är fokus, ENTER-hantering, söktiming eller valideringsordning, börja med emulering och loggar. Ta in hårdvaran igen när du har ringat in problemet.

Den ordningen håller felsökningsslingan sund. Den hindrar också skannern själv från att bli ursäkten till att ett fel fortfarande är vagt efter en halv dags utredning.

Där det här gör en verklig skillnad

De snabbaste teamen förlitar sig inte på ett enda verktyg.

De kombinerar några enkla som låter dem röra sig snabbt när något går sönder.

Om din uppsättning hjälper dig att köra om samma skanning, granska vad som hände och justera snabbt ligger du redan före.