Сканер на складе: считанный код ещё не учтённый товар

Сотрудник сканирует товар и слышит сигнал устройства. В программе количество не изменилось: код попал в строку комментария, окно поиска ещё загружалось или операция не сохранилась. Возможна обратная ошибка — товар учтён дважды после повторной отправки. Для приёмки складской системы нужно проверять весь путь от ввода до подтверждённого изменения документа, а не только способность прочитать этикетку.

Ниже предложена модель испытаний собственной программы. Она не устанавливает универсальные настройки всех сканеров и не описывает обязательные правила маркировки товаров. Используются вымышленные коды и тестовые документы. Проверки не должны изменять настоящие остатки склада или запускать внешние учётные операции без предусмотренного тестового процесса.

Сначала определите, как устройство передаёт данные

Сканер может быть подключён к программе разными предусмотренными способами. Не выбирайте обработчик только по внешнему виду устройства. Например, документация Zebra описывает Keystroke Output в DataWedge как передачу данных последовательностью нажатий клавиш и отдельно рассматривает специальные символы TAB и ENTER. Это конкретный документированный способ интеграции, а не утверждение, что любое оборудование работает одинаково.

Для технического задания запишите модель устройства, подключение, профиль и ожидаемый формат ввода. Уточните, передаётся ли специальный признак окончания и что приложение с ним делает. Одному процессу нужен поиск позиции, другому — добавление количества в текущий документ. Даже одинаковая строка символов может требовать разных действий в разных режимах программы.

Не начинайте с просьбы увеличить скорость передачи. Если код попадает не туда, причина может находиться в выборе активного поля или обработке завершения. Сначала получите воспроизводимый пример на тестовом документе. Затем меняют одну согласованную настройку и сравнивают результат, сохраняя возможность вернуть прежний профиль. Универсальное значение задержки здесь не предлагается.

Три события должны быть различимы

Первое событие — программа получила ввод. Второе — найдено соответствие коду в принятом справочнике. Третье — подтверждена предусмотренная операция документа. Между ними могут быть ожидание, ошибка или необходимость выбора. Один общий зелёный значок «успешно» скрывает, на каком этапе возникла проблема.

В учебном режиме приёмки код Т001 соответствует тестовому товару, но количество увеличивается только после подтверждения операции в документе Д1. Показ найденного названия не означает, что количество уже изменено. Если система обрабатывает ввод автоматически, это условие всё равно должно быть видно в результате: пользователь понимает, что произошло с конкретной строкой.

Звуковой сигнал оборудования не следует использовать как единственное доказательство сохранения. Программа может показать собственное подтверждение с названием, количеством и состоянием действия. Способ обратной связи согласуют с рабочим местом и возможностями пользователей. Для приёмки важен проверяемый смысл, а не обязательный звук или цвет для любого интерфейса.

Поле ввода является частью рабочего контекста

Для клавиатурного способа передачи проверьте состояние активного ввода перед сканированием. Если сотрудник только что редактировал комментарий, открыл поиск или закрыл окно, ввод может обрабатываться иначе, чем при первом запуске программы. Нужен явный рабочий режим, в котором понятно, куда попадёт следующий код и какое действие за ним последует.

Не решайте проблему бесконтрольным перехватом каждой клавиши на всей странице. В программе могут быть обычные текстовые поля, где человек вводит примечание или исправляет значение вручную. Согласуйте границы сканирования и переход между режимами. При выходе из режима интерфейс должен перестать обещать автоматическое добавление, даже если устройство продолжает передавать символы.

Включите в испытание открытие и закрытие предусмотренных окон, переход в другое поле и возврат к документу. После каждого перехода проверьте следующий тестовый ввод. Это самостоятельный маршрут рабочего места: демонстрация одного удачного скана на пустом экране его не покрывает. Если активный документ не определён, безопаснее запросить выбор, чем незаметно использовать ранее открытый.

Определите границу одного сканирования

Программе нужно понимать, когда получена полная строка, а не начало следующего ввода. Используемый механизм зависит от устройства и режима подключения. В задании достаточно описать ожидаемые сообщения, окончание и реакцию на неполный ввод. Не подставляйте один короткий таймаут как универсальное доказательство, что последовательность закончилась.

Проверьте пустой ввод, неизвестный код, неполную строку и два тестовых кода подряд. Неизвестная позиция не должна автоматически создавать новый товар, если такого процесса нет. Если код соответствует нескольким допустимым записям, нужен предусмотренный выбор или замечание. Правило «возьмём первую строку поиска» не подтверждает нужную номенклатуру.

Код храните в согласованном строковом формате. Ведущий ноль, разделитель или служебная часть не должны пропадать из-за случайного преобразования в число. Это не запрет любых документированных преобразований: если интеграция их требует, сохраняется понятное правило. В тестовом наборе должны присутствовать именно такие случаи, а не только простые короткие номера.

Повтор кода и повтор запроса не равны

Предположим, для одного вида тестового товара две одинаковые единицы имеют один код Т001. Сотрудник сканирует обе по принятому поштучному процессу. Два завершённых самостоятельных действия должны дать количество два. Если программа удаляет любой повтор одинакового кода за короткий промежуток, она может потерять вторую настоящую единицу.

Теперь другой случай: одно действие создало запрос, подтверждение задержалось, и программа повторила передачу этой же операции. Это не второе сканирование товара. При правильно согласованной повторной обработке количество не должно увеличиться ещё раз. Различать нужно самостоятельные действия и повтор одного действия, а не только сравнивать текст кода.

У последовательности Т001, Т001, Т002 по условию три самостоятельных поштучных действия. Если последний сетевой запрос повторился дважды, ожидаемый итог остаётся: две единицы первого товара и одна второго. Количество полученных сетевых сообщений не равно количеству поступивших товаров. Отдельный разбор повторного запроса после обрыва помогает поставить эту часть проверки.

Прибавление и замена количества различаются

В документе уже могут находиться две единицы товара. Если следующий скан означает ещё одну единицу, ожидаемое количество — три. Если экран предназначен для ввода нового итогового количества, значение имеет другой смысл. В интерфейсе нужно различать эти режимы, иначе одно и то же подтверждение случайно заменит накопленное число вместо прибавления.

Проверьте действие не только на пустой строке, но и на существующей позиции. Заранее укажите, создаётся ли новая строка или меняется имеющаяся, и как результат показывается сотруднику. Это позволяет обнаружить ошибку, которую успешное добавление первого товара не выявляет.

Смена документа не должна менять прошлое действие

Сотрудник отсканировал позицию в Д1, а затем открыл Д2 до получения ответа. У исходного действия должен сохраняться его контекст. Позднее подтверждение не должно добавлять товар в Д2 только потому, что сейчас открыт именно он. Отдельно согласуйте, где пользователь увидит результат операции предыдущего документа и как поймёт, что произошло.

При изменении режима также нужен определённый момент применения. Ввод, начатый как поиск, не должен завершиться как списание из-за переключения экрана между символами. Для конкретного подключения команда выбирает подходящую границу и испытывает её. Глобальная переменная «текущий документ» сама по себе не объясняет судьбу уже начавшейся обработки.

В журнале теста полезно сохранять идентификатор действия, документ и результат. Настоящие закрытые данные для этого не нужны. По такой записи проще отличить потерянный ввод, ошибочное соответствие товара и неверный контекст операции. Это три разные задачи, даже если сотрудник описывает все одним сообщением «сканер работает неправильно».

Как принять первую рабочую версию

Подготовьте несколько известных тестовых кодов, неизвестный код, строку с ведущим нулём и два документа. Проверьте одиночное действие, два одинаковых самостоятельных скана, задержку подтверждения и повтор одной операции. Затем добавьте переключение документа, редактирование комментария и закрытие вспомогательного окна. Для каждого сценария заранее определите ожидаемое количество и место изменения.

Попросите показать расхождения явно. Система не должна молча пропускать ввод или рисовать успех до получения принятого результата. Если нет связи, предусмотренное состояние должно объяснять, что сохранено, что ожидает обработки и какие действия разрешены. Автономная работа требует отдельного проекта; её нельзя обещать только потому, что текст кода виден без сети.

После проверки запишите поддерживаемые подключения и границы первого выпуска. Рабочий результат — это известный код, применённый к правильному документу ровно по согласованному действию. На таком основании можно расширять интеграцию оборудования, не путая успешное считывание этикетки с подтверждённым складским учётом.