В статье мы расскажем о нашем опыте тестирования ритейл систем, и на примере одного внедрения расскажем, как это происходит. И так постановка задачи: Необходимо перевести существующие бизнес-процессы компании «ТК» на новую технологическую платформу «РС» — это система автоматизации розничной торговли, предназначенная для централизованного управления розничной сетью любого размера и структуры. «РС» — это «коробочный» продукт, поэтому недостаточно было просто проверить функционал системы, необходимо было провести анализ и соответствие между процессами системы магазинов «ТК» и внедряемой системой. В связи с этим тестирование было разделено на 3 этапа: FT3 Testing, POC Testing, Pilot Testing. Ниже мы остановимся на каждом этапе подробнее:
FT3 Testing
Целью данного этапа, в первую очередь, являлась проверка системы на соответствие заявленным требованиям. На основе требований была создана тестовая модель, для составления которой использовалась система «Team Foundation Server». Для проведения тестирования была подготовлена тестовая среда с необходимой и обновляемой версией ПО и всем необходимым оборудованием (компьютер, дисплей покупателя, фискальный принтер, сканер штрих-кодов, клавиатура, денежный ящик, EFT-терминал, ТСД). Для фиксирования багов также использовалась система «Team Foundation Server». В рамках составленной тестовой модели были проведены следующие виды тестирования: функциональное тестирование, тестирование исправленных дефектов и регрессионное тестирование. После выполнения всех согласованных на данном этапе тест-кейсов и регистрации всех найденных в результате багов система была готова к проведению следующего этапа — POC Testing.
POC Testing (Proof of Concept)
Данный этап был направлен на проведение активного анализа концепции работы данного магазина и специфики торговой системы «ТК» в целом, все аспекты которой необходимо было учесть при внедрении ритейл-системы. Также на данном этапе анализировались все процессы действующей системы, с целью обнаружения процессов или мелкого функционала, который необходим в работе магазина, но он отсутствует или недоработан в новой системе «РС». Тестирование системы на данном этапе проходило на территории магазина в идентичной первому этапу тестовой среде, но велось уже не в рамках тестовой модели, а в режиме дублирования (воссоздания) в новой системе всех процессов действующей системы. В целях сбора статистики в ходе процесса тестирования любые инциденты также фиксировались в системе «Team Foundation Server». В ходе данного этапа анализ показал, что критических различий между процессами внедряемой и уже существующей системой нет, и больших доработок не требуется, поэтому наступила готовность к пилотному запуску системы.
Pilot Testing
Самый важный этап, так как работа системы здесь напрямую влияет на качество обслуживания клиентов магазина. Именно поэтому организована активная поддержка сотрудников магазина различными специалистами. В ходе поддержки сотрудников магазина в процессе работы с новой системой, проводится тестирование пилотной версии продуктивной системы. Проводится оно в следующем режиме: сотрудники магазина, работая в обычном режиме с новой системой, сталкиваются с различными трудностями. Это может быть как ошибка системы, так и «неудобство» пользования. Так или иначе любая ситуация анализируется аналитиком системы и далее по необходимости тестировщиком фиксируется баг в системе «Team Foundation Server». Баги с высокими, 1 и 2 приоритетом, исправляются разработчиками в краткие сроки, проходят ретест в тестовой среде, имеющей идентичную продуктивной среде конфигурацию. Успешно ретестированные баги и пойдут в установку Hot-Fix. Менее критичные баги подлежат исправлению в обычном режиме и идут в установку регулярных билдов (версий). Помимо этого на данном этапе проводится тестирование методом свободного поиска. Найденные, в ходе данного тестирования, баги, также фиксируются в системе «Team Foundation Server».
Как и ожидалось, на каждом из этапов, в соответствии с целями тестирования, были зафиксированы различные инциденты.
Так, например, на этапе FT3 Testing тестировался функционал распаковки микс-коробов (скомплектованный короб с мелким товаром) с помощью ТСД (Терминал сбора данных – мобильное оборудование, оснащенное сканером, с помощью которого можно проводить все возможные релокации в магазине: от приемки на склад до выдачи клиенту). Было известно, что в соответствии с заявленными требованиями, запрещено выводить на ТСД сообщение об отсканированном излишке товара в микс-коробе (в целях исключения случаев краж сотрудниками) и система корректно отвечала данному требованию. Но уже на этапе POC Testing было ясно, что отсутствие данного сообщения при распаковке накладывает на процесс распаковки определенные неудобства в работе склада, а на этапе Pilot Testing и вовсе выяснилось, что отсутствие данного сообщения несет за собой последствия, серьезно влияющие на производительность работы, как склада, так и всего магазина. В результате был создан Change Request на необходимость отображения данного сообщения на экран ТСД при распаковке микс-коробов, которое успешно реализовано в данной системе.
В качестве еще одного примера, можно привести ситуацию, когда необходимо было провести заявку на доставку клиенту с удаленного склада (ситуация, когда товара в наличие в магазине нет, но он есть на одном из обособленных складов «ТК», откуда напрямую можно заказать доставку). На этапе FT3 Testing данный функционал был проверен и он корректно отрабатывал согласно требованиям. Но на этапе POC Testing высянилось, что при таком способе доставки существует ограничение по регламенту магазина: доставка может быть оформлена только на десятый день от даты заказа. Тогда, как система позволяла сделать это уже на третий день от даты заказа. Здесь срабатывал человеческий фактор, и сотрудники могли допустить ошибку при оформлении доставки клиенту, которая повлекла за собой некорректное информирование клиенту и некорректно выданные документы по доставке. В результате был создан баг на исправление даты доставки в этой ситуации и успешно исправлен разработчиками системы.
Таким образом, тестирование на разных этапах дало разные результаты и на одном этапе помогло выявить те ошибки, которые не удавалось найти на другом.
Автор: p_lab
