Meny

Hvordan teste salgssted (POS) -system - Restaurant POS-testeksempel

how test point sale system restaurant pos testing example

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er salgssted (POS)?

POS alias Point of Sale er et sted der transaksjoner finner sted. Du kan se POS-systemer i detaljhandel, restauranter, sykehus og nesten overalt i disse dager hvor betaling er involvert.

De fleste av dere kan godt forstå hva en strekkodeleser er eller en trådløs betalingsenhet er (de mest brukte enhetene for betalingstransaksjoner), men POS involverer i virkeligheten mange komponenter, og hver av komponentene må integreres godt for det å kjøre vellykket.

I dagens artikkel skal jeg skrive om hva som gjør POS-testing forskjellig fra andre. Jeg har også tatt med testtips gjennom artikkelen for å gjøre dette nyttig for testmiljøet vårt.

  • Eksempel av Restaurant POS-systemtesting inkludert også

Testing av POS-system

La oss se på:

  • Hva gjør POS-applikasjonstesting annerledes
  • EPOS (Electronic Point of Sale) Architecture
  • EPOS fysiske komponenter
  • Nivåer / funksjoner til POS
  • Eksempel av Restaurant POS-systemtesting inkludert

Anbefalt lesing=> Hvordan teste en e-handelsapplikasjon

Hva du vil lære:

Hva gjør POS-tester annerledes:

POS System Testing ser kompleks ut, men det er ikke så vanskelig for de som forstår konseptet godt. Det er interessant fordi du får en følelse av å sitte i en butikk og gjennomføring av testsakene dine siden POS krever oppsett som du ser i alle butikker.

Dette gjør det annerledes sammenlignet med å sitte i båsen din og kjøre noen sjekker i en webapp. Organisasjoner som arbeider med POS-systemtesting har separate laboratorier.

beste webhotell selskaper i India

Hva er utfordringene i POS-testing?

  • Flere konfigurasjoner i henhold til butikkravet - jeg vil forklare med aenkelt eksempel, sier en butikkjede bare ønsker å kjøre et kampanjetilbud i en bestemt by. I slike tilfeller er det nødvendig med spesielle konfigurasjoner for POS-systemer som kjører i byen.
  • POS krever et riktig oppsett med alle enhetene, og også flere typer maskinvareenheter og versjoner av programvaren.
  • Flere enheter krever kompatibilitetstesting og også en grundig integrasjonstesting
  • PCI-kompatibel, fordi POS-test omhandler sluttbrukerens kortdetaljer.

POS-arkitektur:

POS Arkitektur

Hver av terminalene i en butikk er koblet til en filserver. Innstillingene eller hovedkonfigurasjonene blir gjort på serveren og skyves deretter til hver av terminalene i butikken. XML- eller batchjobber brukes til å gjøre slike oppdateringer.

For store butikker eller butikkjeder gjøres ingen av endringene lokalt. Siden POS-systemer godtar kortbetaling, er de integrert med tredjepartsleverandører som hovedsakelig utfører kredittkortbehandling, så når en kredittkorttransaksjon finner sted, sendes data til tredjepart eller banker for autorisasjon.

(Klikk på bildet for forstørret visning)

POS-arkitektur 1

Bilde Kilde .

POS fysiske komponenter og hvordan du tester disse:

# 1) Terminal - Terminal er hovedskjermen som brukes til å legge inn detaljene i transaksjonen. Dette er for det meste berøringsskjermenheter. Alle konfigurasjonene, det være seg relatert til produktliste, priser, kampanjetilbud, betalingsmåter, blir presset til terminalen. Dette er den viktigste enheten som brukes på ethvert POS.

  • Terminal Testing krever validering for å sikre at enhetene er koblet til nettverket og at det nyeste operativsystemet kjører på det for å støtte POS-appen.

# 2) Skjermstang - Display Pole er enheten som viser vareprisen når produktet er skannet ved hjelp av strekkodeleseren.

  • Kontroller at skjermstangen viser samme pris som sett på POS-terminalen

# 3) Strekkodeleser - Strekkodeleser brukes til å skanne produktene. Etter at skanningen er fullført, kontrolleres det i backend for å verifisere om varen finnes i lagerlisten og også hente varepris. Når varen blir solgt, blir varelageret oppdatert for å redusere det tilgjengelige antall enheter.

  • For testformål kan validering gjøres ved å skanne et produkt som mangler i inventarlisten
  • Valider ved å skanne produkter som er tilgjengelige i beholdningslisten, men uten prismerket
  • Valider ved å skanne produkter som er tilgjengelige i inventarlisten med riktig merking til et prisnivå.

# 4) Kassaapparat - Kasseapparat brukes til å lagre kontanter. For enhver kontanttransaksjon åpnes kasseapparatet umiddelbart for kasserere for å akseptere kontanter fra kunden og også returnere balansen hvis det er noen.

  • Kontantregistertesting kan gjøres ved å velge betalingsmodus som Kontanter, og foreta kontanttransaksjoner med refusjonsbeløp.

# 5) Håndholdt enhet - Håndholdte enheter er trådløse enheter som brukes til å godta kredittkortbetalinger. Disse gjør det enkelt å få brukerautentisering ved å bære enheten til sluttbrukeren direkte, der brukerne kan angi kortnål.

  • Testing kan gjøres ved å opprette en transaksjon ved å velge betalingsmåte som kort.
  • Bekreftelse for manuell oppføring av beløp bør gjøres.

# 6) Skriver - Skrivere er koblet til hver av terminalene og kalles som registerskrivere, disse brukes til å generere kvitteringen etter hver transaksjon.

  • Testere kan bekrefte utskrift av kvittering, se etter justering, tekstoverskriving, tekststørrelse, skrifttyper etc.
  • Feilhåndtering kan bekreftes, si hva som vil skje hvis utskriften blir gitt når skriveren ikke er i klar tilstand eller skriveren er tom for papir.
  • Bekreft resultatet når skriveren går frakoblet eller mister tilkoblingen midt i transaksjonen.

# 7) Magnetisk sveipleser - MSR brukes til å sveipe kort som brukes til betaling, som kan være debet-, kreditt- eller gavekort. Dette brukes hovedsakelig i butikker eller restauranter, men med skiftende tider, der en bruker må oppgi PIN-koden for betaling, vil du se mange steder at en trådløs enhet brukes til å godta kortbetalinger.

  • Når det gjelder gavekort, brukes MSR til saldokontroll, utløpsdato og for betaling. Trykte kvitteringer blir gitt til gjestene for autorisasjon. Testere bør validere disse tilfellene.

Les også=> 7 typer programvarefeil som alle testere burde vite

Nivåer / funksjoner til POS:

Det er i utgangspunktet tre nivåer eller funksjoner involvert i POS.

Nivåfunksjoner til POS

Nivå 1) Søknadsnivå / Front Office-funksjoner:

1) Salgstransaksjon - Hovedformålet med ethvert POS-system er å legge til rette for transaksjoner -

  • Validering av en vellykket salgstransaksjon som inkluderer skanning av varer ved hjelp av enten en strekkodeenhet eller manuell oppføring ved hjelp av tastaturet, for å sikre at det totale betalte beløpet blir beregnet og vises på skjermen, og det skal ende med en vellykket utskrift av betaling og kvittering.
  • Validering av riktig avgiftsberegning

2) Betaling - Betaling er nok et viktig område for testere. Dette skyldes det store utvalget av betalingsmåter som POS godtar. En POS tillater betaling via kort, kontanter, gavekort. De godtar også visse kupongkoder, rabattkuponger.

  • Validering av kontanter - Kontantvalidering er den enkleste å teste. Systemet beregner gjenværende saldo og gjør det enkelt for kassereren å tilbakebetale beløpet til kunden. Ofte foretrekker brukerne å foreta delbetalinger - noen ved å bruke gavekort (GC) og gjenværende med kontanter. Testing bør gjøres for å validere hvis systemet godtar og tillater delbetalinger.
  • Validering av kort - Betaling via kort vil alltid kreve tredjepartsautorisasjon. Kortbetaling starter ved å sveipe kortet - gjennom MSR eller en håndholdt enhet og deretter ta kundens autorisasjon for det angitte beløpet. Det samme beløpet blir deretter autorisert av tredjepartsbanker.
  • Validering av gavekort - Testere kan validere utløpsdatoen, et beløp på kortet før innløsning kan valideres ved å sveipe kortet på MSR, sveipe det begge veier for å se systematferd, validere i den delvise betalingstransaksjonen, validere ved å overbetale med kortet.
  • Rabatter / kuponger / kampanjetilbud - Dette er et vanskelig testområde fordi systemene er designet for kun å akseptere en kupongkode og ikke alle typer rabatter, og validering bør derfor bestå av alle typer kombinasjoner. Testing kan gjøres ved å bruke en kode som fungerer på det totale beløpet eller bruke en rabattkupong som gjelder for visse varer. Igjen, kampanjetilbud er kortvarige og kan ikke brukes overalt, og derfor krever testing av rabatt og kuponger litt forsiktighet. Valider også rekkefølgen der rabatter blir brukt. Noen ganger fungerer ikke butikkrabatter over produsentens kuponger, og noen ganger gjør de det. Så vær ekstra forsiktig når du tester dette.

Nivå # 2) Funksjoner på baksiden av huset

1) Slutten av dagen - End of Day er den viktigste aktiviteten som gjøres i backend. I løpet av EOD gjøres flere avstemminger og backend-systemer oppdateres.

er nettverksnøkkelen wifi-passordet

Flere sammendragsrapporter, inkludert den daglige salgsavstemmingen, blir generert og sendt til interessenter fordi dette gir en indikasjon på hvordan dagen var i forhold til salg. Det sendes også et sammendrag til bankene for alle kredittkorttransaksjoner som er utført i løpet av dagen. Beholdningssystemet blir oppdatert for å gjenspeile riktig lagerbalanse.

Dette utgjør et av de viktigste testområdene. Viktige scenarier som kan inkluderes som en del av EOD-testing kan være:

  • Kontroller at kjøringen av EOD-prosessen er vellykket. Dette vil ha flere forsettlige feil for å sikre at operasjonsdagen er stengt eller ikke. Si at i en restaurant, lederne vil ikke være i stand til å kjøre EOD-prosessen hvis alle sjekker ikke er stengt hvis alle ansatte ikke er utestengt fra systemet. Testing bør omfatte å kjøre denne prosessen, inkludert alle kontroller med positive og negative scenarier. Vanligvis er dette en automatisert prosess som er planlagt å kjøre med et bestemt tidsintervall i ekte butikker. For testformål bør denne prosessen testes manuelt.
  • Bekreft at avstemmingsrapporter genereres og valider innholdet i rapporten for å sikre at data i rapporten samsvarer med dataene fra den aktuelle butikken. For slike typer tester kan testere manuelt opprette noen transaksjoner og holde notater om de oppgitte dataene, og generere avstemmingsrapport på slutten av dagen og matche dataene de skrev inn. Avstemmingsrapport vil være mer som en balanse med debet- og kredittopplysningene.

2) Arbeidstidsplanlegging - En annen viktig BOH-aktivitet innebærer planleggingsfunksjonen som hovedsakelig omhandler å lage en arbeidsplan for ansatte. Ansatte bør klokke inn i systemet i henhold til deres tidsplan.

Planlegging kan gjøres manuelt eller på en automatisk måte ved å bruke data fra tidligere salgsmønstre og prosjektarbeidskrav. Planleggingen er en backend-aktivitet, men valideringen skjer i frontenden når den ansatte prøver å klokke inn.

gratis mp3 sanger nedlasting app for android
  • Validering bør omfatte bekreftelse av en ikke-planlagt klokke
  • Planlagt sen klokke inn og ut
  • Planlagt tidlig klokke inn og ut

3) Lagerstyring - Et annet viktig område er lagerstyringen. Butikksjefer krever hovedsakelig at slike systemer sporer produkter gjennom hvert trinn i varesyklusen og også har en ide før en vare faller under lagerbeholdningen.

Derfor er beholdningssystemer designet slik at ledere kan bestille riktig produkt til rett tid, i riktig mengde fra riktig leverandør og til riktig pris.

Testvalidering bør inneholde:

  • Validering av antall som skal kjøpes
  • Varsler hvis aksjenivået går under pari
  • Bestilling
  • Validering av riktig vareliste med riktig pris vises på POS for valg
  • Vare- og prisforening, validering på masternivå

Nivå # 3) Funksjoner på bedriftsnivå

Funksjoner på bedriftsnivå krever ikke at du sitter foran POS-systemet for å gjøre det, men de gjøres ved hjelp av hvilken som helst bærbar PC / stasjonær PC med appen eller programvaren installert, men de er på en eller annen måte integrert i POS-systemene. Hvis bedriftsfunksjoner gjøres ved hjelp av en webapplikasjon, vil det være en mekanisme som vil skyve endringene eller innstillingene til POS.

1) HR og lønn - HR- og lønnssystem tar for seg ansattes rekruttering, opprettholdelse av lønn / lønn for arbeidstakere, arbeidslover, skatteopplysninger, tilgjengelighet for ansatte og permisjon.

For det meste skjer lønnsvedlikeholdet med en tredjepart som ADP osv. Derfor må integrasjonen testes godt. HR-aktivitetene opprettholdes stort sett internt. Lønn blir et eget stort område for testing, da det krever alle slags beregninger før en ansattes lønnsbeløp blir avsluttet. Det danner et enormt omfang for testing.

  • Validering kan gjøres for HR-aktiviteter som å rekruttere ansatte og deretter sikre at ansatte importeres til POS-systemer
  • Lønns- / lønnsberegning i henhold til arbeidslover
  • Ansattes muligheter til å legge inn detaljer

2) Økonomi og regnskap - Finans- og regnskapssystem er det som krever rapportering. P & L-uttalelser, planlagte budsjetter, avvik, daglig butikkutsalg osv. Alle disse detaljene kreves av regnskapsteamet for å sikre om POS-butikken er i rute eller ikke.

Mange beslutninger tas basert på analysen av denne rapporten. Si at hvis teamet bestemmer seg for å åpne en ny butikk, basert på historiske data og analyser, godkjenner regnskapsteamet budsjettet og området der butikken kan åpnes. Slike detaljer hjelper dem også med å finne områdene for forbedring.

  • Valider generering av riktige rapporter
  • Bekreft analyselogikken
  • Validering av resultatregnskap og balanse

3) Leverandørledelse - For levering av varer vil enhver detaljhandel kreve leverandører, som nå vurderer riktig leverandør som gir rimelige priser og overvåker ytelsen, blir alt tatt hånd om av leverandørstyringssystemet.

Fra testperspektiv kan viktige valideringer nedenfor gjøres:

  • Validerer innføring og vedlikehold av leverandørdetaljer i systemet
  • Valider leverandørpriser
  • Valider leverandørens ytelse ved å spore levering i tide, kvaliteten på de leverte produktene osv.

4) DW og BI - Datavarehus gjør det mulig for enhver bransje å lagre og beholde detaljer om transaksjonen i mange år, som kan brukes til å kjenne trender, formulere kjøpemønstre osv. Business Intelligence-verktøy brukes til å hente ut denne enorme mengden data fra forskjellige systemer og gi sluttbrukeren en mulighet for analyse.

DW-systemer blir oppdatert fra dataene som kommer fra POS-systemene. Derfor, fra testbehov, er dette igjen viktig for testing. Mange organisasjoner bruker BI-verktøy eller noen utvikler intern analyse. Men i begge tilfeller er testing påkrevd.

DW- og BI-systemer hjelper folk på bedriftsnivå ved å forenkle generering av rapporter og tilpasse rapporter etter deres behov, det hjelper også til bedre sporing av ytelse.

  • Validering på POS-nivå kan gjøres for transaksjonsdata, men DW krever validering av historiske data
  • Valider brukerens rapportgenereringsevne og tilpasning ved hjelp av BI-verktøy.

Konklusjon:

Jeg håper denne artikkelen forklarte POS-testing i detalj. Jeg har en annen detaljert artikkel om hvordan POS-systemtesting kan gjøres for restaurantbransjen.

Restaurant pos-systemer Testing Eksempel:

=> Vennligst les Restaurant POS-systemer Testing artikkel her å forstå mer om POS med et eksempel.

Anbefalt lesing

^