FT3テスト
この段階の目的は、まず、システムが規定の要件を満たしているかどうかを確認することでした。 要件に基づいて、Team Foundation Serverシステムが使用されるテストモデルが作成されました。 テストのために、必要な更新バージョンのソフトウェアとすべての必要な機器（コンピューター、カスタマーディスプレイ、フィスカルプリンター、バーコードスキャナー、キーボード、キャッシュドロワー、EFTターミナル、TSD）でテスト環境を準備しました。 Team Foundation Serverシステムは、バグの修正にも使用されました。 コンパイルされたテストモデルの一部として、次のタイプのテストが実行されました：機能テスト、修正された欠陥のテスト、および回帰テスト。 この段階で合意したすべてのテストケースを完了し、結果として見つかったすべてのバグを登録すると、システムは次の段階であるPOCテストの準備が整いました。POCテスト（概念実証）
この段階は、小売システムを導入する際にすべての側面を考慮しなければならなかった、店舗の概念とショッピングシステム「TK」全体の詳細を積極的に分析することを目的としています。 また、この段階では、ストアの作業に必要なプロセスまたは小さな機能を検出するために、現在のシステムのすべてのプロセスが分析されましたが、新しい「RS」システムには存在しないか不完全です。 この段階でのシステムのテストは、最初の段階と同じテスト環境で店舗の領域で行われましたが、テストモデルの一部としては実行されなくなりましたが、既存システムのすべてのプロセスの新しいシステムで複製（レクリエーション）モードで実行されました。 テストプロセス中に統計を収集するために、インシデントはTeam Foundation Serverシステムにも記録されました。 この段階では、実装されたシステムと既存のシステムのプロセスに重大な違いはなく、大きな改善は必要ないことが分析により示されたため、システムのパイロット起動の準備ができていました。パイロット試験
ここでのシステムの動作は、店舗の顧客サービスの品質に直接影響するため、最も重要な段階です。 それが、さまざまな専門家による店員の積極的な支援が組織されている理由です。 新しいシステムで作業するプロセスで店舗の従業員をサポートするために、本稼動システムのパイロットバージョンがテストされています。 これは、次のモードで実行されます。新しいシステムで通常どおり作業する従業員は、さまざまな困難に直面します。 これは、システムエラーまたは使用する「不便」のいずれかです。 何らかの方法でシステムアナリストが状況を分析し、必要に応じてテスターがTeam Foundation Serverシステムのバグを修正します。 優先度1および2の高いバグは開発者によって短時間で修正され、本番環境と同じ構成のテスト環境で再テストに合格します。 再テストに成功したバグは、Hot-Fixインストールに進みます。 それほど重大ではないバグは、通常モードで修正し、通常のビルド（バージョン）のインストールに進む必要があります。 また、この段階では、無料の検索方法を使用してテストが実行されます。 このテスト中に見つかったバグは、Team Foundation Serverシステムにも記録されます。予想どおり、各段階で、テストの目的に従って、さまざまなインシデントが記録されました。
そのため、たとえばFT3テスト段階では、TSD（データ収集端末-スキャナーを搭載したモバイル機器を使用して、ミックスボックス（小さな商品のある完全な箱）を開梱する機能をテストしました。顧客に発行する前に）。 指定された要件に従って、スキャンされたミックスボックス内の商品の余剰に関するメッセージをTSDに表示することは禁止されており（従業員による盗難のケースを除外するため）、システムはこの要件を正しく満たしていました。 しかし、すでにPOCテスト段階で、開梱中にこのメッセージが存在しないことは、開梱プロセスに倉庫操作に特定の不便を課すことは明らかでした。また、パイロットテスト段階では、倉庫、および店舗全体。 その結果、ミックスボックスの開梱時にTSD画面にこのメッセージを表示するための変更要求が作成され、このシステムに正常に実装されました。
別の例として、リモート倉庫からクライアントに配送するためのアプリケーションを作成する必要があった状況（商品は店頭では利用できないが、配送を直接注文できる別のTK倉庫の1つにある状況）を挙げることができます。 FT3テスト段階で、この機能がテストされ、要件に従って正しく機能しました。 しかし、POCテストの段階では、この配送方法では店舗のルールに応じた制限があることが判明しました。配送は注文日から10日目にのみ発行できます。 その後、システムはすでに注文日から3日目にこれを行うことができたため。 ここで人的要因が働いたため、従業員はクライアントに配達するときにミスを犯す可能性がありました。 その結果、この状況で納期を修正するバグが作成され、システムの開発者によって正常に修正されました。
したがって、さまざまな段階でテストを行うと、さまざまな結果が得られ、ある段階では別の段階では発見できないエラーを特定するのに役立ちました。