Menu

Sådan testes salgsstedet (POS) - Restaurant POS-testeksempel

how test point sale system restaurant pos testing example

Prøv Vores Instrument Til At Fjerne Problemer

Hvad er salgssted (POS)?

POS alias Point of Sale er et sted, hvor transaktioner finder sted. Du kan se POS-systemer i detailbutikker, restauranter, hospitaler og næsten overalt i disse dage, hvor betalinger er involveret.

De fleste af jer kan meget godt forstå, hvad en stregkodelæser er eller en trådløs betalingsenhed er (de mest anvendte enheder til betalingstransaktioner), men POS involverer i virkeligheden mange komponenter, og hver af komponenterne skal integreres godt for det at køre med succes.

I dagens artikel skal jeg skrive om, hvad der gør POS-test forskellig fra andre. Jeg har også indarbejdet testtip gennem hele artiklen for at gøre dette nyttigt for vores testfællesskab.

  • Eksempel på Test af restaurantens POS-system inkluderet også

Test af POS-system

Lad os se på:

  • Hvad gør test af POS-applikation anderledes
  • EPOS (Electronic Point of Sale) -arkitektur
  • EPOS Fysiske komponenter
  • Niveauer / funktioner i POS
  • Eksempel på Test af restaurantens POS-system inkluderet

Anbefalet læsning=> Sådan tester du en e-handelsapplikation

Hvad du lærer:

Hvad gør POS-test anderledes:

POS-systemtest ser komplekst ud, men det er ikke så vanskeligt for dem, der forstår konceptet godt. Det er interessant, fordi du får en fornemmelse af at sidde i en butik og udførelse af dine testsager da POS kræver opsætning, som du ville se i alle butikker.

Dette gør det anderledes sammenlignet med at sidde i dit kabine og køre nogle kontroller i en webapp. Organisationer, der beskæftiger sig med POS-systemtest, opretholder separate laboratorier.

spørgsmål til ydeevne testinterview for erfarne

Hvad er udfordringerne i POS-test?

  • Flere konfigurationer i henhold til butikskravet - jeg forklarer med ensimpelt eksempel, siger en detailkæde kun ønsker at køre et kampagnetilbud i en bestemt by. I sådanne tilfælde kræves der specielle konfigurationer for POS-systemer, der kører i den by.
  • POS kræver en korrekt opsætning med alle enhederne og også flere typer hardwareenheder og versioner af softwaren.
  • Flere enheder kræver kompatibilitetstest og også en grundig integrationstest
  • PCI-kompatibel, fordi POS-test omhandler slutbrugerens kortoplysninger.

POS-arkitektur:

POS Arkitektur

Hver af terminalerne i en butik er forbundet til en filserver. Indstillingerne eller hovedkonfigurationerne bliver gjort på serveren og skubbes derefter til hver af terminalerne i butikken. XML'er eller batchjobs bruges til at udføre sådanne opdateringer.

For store detailbutikker eller forretningskæder foretages ingen af ​​ændringerne lokalt. Da POS-systemer accepterer kortbetaling, er de integreret med tredjepartsudbydere, der primært foretager kreditkortbehandling, så når en kreditkorttransaktion finder sted, sendes data til tredjepart eller banker til godkendelse.

(Klik på billedet for at se det større)

POS-arkitektur 1

Billede Kilde .

POS Fysiske komponenter og hvordan man tester disse:

# 1) Terminal - Terminal er hovedskærmen, der bruges til at indtaste detaljerne i transaktionen. Disse er for det meste berøringsfølsomme enheder. Alle konfigurationer, det være sig relateret til produktliste, priser, kampagnetilbud, betalingsformer, bliver skubbet til terminalen. Dette er den primære enhed, der bruges på ethvert POS.

  • Terminal Test kræver validering for at sikre, at enhederne er forbundet til netværket, og at det nyeste operativsystem kører på det for at understøtte POS-appen.

# 2) Vis stang - Display Pole er den enhed, der viser vareprisen, når produktet er scannet ved hjælp af stregkodescanneren.

  • Bekræft, at skærmstangen viser den samme pris som set på POS-terminalen

# 3) Stregkodelæser - Stregkodelæser bruges til at scanne produkterne. Når scanningen er afsluttet, foretages en kontrol i backend for at kontrollere, om varen findes i lagerlisten og også hente vareprisen. Når varen er solgt, opdateres beholdningen for at reducere det tilgængelige antal enheder.

  • Til testformål kan validering udføres ved at scanne et produkt, der mangler på lagerlisten
  • Bekræft ved at scanne produkter, der er tilgængelige på lagerlisten, men uden prismærkning
  • Valider ved at scanne produkter, der er tilgængelige på lagerlisten med korrekt mærkning til et prisniveau.

# 4) Kasseapparat - Kasseapparat bruges til opbevaring af kontanter. For enhver kontant transaktion åbner kasseapparatet straks for kasserer at acceptere kontanter fra kunden og også returnere restbeløbet, hvis der er noget.

  • Kontantregistreringstest kan udføres ved at vælge betalingstilstand som Kontant og foretage kontant transaktion med et refusionsbeløb.

# 5) Håndholdt enhed - Håndholdte enheder er trådløse enheder, der bruges til at acceptere kreditkortbetalinger. Disse gør det nemt at få brugergodkendelse ved at føre enheden direkte til slutbrugeren, hvor brugerne kan indtaste kortnål.

  • Test kan udføres ved at oprette en transaktion ved at vælge en betalingsform som kort.
  • Bekræftelse for den manuelle indtastning af beløbet skal foretages.

# 6) Printer - Printere er forbundet til hver af terminalerne og kaldes som registerprintere, disse bruges til at generere kvitteringen efter hver transaktion.

  • Testere kan kontrollere udskrivning af kvittering, kontrollere for justering, tekstoverskrivninger, tekststørrelse, skrifttyper osv.
  • Fejlhåndtering kan bekræftes, sig hvad der vil ske, hvis udskriften gives, når printeren ikke er klar, eller printeren er løbet tør for papir.
  • Bekræft resultatet, når printeren går offline eller mister forbindelsen midt i transaktionen.

# 7) Magnetisk strygelæser - MSR'er bruges til at skubbe kort, der bruges til betaling, som kan være debet-, kredit- eller gavekort. Dette bruges mest i butikker eller restauranter, men med skiftende tidspunkter, hvor en bruger skal indtaste pinkoden til betaling, ville du mange steder se, at en trådløs enhed bruges til at acceptere kortbetalinger.

  • I tilfælde af gavekort bruges MSR'er til saldokontrol, udløbsdato og til betaling. Udskrevne kvitteringer gives til gæsterne til godkendelse. Testere bør validere disse tilfælde.

Læs også=> 7 typer softwarefejl, som hver tester burde vide

youtube til mp3 online konverter anmeldelser

Niveauer / funktioner i POS:

Der er dybest set 3 niveauer eller funktioner involveret i POS.

Niveauer Funktioner af POS

Niveau # 1) Applikationsniveau / Front Office-funktioner:

1) Salgstransaktion - Hovedformålet med ethvert POS-system er at lette transaktioner -

  • Validering af en vellykket salgstransaktion, der inkluderer varescanning ved hjælp af enten en stregkodeenhed eller manuel indtastning ved hjælp af tastaturet, hvilket sikrer, at det samlede betalte beløb beregnes og vises på skærmen, og det skal ende med en vellykket udskrivning af betaling og kvittering.
  • Validering af den korrekte beregning af skattebeløb

2) Betaling - Betaling er endnu et vigtigt område for testere. Dette skyldes det store udvalg af betalingsformer, der accepteres af POS. En POS tillader betaling via kort, kontanter, gavekort. De accepterer også visse kuponkoder, rabatkuponer.

  • Validering af kontanter - Validering af kontanter er den enkleste at teste. Systemet beregner den resterende saldo og gør kasserers job let at tilbagebetale beløbet til kunden. Mange gange foretrækker brugerne muligvis at foretage delvise betalinger - nogle ved hjælp af gavekort (GC) og forbliver kontant. Test skal udføres for at validere, hvis systemet accepterer og tillader delbetalinger.
  • Validering af kort - Betaling via kort kræver altid tredjepartsautorisation. Kortbetaling starter ved at skubbe kortet - gennem MSR eller en håndholdt enhed og derefter tage kundens autorisation til det angivne beløb. Det samme beløb bliver derefter godkendt af tredjepartsbanker.
  • Validering af gavekort - Testere kan validere udløbsdatoen, et beløb på kortet inden indløsning kan valideres ved at skubbe kortet på MSR, stryge det begge veje for at se systemadfærd, validere i den delvise betalingstransaktion, validere ved for meget betaling ved hjælp af kortet.
  • Rabatter / kuponer / tilbud - Dette er et vanskeligt testområde, fordi systemerne kun er designet til at acceptere en kuponkode og ikke alle typer rabatter, og validering skal derfor bestå af alle typer kombinationer. Test kan udføres ved hjælp af en kode, der fungerer på det samlede beløb eller ved hjælp af en rabatkupon, der gælder for visse varer. Igen er kampagnetilbud kortvarige og gælder ikke overalt, hvorfor test af rabat og kuponer kræver lidt pleje. Valider også rækkefølgen, i hvilken rabatter anvendes. Nogle gange fungerer butiksrabatter ikke over producentens kuponer, og nogle gange gør de det. Så vær ekstra forsigtig, når du tester dette.

Niveau # 2) Bagsiden af ​​husets funktioner

1) Slut på dagen - Slutningen af ​​dagen er den vigtigste aktivitet, der udføres i backend. Under EOD foretages flere afstemninger, og backend-systemer opdateres.

Flere oversigtsrapporter, inklusive den daglige salgsafstemning, genereres og sendes til interessenter, fordi dette giver en indikation af, hvordan dagen var med hensyn til salg. Der sendes også et resumé til bankerne for alle kreditkorttransaktioner udført i løbet af dagen. Beholdningssystemet opdateres for at afspejle den korrekte lagerbalance.

Dette er et af de største testområder. Vigtige scenarier, som kan medtages som en del af EOD-test, kan være:

  • Kontroller, at EOD-proceskørsel er vellykket. Dette vil have flere forsætlige fejl for at sikre, at den operationelle dag er lukket eller ej. Sig i en restaurant, lederne vil ikke være i stand til at køre EOD-processen, hvis alle kontroller ikke lukkes, hvis alle medarbejdere ikke er blokeret fra systemet. Testning skal omfatte at køre denne proces inklusive alle kontroller med positive og negative scenarier. Normalt er dette en automatiseret proces, som er planlagt til at køre med et bestemt tidsinterval i rigtige butikker. Til testformål bør denne proces testes manuelt.
  • Bekræft, at afstemningsrapporter genereres, og valider indholdet af rapporten for at sikre, at data i rapporten stemmer overens med dataene fra den pågældende butik. Til sådanne testtyper kan testere manuelt oprette nogle transaktioner og registrere de indtastede data og generere afstemningsrapport i slutningen af ​​dagen og matche de data, de har indtastet. Afstemningsrapport ville være mere som en balance med debet- og kreditoplysninger.

2) Medarbejderplanlægning - En anden vigtig BOH-aktivitet involverer planlægningsfunktionen, der primært beskæftiger sig med at oprette en arbejdsplan for medarbejderne. Medarbejdere skal indstille systemet i henhold til deres tidsplan.

Planlægning kan udføres manuelt eller på en automatisk måde ved hjælp af data fra tidligere salgsmønstre og projektkrav. Planlægningen er en backend-aktivitet, men valideringen sker i frontenden, når medarbejderen forsøger at uret ind.

  • Validering skal omfatte kontrol af et ikke-planlagt ur ind
  • Planlagt sent ur ind og ud
  • Planlagt tidligt ur og ur ud

3) Lagerstyring - Et andet vigtigt område er lagerstyringen. Butikschefer kræver primært, at sådanne systemer sporer produkter gennem hvert trin i lagercyklussen og også har en idé, inden en vare falder under lagerniveauet.

Derfor er beholdningssystemer designet, så ledere kan bestille det rigtige produkt på det rigtige tidspunkt, i den rigtige mængde fra den rigtige leverandør og til den rigtige pris.

Testvalidering skal omfatte:

  • Validering af mængde, der skal købes
  • Advarsler, hvis lagerniveauet går under pari
  • Afgivelse af ordre
  • Validering af den korrekte vareliste med korrekt pris vises på POS til valg
  • Vare- og prisforening, validering på masterniveau

Niveau # 3) Virksomhedsniveaufunktioner

Virksomhedsniveaufunktioner kræver ikke, at du sidder foran POS-systemet for at udføre dem, men de gøres ved hjælp af enhver bærbar computer / desktop med appen eller softwaren installeret, men de er på en eller anden måde integreret i POS-systemerne. Hvis virksomhedsfunktioner udføres ved hjælp af en webapplikation, vil der være en mekanisme, der skubber ændringerne eller indstillingerne til POS.

1) HR og lønningsliste - HR- og lønsystem behandler medarbejderrekruttering, opretholder medarbejderløn / løn, arbejdslovgivning, skatteoplysninger, medarbejdertilgængelighed og medarbejderorlov.

For det meste sker vedligeholdelse af lønninger med en tredjepart som ADP osv. Derfor skal integrationen testes godt. HR-aktiviteterne opretholdes for det meste internt. Løn bliver et separat stort område til test, da det kræver alle mulige beregninger, før en medarbejders lønseddel bliver afsluttet. Det danner et stort muligheder for testning.

  • Validering kunne ske for HR-aktiviteter som at rekruttere medarbejdere og derefter sikre, at medarbejdere importeres til POS-systemer
  • Løn / Lønberegning i henhold til arbejdslove
  • Medarbejdernes evne til at indtaste efterladte detaljer

2) Finans og regnskab - Finans- og regnskabssystem er det, der kræver rapportering. P & L-udsagn, planlagte budgetter, afvigelser, daglig salg af butikker osv. Alle disse detaljer kræves af regnskabsteamet for at sikre, om POS-butikken er på rette spor eller ej.

Der træffes mange beslutninger baseret på denne analyses analyse. Sig, hvis teamet beslutter at åbne en ny butik baseret på historiske data og analyser, godkender regnskabsteamet budgettet og det område, hvor butikken kunne åbnes. Sådanne detaljer hjælper dem også med at finde områderne til forbedring.

  • Valider generering af korrekte rapporter
  • Bekræft analyselogikken
  • Validering af resultatopgørelse og balance

3) Leverandørstyring - For levering af varer vil enhver detailindustri kræve leverandører, der nu vurderer den rigtige leverandør, der giver en rimelig pris og overvåger deres ydeevne, alt taget hånd om af leverandørstyringssystemet.

Fra testperspektiv kan nedenstående vigtige valideringer udføres:

  • Validering af indtastning og vedligeholdelse af leverandørdetaljer i systemet
  • Bekræft leverandørpriser
  • Valider leverandørens ydeevne ved at spore levering til tiden, kvaliteten af ​​de leverede produkter osv.

4) DW og BI - Data varehus gør det muligt for enhver branche at gemme og opbevare detaljer om transaktionen i årevis, som kan bruges til at kende trends, formulere købsmønstre osv. Business Intelligence-værktøjer bruges til at hente denne enorme mængde data fra forskellige systemer og give slutbrugeren en mulighed til analyse.

DW-systemer opdateres fra de data, der kommer fra POS-systemerne. Derfor, fra testbehov, er dette igen afgørende for testning. Mange organisationer bruger BI-værktøjer eller nogle udvikler interne analyser. Men i begge tilfælde er test påkrævet.

c ++ stack datastruktur

DW- og BI-systemer hjælper folk på virksomhedsniveau ved at forenkle generering af rapporter og tilpasse rapporter efter deres behov, det hjælper også med en bedre præstationssporing.

  • Validering på POS-niveau kan foretages for transaktionsdata, men DW kræver validering af historiske data
  • Valider brugerens rapportgenereringsevne og tilpasning ved hjælp af BI-værktøj.

Konklusion:

Jeg håber, at denne artikel forklarede POS-test i detaljer. Jeg har en anden detaljeret artikel om, hvordan POS-systemtest kan udføres for restaurantbranchen.

Restaurant pos-systemer Testeksempel:

=> Læs artiklen om Restaurant POS-systemtest her at forstå mere om POS med et eksempel.

Anbefalet læsning

^