Meny

Hur man testar POS-systemet (POS) - Restaurang POS-testexempel

how test point sale system restaurant pos testing example

Prova Vårt Instrument För Att Eliminera Problem

Vad är försäljningsstället (POS)?

POS alias Point of Sale är en plats där transaktioner äger rum. Du kan se kassasystem i butiker, restauranger, sjukhus och nästan överallt idag där betalningar är inblandade.

De flesta av er kanske mycket väl förstår vad en streckkodsläsare är eller en trådlös betalningsenhet är (de mest använda enheterna för betalningstransaktioner) men POS involverar i själva verket många komponenter och var och en av komponenterna måste integreras väl för det att köra framgångsrikt.

I dagens artikel ska jag skriva om vad som gör att POS-test skiljer sig från andra. Jag har också införlivat testtips i hela artikeln för att göra det till hjälp för vår testgrupp.

  • Exempel av Restaurang POS-systemtestning ingår också

Testar POS-system

Låt oss titta på:

  • Vad gör testet för POS-applikationer annorlunda
  • EPOS (Electronic Point of Sale) Architecture
  • EPOS fysiska komponenter
  • Nivåer / funktioner för POS
  • Exempel av Restaurang POS-systemtestning ingår

Rekommenderad läsning=> Hur man testar en e-handelsapplikation

Vad du kommer att lära dig:

Vad gör POS-testning annorlunda:

POS-systemtest ser komplicerat ut, men det är inte så knepigt för dem som förstår konceptet bra. Det är intressant eftersom du får en känsla av att sitta i en butik och utför dina testfall eftersom POS kräver installation som du skulle se i alla butiker.

Detta gör det annorlunda jämfört med att sitta i ditt skåp och köra några kontroller i en webbapp. Organisationer som hanterar POS-systemtester har separata laboratorier.

bästa webbhotell företag i Indien

Vilka är utmaningarna i POS-testning?

  • Flera konfigurationer enligt butikskravet - jag kommer att förklara med enenkelt exempelsäger att en detaljhandelskedja bara vill köra ett kampanjerbjudande i en viss stad. I sådana fall krävs särskilda konfigurationer för POS-system som körs i den staden.
  • POS kräver en korrekt installation med alla enheter och även flera typer av hårdvaruenheter och versioner av programvaran.
  • Flera enheter kräver kompatibilitetstest och också en grundlig integrationstestning
  • PCI-kompatibel, eftersom POS-test handlar om slutanvändarens kortuppgifter.

POS-arkitektur:

POS-arkitektur

Var och en av terminalerna i en butik är ansluten till en filserver. Inställningarna eller huvudkonfigurationerna görs på servern och trycks sedan till var och en av terminalerna i butiken. XML: er eller batchjobb används för att göra sådana uppdateringar.

För stora butiker eller butikskedjor görs ingen av ändringarna lokalt. Eftersom kassasystem accepterar kortbetalning är de integrerade med tredjepartsleverantörer som huvudsakligen gör kreditkortshantering, så när en kreditkortstransaktion sker skickas data till tredje part eller banker för auktorisering.

(Klicka på bilden för förstorad vy)

POS-arkitektur 1

bästa gratisprogramvaran för att optimera datorns prestanda

Bild Källa .

POS fysiska komponenter och hur man testar dessa:

# 1) Terminal - Terminal är huvudskärmen som används för att ange detaljerna i transaktionen. Dessa är mestadels pekskärmsenheter. Alla konfigurationer, vare sig det är relaterat till produktlista, prissättning, kampanjerbjudanden, betalningsmetoder, skjuts till terminalen. Detta är den huvudsakliga enheten som används vid alla kassor.

  • Terminal Testing kräver validering för att säkerställa att enheterna är anslutna till nätverket och att det senaste operativsystemet körs på det för att stödja POS-appen.

# 2) Displaypol - Display Pole är den enhet som visar artikelpriset när produkten skannas med streckkodsläsaren.

  • Kontrollera att displaypolen visar samma pris som på POS-terminalen

# 3) Streckkodsläsare - Streckkodsläsare används för att skanna produkterna. När skanningen är klar görs en kontroll i backend för att verifiera om artikeln finns i lagerlistan och även hämta artikelpris. När varan sålts uppdateras lagret för att minska det tillgängliga antalet enheter.

  • För teständamål kan validering göras genom att skanna en produkt som saknas i inventeringslistan
  • Validera genom att skanna produkter som finns i lagerlistan men utan prisetiketter
  • Validera genom att skanna produkter som finns i lagerlistan med rätt märkning till en prisnivå.

# 4) Kassaapparat - Kassaregister används för att lagra kontanter. För alla kontanttransaktioner öppnas kassaregistret omedelbart för kassörerna att acceptera kontanter från kunden och även returnera balansbeloppet om det finns något.

  • Kassaregistrering kan göras genom att välja betalningsläge som Kontant och genomföra kontanttransaktioner med ett återbetalningsbelopp.

# 5) Handhållen enhet - Handhållna enheter är trådlösa enheter som används för att acceptera kreditkortsbetalningar. Dessa gör det enkelt att få användarautentisering genom att bära enheten till slutanvändaren direkt, där användare kan ange kortnål.

  • Testning kan göras genom att skapa en transaktion genom att välja ett betalningssätt som kort.
  • Verifiering för manuell inräkning av belopp bör göras.

# 6) Skrivare - Skrivare är anslutna till var och en av terminalerna och kallas som registerskrivare, dessa används för att generera kvittot efter varje transaktion.

  • Testare kan verifiera kvittoutskrift, kontrollera om de är justerade, textöverskrivningar, textstorlek, teckensnitt etc.
  • Felhanteringsfall kan verifieras, säg vad som kommer att hända om utskriften ges när skrivaren inte är i färdigt skick eller om skrivaren har slut på papper.
  • Kontrollera resultatet när skrivaren går offline eller förlorar anslutningen mitt i transaktionen.

# 7) Magnetisk svepläsare - MSR används för att dra kort som används för betalning, vilket kan vara debet-, kredit- eller presentkort. Detta används oftast i butiker eller restauranger, men med föränderliga tider, där en användare måste ange PIN-koden för betalning, på många ställen skulle du se att en trådlös enhet används för att acceptera kortbetalningar.

  • När det gäller presentkort används MSR för balanskontroll, utgångsdatum och för betalning. Tryckta kvitton ges till gästerna för auktorisering. Testare bör validera dessa fall.

Läs också=> 7 typer av programvarufel som varje testare borde veta

Nivåer / funktioner för POS:

Det finns i princip tre nivåer eller funktioner involverade i POS.

Nivåfunktioner för POS

Nivå 1) Applikationsnivå / Front Office-funktioner:

1) Försäljningstransaktion - Huvudsyftet med alla kassasystem är att underlätta transaktioner -

  • Validering av en framgångsrik försäljningstransaktion som skulle inkludera genomsökning med antingen en streckkodsenhet eller manuell inmatning med tangentbordet, vilket säkerställer att det totala betalningsbeloppet beräknas och visas på skärmen och att det ska sluta med en lyckad utskrift av betalning och kvitto.
  • Validering av korrekt beräkning av skattebelopp

2) Betalning - Betalning är ännu ett viktigt område för testare. Detta beror på det stora utbudet av betalningssätt som accepteras av POS. En POS tillåter betalning via kort, kontanter, presentkort. De accepterar också vissa kupongkoder, rabattkuponger.

  • Validering av kontanter - Kontantvalidering är den enklaste att testa. Systemet beräknar återstående saldo och gör det möjligt för kassörens jobb att återbetala beloppet till kunden. Många gånger föredrar användarna att göra delbetalningar - vissa med hjälp av presentkort (GC) och återstår med kontanter. Testning bör göras för att validera om systemet accepterar och tillåter delbetalningar.
  • Kortvalidering - Betalning via kort kräver alltid tredjepartsbehörighet. Kortbetalning börjar med att svepa kortet - genom MSR eller en handhållen enhet och sedan ta kundens auktorisering för det angivna beloppet. Samma belopp godkänns sedan av banker från tredje part.
  • Validering av presentkort - Testare kan validera utgångsdatumet, ett belopp på kortet innan inlösen kan valideras genom att svepa kortet på MSR, dra det åt båda hållen för att se systembeteende, validera i delbetalningstransaktionen, validera genom att överbetala med kortet.
  • Rabatter / kuponger / kampanjerbjudanden - Detta är ett knepigt testområde eftersom systemen är utformade för att endast acceptera en kupongkod och inte alla typer av rabatter, varför validering bör bestå av alla typer av kombinationer. Testning kan göras genom att använda en kod som fungerar på det totala beloppet eller använda en rabattkupong som gäller för vissa artiklar. Återigen är kampanjerbjudanden kortlivade och är inte tillämpliga överallt, därför kräver testning av rabatter och kuponger lite vård. Validera också den ordning i vilken rabatter tillämpas. Ibland fungerar butiksrabatter inte över tillverkarens kuponger och ibland gör de det. Så var extra försiktig när du testar detta.

Nivå 2) Baksidan av husfunktioner

1) Slut på dagen - End of Day är den viktigaste aktiviteten som görs i backend. Under EOD görs flera avstämningar och backend-system uppdateras.

Flera sammanfattningsrapporter, inklusive den dagliga försäljningsavstämningen, genereras och skickas till intressenter eftersom detta ger en indikation på hur dagen var när det gäller försäljning. Dessutom skickas en sammanfattning till bankerna för alla kreditkortstransaktioner som gjorts under dagen. Lagersystemet uppdateras för att återspegla korrekt lagerbalans.

Detta utgör ett av de viktigaste områdena för test. Viktiga scenarier som kan inkluderas som en del av EOD-testning kan vara:

  • Kontrollera att EOD-processkörningen är framgångsrik. Detta kommer att ha flera avsiktliga misslyckanden för att säkerställa att den operativa dagen är stängd eller inte. Säg i en restaurang, cheferna kommer inte att kunna köra EOD-processen om alla kontroller inte stängs om alla anställda inte är urklockade från systemet. Testning bör inkludera att köra denna process inklusive alla kontroller med positiva och negativa scenarier. Vanligtvis är detta en automatiserad process som är planerad att köras vid ett visst tidsintervall i riktiga butiker. För teständamål bör denna process testas manuellt.
  • Kontrollera att avstämningsrapporter genereras och validera innehållet i rapporten för att säkerställa att data i rapporten matchar data från den aktuella butiken. För sådana typer av test kan testare skapa manuella transaktioner manuellt och hålla reda på de angivna uppgifterna och generera avstämningsrapport vid slutet av dagen och matcha de uppgifter de angav. Avstämningsrapporten skulle vara mer som en balansräkning med debet- och kredituppgifterna.

2) Schemaläggning av anställda - En annan viktig BOH-aktivitet innefattar schemaläggningsfunktionen som huvudsakligen handlar om att skapa ett arbetsschema för anställda. Anställda bör klocka in i systemet enligt deras schema.

Schemaläggning kan göras manuellt eller på ett automatiserat sätt genom att använda data från tidigare försäljningsmönster och projektarbetskrav. Schemaläggningen är en backendaktivitet men valideringen sker i fronten när den anställde försöker klocka in.

  • Validering bör inkludera verifiering av en icke schemalagd klocka in
  • Schemalagd sen klocka in och ut
  • Planerad tidig klocka in och klocka ut

3) Lagerhantering - Ett annat viktigt område är lagerhanteringen. Butikschefer kräver främst att sådana system spårar produkter genom varje steg i lagercykeln och också har en idé innan en artikel faller under lagernivån.

Därför är lagersystem utformade så att chefer kan beställa rätt produkt vid rätt tidpunkt, i rätt mängd från rätt leverantör och till rätt pris.

Testvalidering bör innehålla:

hur man gör en ddos-attack på en webbplats
  • Validering av kvantitet som ska köpas
  • Varnar om lagernivån går under pari
  • Beställning
  • Validering av rätt artikellista med korrekt prissättning visas på POS för val
  • Artikel- och prisförening, validering på masternivå

Nivå 3) Företagsnivåfunktioner

Företagsnivåfunktioner kräver inte att du sitter framför kassasystemet för att göra dem, men de görs med vilken bärbar dator som helst med appen eller programvaran installerad, men de är på något eller annat sätt integrerade i kassasystemen. Om företagsfunktioner görs med hjälp av en webbapplikation kommer det att finnas en mekanism som kommer att driva ändringarna eller inställningarna till POS.

1) HR och löner - HR- och lönesystemet handlar om rekrytering av anställda, upprätthållande av löner för arbetstagare, arbetslagar, skatteuppgifter, anställds tillgänglighet och anställningsledighet.

För det mesta sker löneunderhållet med en tredje part som ADP etc., därför måste integrationen testas väl. HR-aktiviteterna upprätthålls oftast internt. Lönen blir ett separat stort område för testning eftersom det kräver alla typer av beräkningar innan en anställds lönecheckbelopp slutförs. Det utgör ett stort utrymme för testning.

  • Validering kan göras för HR-aktiviteter som att rekrytera anställda och sedan se till att anställda importeras till kassasystem
  • Lön / löneberäkning enligt arbetslagar
  • Anställdas förmåga att ange lämningsinformation

2) Ekonomi och redovisning - Ekonomi- och redovisningssystemet är det som kräver rapporteringen. P & L-uttalanden, planerade budgetar, avvikelser, daglig försäljning av butiker etc. Alla dessa uppgifter krävs av redovisningsteamet för att säkerställa om POS-butiken är på rätt spår eller inte.

Många beslut fattas baserat på analysen av denna rapport. Säg, om teamet beslutar att öppna en ny butik, baserat på historisk data och analys, godkänner kontoteamet budgeten och det område där butiken skulle kunna öppnas. Sådana detaljer hjälper dem också att hitta områdena för förbättringar.

  • Validera genereringen av korrekta rapporter
  • Verifiera analyslogiken
  • Validering av resultaträkning och balansräkning

3) Leverantörshantering - För leverans av varor skulle alla detaljhandelsbranscher kräva leverantörer, som nu utvärderar rätt leverantör som tillhandahåller en rimlig prissättning och övervakar deras prestanda tas alla hand av leverantörshanteringssystemet.

Ur testperspektiv kan nedan viktiga valideringar göras:

  • Validerar inmatning och underhåll av leverantörsdetaljer i systemet
  • Validera leverantörspriser
  • Validera leverantörens prestanda genom att spåra leverans i tid, kvalitet på levererade produkter etc.

4) DW och BI - Datalager gör det möjligt för alla branscher att lagra och behålla information om transaktionen i flera år som kan användas för att känna till trenderna, formulera köpmönster etc. Business Intelligence-verktyg används för att hämta den enorma mängden data från olika system och ge slutanvändaren en möjlighet för analys.

DW-system uppdateras från de data som kommer från POS-systemen. Följaktligen, från testbehov, är detta igen viktigt för testning. Många organisationer använder BI-verktyg eller vissa utvecklar intern analys. Men i båda fallen krävs testning.

DW- och BI-system hjälper människor på företagsnivå genom att förenkla generering av rapporter och anpassa rapporter enligt deras behov, det hjälper också till bättre spårning av prestanda.

  • Validering på POS-nivå kan göras för transaktionsdata, men DW kräver validering av historiska data
  • Validera användarens rapportgenereringsförmåga och anpassning med hjälp av BI-verktyget.

Slutsats:

Jag hoppas att den här artikeln förklarade POS-test i detalj. Jag har en annan detaljerad artikel om hur POS-systemtestning kan göras för restaurangbranschen.

Restaurang pos-system Testningsexempel:

=> Läs artikeln om POS-system för restaurang här att förstå mer om POS med ett exempel.

Rekommenderad läsning

^