De beste verktøyene for testing av strekkodeskannere for utviklere

Det som gjør et testverktøy genuint nyttig

Et godt verktøy beviser ikke bare at lykkelig vei virker én gang. Det hjelper deg å bevege deg raskt når noe feiler. For testing av strekkodeskannere betyr det vanligvis fire ting:

• raskt oppsett
• gjentakbare inndata
• innsyn i hva appen faktisk mottok
• nok kontroll til å gjenskape kanttilfeller for tid og suffiks

Jeg vurderer vanligvis verktøy med ett spørsmål: kortet dette ned tiden mellom «det så galt ut» og «jeg skjønner hvorfor det brøt»? Er svaret nei, legger verktøyet trolig til seremoni i stedet for verdi.

1. En strekkodeskanneremulator hører hjemme i standardverktøykassen

I daglig utvikling er en strekkodeemulator det mest praktiske startpunktet. Den lar deg simulere strekkodeskanneratferd rett fra arbeidsstasjonen, noe som passer når du bygger skjemaflyt, tester gjenoppretting av fokus, eller feilsøker hvorfor en POS-skjerm oppfører seg annerledes etter en skanning enn etter manuell innskriving.

Derfor er et verktøy som Barcode Scanner Emulator nyttig: det kortet ned tilbakemeldingssløyfen. Du kan endre strekkodeverdien, kjøre skanningen på nytt, prøve et annet suffiks og sammenligne resultater med en gang. For det meste av feilsøking i grensesnitt og arbeidsflyt er det mer verdifullt enn å vente på tilgang til en fysisk skanner.

2. Ekte maskinvareskannere betyr fortsatt noe

En emulator erstatter ikke all maskinvaretesting. Du vil fortsatt ha minst én ekte skanner i løkken før lansering, særlig hvis du støtter flere operativsystemer eller låste butikkterminaler.

Ekte maskinvare er viktig for å validere:

• utløseratferd på skanneren
• USB-tilkobling og særheter i drivere
• terminalbegrensninger
• forskjeller i maskinvarekonfigurasjon
• den ekte følelsen for operatøren

Den praktiske tilnærmingen er enkel: bruk emulatoren til daglig arbeid og den fysiske skanneren til tillitskontroller. Snur du rekkefølgen, kaster du bort maskinvaretid på feil som kunne vært funnet mye tidligere.

3. Stabile testdatafiksturer undervurderes

Strekkodearbeidsflyter er bare så gode som dataene bak dem. En produktkode som er knyttet til lager, kampanjer, pakkelogikk eller lokasjonsregler, er mye nyttigere enn et tilfeldig tall skrevet inn i et felt.

Hold et dokumentert sett med teststrekkoder for:

• et gyldig produkt
• en ukjent strekkode
• en strekkode med ledende nuller
• en begrenset vare eller en vare med alderskontroll
• et produkt med rabatt eller kampanje

Dette er særlig viktig i POS-testing. Endrer testdataene seg hver dag, ender du med å feilsøke miljøet i stedet for programvaren.

4. Nettverks- og API-inspeksjonsverktøy er også en del av strekkodetesting

Et overraskende antall skannerelaterte feil skjer etter at verdien har kommet inn i feltet. Strekkoden lander riktig, men oppslagsforespørselen er feilformet, trimmet feil, hurtigbufret dårlig eller avvist av tjeneren.

Derfor er logger, nettverksinspektører og API-verktøy fortsatt en del av den beste stabelen for testing av strekkodeskannere. Gjør en skanning i et POS-søkefelt ingenting, vil jeg vite om strekkoden ble normalisert riktig, om Enter ble utløst to ganger, og om tjeneren returnerte det forventede resultatet. Et skannerverktøy alene kan ikke svare på de spørsmålene.

5. POS-sandkasser og stagingmiljøer lukker arbeidsflytgapet

I POS-testing og kasseflyt betyr staging noe fordi skanning aldri bare handler om tekstinndata. Den berører priser, avgifter, tillatelser, lager, kundetildeling og kvitteringslogikk.

Her blir et staging- eller sandkassemiljø nødvendig. En simulert skanning kan virke perfekt på en demoside for en komponent og likevel feile når kampanjer, lagerregler og kasserertillatelser kommer inn. Det er ikke en grunn til å hoppe over emulatoren. Det er en grunn til å pare den med bedre validering av arbeidsflyten.

En praktisk verktøystabel som virker for de fleste team

Trenger du et lett, men pålitelig oppsett, er dette en god standard:

1. strekkodeemulator til daglig utvikling og QA-omkjøringer
2. én ekte skanner til lanseringsvalidering
3. stabile strekkodefiksturer knyttet til kjente produkter eller entiteter
4. forespørsels- og applikasjonslogger til feilsøking
5. et staging- eller POS-sandkassemiljø til fulle arbeidsflytkontroller

De raskeste teamene bruker ikke nødvendigvis flest verktøy. De bruker det rette lille settet og sørger for at hvert verktøy dekker en annen type feil.

En liten bestemt regel som sparer tid

Hvis jeg måtte fjerne én feil fra de fleste team, ville det vært denne: ikke bruk ekte maskinvare til spørsmål som tydelig handler om programvarearbeidsflyt. Er problemet fokus, Enter-håndtering, søketid eller valideringsrekkefølge, start med emulering og logger. Ta inn maskinvare igjen når du har snevret inn problemet.

Den rekkefølgen holder feilsøkingssløyfen sunn. Den hindrer også at selve skanneren blir unnskyldningen for at en feil fortsatt er vag etter en halv dag med undersøkelse.

Der dette utgjør en ekte forskjell

De raskeste teamene støtter seg ikke på ett verktøy.

De kombinerer noen enkle som lar dem bevege seg raskt når noe går i stykker.

Hjelper oppsettet ditt deg med å kjøre den samme skanningen på nytt, se hva som skjedde og justere raskt, ligger du allerede foran.