Testing retail systems

In the article we will tell about our experience in testing retail systems, and using the example of one implementation, we will tell how this happens. And so the statement of the problem: It is necessary to transfer the existing business processes of TK to the new technological platform “RS” - this is a retail automation system designed for centralized management of a retail network of any size and structure. “PC” is a “boxed” product, so it was not enough to simply check the functionality of the system, it was necessary to analyze and match the processes of the TK store system and the system being implemented. In this regard, testing was divided into 3 stages: FT3 Testing, POC Testing, Pilot Testing. Below we will focus on each stage in more detail:

FT3 Testing

The purpose of this stage, first of all, was to check the system for compliance with the stated requirements. Based on the requirements, a test model was created, which was compiled using the Team Foundation Server system. For testing, a test environment was prepared with the necessary and updated software version and all the necessary equipment (computer, customer display, fiscal printer, barcode scanner, keyboard, cash drawer, EFT terminal, TSD). To fix bugs, the Team Foundation Server system was also used. As part of the compiled test model, the following types of testing were conducted: functional testing, testing of corrected defects, and regression testing. After all the test cases agreed at this stage were completed and all the bugs found as a result were registered, the system was ready for the next stage - POC Testing.

POC Testing (Proof of Concept)

This stage was aimed at conducting an active analysis of the concept of this store and the specifics of the TK trading system as a whole, all aspects of which had to be taken into account when introducing a retail system. Also at this stage all the processes of the current system were analyzed, in order to detect processes or small functionality that is necessary in the operation of the store, but it is missing or flawed in the RS system. Testing of the system at this stage took place in the store in the test environment that was identical to the first stage, but it was no longer carried out within the framework of the test model, but in the duplication mode (recreation) in the new system of all the existing system processes. In order to collect statistics during the testing process, any incidents were also recorded in the Team Foundation Server system. During this stage, the analysis showed that there are no critical differences between the processes being implemented and the already existing system, and there is no need for major modifications, so readiness for a pilot launch of the system has come.

')

Pilot testing

The most important stage, as the work of the system here directly affects the quality of customer service of the store. That is why the active support of store employees by various specialists is organized. In the course of supporting the store employees in the process of working with the new system, a pilot version of the productive system is being tested. It is conducted in the following mode: the store employees, working in the usual mode with the new system, face various difficulties. This can be either a system error or an “inconvenience” of use. Anyway, any situation is analyzed by the system analyst and then, if necessary, the tester fixes a bug in the Team Foundation Server system. Bugs with high, 1 and 2 priority, are corrected by developers in a short time, pass retest in a test environment that has an identical production environment configuration. Successfully retested bugs and go to the installation of Hot-Fix. Less critical bugs are fixed as usual and go to the installation of regular builds (versions). In addition, at this stage, testing is conducted by the method of free search. The bugs found during this test are also recorded in the Team Foundation Server system.



As expected, at each of the stages, in accordance with the objectives of the test, various incidents were recorded.



For example, at the FT3 Testing stage, the functionality of unpacking mix boxes (a complete box with small goods) was tested using a TSD (Data collection terminal is a mobile equipment equipped with a scanner with which you can carry out all possible relocations in the store: from acceptance to the warehouse before delivery to the client). It was known that, in accordance with the stated requirements, it was forbidden to display a message on the TSD about the scanned surplus of goods in the mix box (in order to exclude cases of theft by employees) and the system correctly met this requirement. But already at the POC Testing stage it was clear that the absence of this message during unpacking imposes certain inconveniences in the warehouse operation on the unpacking process, and at the Pilot Testing stage it turned out that the absence of this message carries the consequences that seriously affect the performance of warehouse and the entire store. As a result, a Change Request was created for the need to display this message on the TSD screen when unpacking mix-boxes, which was successfully implemented in this system.



As another example, you can bring a situation when it was necessary to carry out an application for delivery to a customer from a remote warehouse (a situation when there is no product in the store, but it is in one of the separate warehouses “TK”, where you can directly order delivery) . At the FT3 Testing stage, this functionality was tested and it was correctly processed according to the requirements. But at the POC Testing stage, it came out that with this method of delivery there is a restriction on the rules of the store: delivery can only be made on the tenth day from the date of the order. Then, as the system allowed to do this on the third day from the date of the order. Here, the human factor worked, and employees could make a mistake in arranging the delivery to the client, which resulted in incorrect informing the client and incorrectly issued delivery documents. As a result, a bug was created to correct the delivery date in this situation and was successfully corrected by system developers.



Thus, testing at different stages gave different results and at one stage helped to identify those errors that could not be found at the other.