Parhaat viivakoodinlukijan testaustyökalut kehittäjille

Mikä tekee testaustyökalusta aidosti hyödyllisen

Hyvä työkalu ei vain todista, että onnellinen polku toimii kerran. Se auttaa etenemään nopeasti, kun jokin epäonnistuu. Viivakoodinlukijan testauksessa se tarkoittaa yleensä neljää asiaa:

• nopea käyttöönotto
• toistettava syöte
• näkyvyys siihen, mitä sovellus oikeasti vastaanotti
• riittävä hallinta ajoituksen ja päätteen reunatapausten toistamiseen

Arvioin työkaluja yleensä yhdellä kysymyksellä: lyhentääkö tämä aikaa sen välillä, että „tuo näytti väärältä“ ja „ymmärrän miksi se hajosi“? Jos vastaus on ei, työkalu lisää todennäköisesti seremonioita arvon sijaan.

1. Viivakoodinlukijan emulaattori kuuluu oletustyökalupakkiin

Päivittäisessä kehityksessä viivakoodiemulaattori on käytännöllisin lähtökohta. Sen avulla simuloit viivakoodinlukijan toimintaa suoraan työasemaltasi, mikä sopii lomakevirtojen rakentamiseen, kohdistuksen palautumisen testaamiseen tai sen selvittämiseen, miksi POS-näyttö käyttäytyy skannauksen jälkeen eri tavalla kuin käsin syötön jälkeen.

Juuri siksi työkalu kuten Barcode Scanner Emulator on hyödyllinen: se lyhentää palautesilmukkaa. Voit vaihtaa viivakoodiarvon, ajaa skannauksen uudelleen, kokeilla toista päätettä ja verrata tuloksia heti. Useimpaan käyttöliittymän ja työnkulun virheenjäljitykseen se on arvokkaampaa kuin fyysisen lukijan odottaminen.

2. Oikeilla laitteistolukijoilla on yhä merkitystä

Emulaattori ei korvaa kaikkea laitteistotestausta. Ennen julkaisua ketjussa kannattaa yhä olla vähintään yksi oikea lukija, etenkin jos tuet useita käyttöjärjestelmiä tai lukittuja vähittäiskaupan päätteitä.

Oikea laitteisto on tärkeää, kun validoit:

• lukijan liipaisimen toimintaa
• USB-yhteyden ja ajurien omituisuuksia
• päätteen rajoituksia
• laitteiston kokoonpanoeroja
• oikean käyttäjän tuntumaa

Käytännön lähestymistapa on yksinkertainen: käytä emulaattoria päivittäiseen työhön ja fyysistä lukijaa varmistustarkistuksiin. Jos käännät järjestyksen, tuhlaat laitteistoaikaa virheisiin, jotka olisi voitu löytää paljon aiemmin.

3. Vakaat testidatan fixturet ovat aliarvostettuja

Viivakoodityönkulut ovat vain niin hyviä kuin niiden takana oleva data. Tuotekoodi, joka kytkeytyy varastoon, kampanjoihin, pakettien logiikkaan tai sijaintisääntöihin, on paljon hyödyllisempi kuin satunnainen numero kenttään kirjoitettuna.

Pidä dokumentoitu joukko testiviivakoodeja:

• kelvolliselle tuotteelle
• tuntemattomalle viivakoodille
• viivakoodille, jossa on etunollia
• rajoitetulle tai ikärajatulle tuotteelle
• tuotteelle, jolla on alennus tai kampanja

Tämä on erityisen tärkeää POS-testauksessa. Jos testidata muuttuu päivittäin, päädyt jäljittämään ympäristöä ohjelmiston sijaan.

4. Verkon ja API:n tarkastustyökalut kuuluvat myös viivakooditestaukseen

Yllättävän moni skannaukseen liittyvä vika tapahtuu sen jälkeen, kun arvo on päätynyt kenttään. Viivakoodi osuu oikein, mutta hakupyyntö on väärin muodostettu, väärin trimmattu, huonosti välimuistissa tai taustajärjestelmän hylkäämä.

Siksi lokit, verkkotarkastimet ja API-työkalut ovat yhä osa parasta viivakoodinlukijan testauspinoa. Jos skannaus POS-hakukentässä ei tee mitään, haluan tietää normalisoitiinko viivakoodi oikein, laukesiko Enter kahdesti ja palauttiko palvelin odotetun tuloksen. Pelkkä lukijatyökalu ei vastaa näihin kysymyksiin.

5. POS-hiekkalaatikot ja staging-ympäristöt sulkevat työnkulun aukon

POS-testauksessa ja kassatyönkuluissa staging merkitsee, koska skannaus ei ole koskaan pelkkää tekstisyötettä. Se koskettaa hinnoittelua, veroja, oikeuksia, varastoa, asiakkaan kytkemistä ja kuittilogiikkaa.

Tässä staging- tai hiekkalaatikkoympäristö muuttuu välttämättömäksi. Simuloitu skannaus voi toimia täydellisesti komponentin demosivulla ja silti epäonnistua, kun kampanjat, varastosäännöt ja kassanhoitajan oikeudet tulevat mukaan. Se ei ole syy ohittaa emulaattoria. Se on syy yhdistää se parempaan työnkulun validointiin.

Käytännön työkalupino, joka toimii useimmille tiimeille

Jos tarvitset kevyen mutta luotettavan asetelman, tämä on hyvä oletus:

1. viivakoodiemulaattori päivittäiseen kehitykseen ja QA-uusintoihin
2. yksi oikea lukija julkaisun validointiin
3. vakaat viivakoodifixturet, jotka on sidottu tunnettuihin tuotteisiin tai entiteetteihin
4. pyyntö- ja sovelluslokit virheenjäljitykseen
5. staging- tai POS-hiekkalaatikkoympäristö koko työnkulun tarkistuksiin

Nopeimmat tiimit eivät välttämättä käytä eniten työkaluja. Ne käyttävät oikeaa pientä joukkoa ja varmistavat, että kukin kattaa erilaisen vian.

Pieni jämäkkä sääntö, joka säästää aikaa

Jos minun pitäisi leikata yksi virhe pois useimmilta tiimeiltä, se olisi tämä: älä käytä oikeaa laitteistoa kysymyksiin, jotka koskevat selvästi ohjelmiston työnkulun toimintaa. Jos asia on kohdistus, Enterin käsittely, haun ajoitus tai tarkistuksen järjestys, aloita emuloinnista ja lokeista. Tuo laitteisto takaisin, kun olet rajannut ongelman.

Tämä järjestys pitää virheenjäljityssilmukan järkevänä. Se estää myös sen, että itse lukijasta tulee selitys sille, miksi vika on yhä epämääräinen puolen päivän tutkimisen jälkeen.

Missä tällä on oikea merkitys

Nopeimmat tiimit eivät nojaa yhteen työkaluun.

Ne yhdistävät muutaman yksinkertaisen, joiden avulla voi edetä nopeasti, kun jokin hajoaa.

Jos asetelmasi auttaa ajamaan saman skannauksen uudelleen, tutkimaan mitä tapahtui ja säätämään nopeasti, olet jo edellä.