メニュー

POS（Point of Sale）システムをテストする方法–レストランのPOSテストの例

how test point sale system restaurant pos testing example

問題を排除するために楽器を試してください

POS（Point of Sale）とは何ですか？

POSエイリアスのPOSは、トランザクションが行われる場所です。 POSシステムは、小売店、レストラン、病院、そして最近では支払いが関係するほとんどすべての場所で見ることができます。

クラスc ++への未定義の参照

ほとんどの人はバーコードリーダーやワイヤレス決済デバイス（決済トランザクションで最もよく使用されるデバイス）をよく理解しているかもしれませんが、実際にはPOSには多くのコンポーネントが含まれており、各コンポーネントを適切に統合する必要があります正常に実行します。

今日の記事では、POSテストが他のテストと異なる点について説明します。また、これをテストコミュニティに役立つように、記事全体にテストのヒントを取り入れました。

  • の例 レストランPOSシステムテスト 含まれています

POSシステムのテスト

を見ようよ：

  • POSアプリケーションテストの違い
  • EPOS（電子販売時点管理）アーキテクチャ
  • EPOS物理コンポーネント
  • POSのレベル/機能
  • の例 レストランPOSシステムテスト 含まれています

推奨読書=> eコマースアプリケーションをテストする方法

学習内容：

POSテストの違い：

POSシステムテストは複雑に見えますが、概念をよく理解している人にとってはそれほど難しいことではありません。お店に座っているような感覚が得られるのでおもしろいです テストケースの実行 POSは、他の店舗で見られるようにセットアップが必要なためです。

これは、キュービクルに座ってWebアプリでいくつかのチェックを実行する場合とは異なります。 POSシステムテストを扱う組織は、別々のラボを維持しています。

POSテストの課題は何ですか？

  • ストアの要件に応じた複数の構成–簡単な例たとえば、小売チェーンが特定の1つの都市でのみプロモーションオファーを実行したい場合、そのような場合、その都市で実行されているPOSシステムに対して特別な構成を行う必要があります。
  • POSには、すべてのデバイス、および複数のタイプのハードウェアデバイスとソフトウェアのバージョンを適切にセットアップする必要があります。
  • 複数のデバイス 互換性テストが必要 また、徹底的な統合テスト
  • POSテストはエンドユーザーのカードの詳細を処理するため、PCIに準拠しています。

POSアーキテクチャ：

POSアーキテクチャ

ストア内の各端末はファイルサーバーに接続されています。設定または主な構成はサーバー上で行われ、ストア内の各端末にプッシュされます。 XMLまたはバッチジョブは、このような更新を行うために使用されます。

大規模な小売店またはチェーン店の場合、変更はローカルで行われません。 POSシステムはカード決済を受け入れるため、主にクレジットカード処理を行うサードパーティプロバイダーと統合されており、クレジットカード取引が行われるたびに、データが承認のためにサードパーティまたは銀行に送信されます。

（画像をクリックすると拡大表示されます）

POSアーキテクチャ1

Windowsでdatファイルを表示する方法

画像 ソース 。

POS物理コンポーネントとこれらをテストする方法：

＃1）ターミナル- ターミナルは、取引の詳細を入力するために使用されるメイン画面です。これらは主にタッチスクリーンデバイスです。製品リスト、価格設定、プロモーションオファー、支払いモードに関連するすべての構成が端末にプッシュされます。これは、すべてのPOSで使用されるメインデバイスです。

  • ターミナルテストでは、デバイスがネットワークに接続されていること、およびPOSアプリをサポートするために最新のOSがネットワーク上で実行されていることを確認するための検証が必要です。

＃2）ディスプレイポール– ディスプレイポールは、バーコードスキャナーを使用して商品をスキャンすると、商品の価格を表示するデバイスです。

  • ディスプレイポールにPOS端末と同じ価格が表示されていることを確認します

＃3） バーコードリーダー - バーコードリーダーは、製品をスキャンするために使用されます。スキャンが完了すると、バックエンドでチェックが実行され、アイテムが在庫リストに存在するかどうかが確認され、アイテムの価格も取得されます。アイテムが販売されると、在庫が更新され、利用可能なユニット数が減少します。

  • テストの目的で、在庫リストにない製品をスキャンすることで検証を行うことができます
  • 在庫リストにあるが価格がタグ付けされていない製品をスキャンして検証します
  • 価格レベルに適切なタグを付けて、在庫リストで利用可能な製品をスキャンして検証します。

＃4）レジ– レジは現金の保管に使用されます。現金取引の場合、レジはすぐに開き、レジ係は顧客からの現金を受け取り、残高がある場合はそれを返します。

  • レジのテストは、支払いモードを現金として選択し、払い戻し金額で現金取引を行うことで実行できます。

＃5）ハンドヘルドデバイス– ハンドヘルドデバイスは、クレジットカードによる支払いを受け入れるために使用されるワイヤレスデバイスです。これらは、ユーザーがカードの暗証番号を入力できるエンドユーザーにデバイスを直接運ぶことにより、ユーザー認証を簡単に取得できるようにします。

  • カードとして支払い方法を選択してトランザクションを作成することで、テストを実行できます。
  • 手動で金額を入力するための検証を行う必要があります。

＃6）プリンター– プリンターは各端末に接続され、レジスタープリンターと呼ばれ、各トランザクションの後にレシートを生成するために使用されます。

  • テスターは、レシートの印刷を確認し、配置、テキストの上書き、テキストサイズ、フォントなどを確認できます。
  • エラー処理のケースを確認できます。たとえば、プリンタが準備完了状態にないとき、またはプリンタの用紙がなくなったときに印刷が行われた場合はどうなるかを確認できます。
  • トランザクションの途中でプリンターがオフラインになったり、接続が失われたりした場合の結果を確認します。

＃7）磁気スワイプリーダー– MSRは、支払いに使用されるカード（デビットカード、クレジットカード、ギフトカード）をスワイプするために使用されます。これは主に小売店やレストランで使用されますが、ユーザーが支払いのためにPINを入力する必要がある時間の変化に伴い、多くの場所でワイヤレスデバイスがカード支払いの受け入れに使用されていることがわかります。

  • ギフトカードの場合、MSRは残高確認、有効期限、支払いに使用されます。印刷された領収書は、承認のためにゲストに渡されます。テスターはこれらのケースを検証する必要があります。

また読む=> すべてのテスターが知っておくべき7種類のソフトウェアエラー

POSのレベル/機能：

POSには基本的に3つのレベルまたは機能があります。

POSのレベル機能

レベル＃1）アプリケーションレベル/フロントオフィス機能：

1）販売取引– POSシステムの主な目的は、トランザクションを容易にすることです–

  • バーコードデバイスを使用したアイテムスキャンまたはキーボードを使用した手動入力を含む、成功した販売トランザクションを検証し、支払い総額が計算されて画面に表示され、支払いと領収書の印刷が成功することを確認します。
  • 正しい税額計算の検証

2）支払い– 支払いは、テスターに​​とってさらに重要な範囲です。これは、POSで受け入れられている幅広い支払いモードによるものです。POSでは、カード、現金、ギフトカードによる支払いが可能です。また、特定のクーポンコード、割引券もご利用いただけます。

  • 現金検証– 現金検証は、テストするのが最も簡単なものです。システムは残りの残高を計算し、レジ係の仕事が顧客に金額を簡単に返金できるようにします。多くの場合、ユーザーは部分的な支払いを好む場合があります。一部はギフトカード（GC）を使用し、残りは現金で支払います。システムが部分的な支払いを受け入れて許可するかどうかを検証するために、テストを実行する必要があります。
  • カードの検証– カードによる支払いには、常に第三者の承認が必要です。カードの支払いは、MSRまたはハンドヘルドデバイスを介してカードをスワイプし、指定された金額の顧客の承認を取得することから始まります。その後、同じ金額がサードパーティの銀行によって承認されます。
  • ギフトカードの検証– テスターは、有効期限を検証できます。償還前のカードの金額は、MSRでカードをスワイプして検証できます。両方向にスワイプしてシステムの動作を確認し、部分支払いトランザクションで検証し、カードを使用して過払いで検証します。
  • 割引/クーポン/プロモーションオファー– システムはクーポンコードのみを受け入れ、すべてのタイプの割引を受け入れるようには設計されていないため、これは注意が必要なテスト領域です。したがって、検証はすべてのタイプの組み合わせで構成する必要があります。テストは、合計金額で機能するコードを使用するか、特定のアイテムに適用される割引券を使用して実行できます。繰り返しになりますが、プロモーションオファーは短命であり、どこにでも適用できるわけではないため、割引やクーポンのテストには少し注意が必要です。また、割引が適用される順序を検証します。場合によっては、店舗の割引がメーカーのクーポンに対して機能しないこともあれば、機能することもあります。したがって、これをテストするときは特に注意してください。

レベル＃2）バックオブハウス機能

1）一日の終わり– 一日の終わりは、バックエンドで行われる最も重要なアクティビティです。 EOD中に、いくつかの調整が行われ、バックエンドシステムが更新されます。

毎日の売上調整を含むいくつかの要約レポートが生成され、利害関係者に送信されます。これは、その日の売上がどのようであったかを示すためです。また、日中に行われたすべてのクレジットカード取引の概要が銀行に送信されます。在庫システムは、正しい在庫バランスを反映するように更新されます。

これは、テストの主要な領域の1つを形成します。 EODテストの一部として含めることができる重要なシナリオは次のとおりです。

  • EODプロセスの実行が成功したことを確認します。これには、営業日が終了しているかどうかを確認するための意図的な失敗がいくつかあります。レストランで言うと、すべての従業員がシステムからクロックアウトされていない場合、すべてのチェックが閉じられていないと、マネージャーはEODプロセスを実行できません。テストには、ポジティブシナリオとネガティブシナリオのすべてのチェックを含むこのプロセスの実行を含める必要があります。通常、これは実際の店舗で特定の時間間隔で実行されるようにスケジュールされた自動化されたプロセスです。テストの目的で、このプロセスは手動でテストする必要があります。
  • 調整レポートが生成されていることを確認し、レポートの内容を検証して、レポートのデータがその特定のストアのデータと一致していることを確認します。このようなタイプのテストの場合、テスターは手動でいくつかのトランザクションを作成し、入力されたデータを記録し、日の終わりに調整レポートを生成して、入力されたデータと照合することができます。調整レポートは、借方と貸方の詳細が記載された貸借対照表のようなものになります。

2）従業員スケジューリング– もう1つの重要なBOHアクティビティには、主に従業員の勤務スケジュールの作成を処理するスケジューリング機能が含まれます。従業員は、スケジュールに従ってシステムにクロックインする必要があります。

スケジューリングは、手動で行うことも、過去の販売パターンとプロジェクトの労働要件からのデータを使用して自動化された方法を使用して行うこともできます。スケジューリングはバックエンドアクティビティですが、検証は従業員が出勤しようとしたときにフロントエンドで行われます。

  • 検証には、スケジュールされていないクロックの検証を含める必要があります
  • スケジュールされたレイトクロックインおよびクロックアウト
  • スケジュールされた早期の出勤と退勤

3）在庫管理– もう1つの重要な領域は在庫管理です。店長は主に、在庫サイクルの各段階を通じて製品を追跡し、アイテムが在庫レベルを下回る前にアイデアを持っているようなシステムを必要とします。

したがって、在庫システムは、管理者が適切な製品を適切なタイミングで、適切なベンダーから適切な数量で、適切な価格で注文できるように設計されています。

テスト検証には以下を組み込む必要があります。

  • 購入数量の検証
  • 在庫レベルが標準を下回った場合に警告します
  • 注文
  • 正しい価格で正しいアイテムリストを検証することは、選択のためにPOSに表示されます
  • アイテムと価格の関連付け、マスターレベルの検証

レベル＃3）企業レベルの機能

企業レベルの機能では、POSシステムの前に座ってそれらを行う必要はありませんが、アプリまたはソフトウェアがインストールされたラップトップ/デスクトップを使用して実行されますが、何らかの方法でPOSシステムと統合されています。企業機能がWebアプリケーションを使用して実行される場合、変更または設定をPOSにプッシュするメカニズムがあります。

1）人事と給与– 人事および給与システムは、従業員の採用、従業員の給与/賃金の維持、労働法、税の詳細、従業員の可用性、および従業員の休暇を扱います。

ほとんどの場合、給与計算のメンテナンスはADPなどのサードパーティで行われるため、統合を十分にテストする必要があります。人事活動は主に社内で維持されています。給与は、従業員の給与額が確定する前にあらゆる種類の計算が必要になるため、テスト用の独立した巨大な領域になります。それはテストのための巨大な範囲を形成します。

  • 検証は、従業員の採用や、従業員がPOSシステムにインポートされていることの確認などの人事活動に対して行うことができます。
  • 労働法に基づく給与/賃金の計算
  • 休暇の詳細を入力する従業員の能力

2）財務および会計– 財務会計システムは、報告が必要なシステムです。損益計算書、計画予算、差異、店舗の1日の売り上げなど。これらすべての詳細は、POSストアが順調に進んでいるかどうかを確認するために経理チームが必要とします。

これらのレポートの分析に基づいて、多くの決定が行われます。たとえば、チームが履歴データと分析に基づいて新しい店舗を開くことを決定した場合、アカウントチームは、店舗を開くことができる予算とエリアを承認します。また、そのような詳細は、彼らが改善すべき領域を見つけるのに役立ちます。

  • 適切なレポートの生成を検証する
  • 分析ロジックを確認する
  • 損益計算書と貸借対照表の検証

3）ベンダー管理– 商品の供給については、小売業界はベンダーを必要とします。現在、リーズナブルな価格を提供する適切なベンダーを評価し、そのパフォーマンスを監視することは、すべてベンダー管理システムによって処理されます。

テストの観点から、以下の重要な検証を行うことができます。

  • システムへのベンダー詳細の入力と保守の検証
  • ベンダーの価格を検証する
  • 時間通りの配達、配達された製品の品質などを追跡することにより、ベンダーのパフォーマンスを検証します。

4）DWおよびBI- データウェアハウス あらゆる業界がトランザクションの詳細を何年にもわたって保存および保持できるようにします。これは、傾向の把握、購入パターンの策定などに使用できます。ビジネスインテリジェンスツールは、さまざまなシステムからこの膨大な量のデータを取得し、エンドユーザーに機会を与えるために使用されます。分析用。

DWシステムは、POSシステムからのデータから更新されます。したがって、テストのニーズから、これもテストにとって重要です。多くの組織がBIツールを使用しているか、一部の組織が社内分析を開発しています。ただし、どちらの場合も、テストが必要です。

c ++はcharをstringに変換します

DWおよびBIシステムは、レポートの生成を簡素化し、ニーズに応じてレポートをカスタマイズすることにより、企業レベルの人々を支援します。また、パフォーマンスの追跡を向上させるのにも役立ちます。

  • POSレベルでの検証はトランザクションデータに対して実行できますが、DWでは履歴データの検証が必要です
  • BIツールを使用して、ユーザーのレポート生成機能とカスタマイズを検証します。

結論：

この記事でPOSテストについて詳しく説明していただければ幸いです。レストラン業界でPOSシステムテストを行う方法についての詳細な記事がもう1つあります。

レストランPOSシステムテスト例：

=> こちらのレストランPOSシステムテストの記事をお読みください 例を挙げてPOSについて詳しく理解する。

推奨読書

^