Инженер по качеству (QA)

Что предстоит делать

О продукте «Технолог.ИИ» стоит у технолога на Windows.Он загружает чертёж детали в PDF,программа разбирает его на этом компьютере и строит данные детали,3D и STEP.Дальше деталь уходит на расчёт обработки.Назад приходят станок,инструмент,установы,операции,техкарта,G-code и стоимость. Рядом работают веб-админка и сервер расчёта.Админка ведёт учётки,стоимость и очередь заданий. Слабое место,которое доехало до цеха,стоит дорого.Нам нужен человек,которому не всё равно,что именно доедет. Кого ищем Инженера по качеству,которому интересен сам продукт и который хочет сделать его лучше. Лучше у нас получается через поиск слабых мест.Нужен человек,который пытается сломать программу,заходит в неё с непривычной стороны и находит баги раньше заказчика.От интерфейса ждём максимум прямой критики: лишний шаг,непонятная подпись,кнопка,после которой страшно нажимать,экран,на котором технолог теряется. О находках говорит прямо и полностью.Как видит приложение и пользовательский опыт,так и выкладывает команде.Смягчать формулировку,чтобы никого не задеть,не нужно.Команда ждёт неприятный и точный разбор. При этом он умеет слушать.Замечание разработчика,технолога или заказчика дослушивает до конца и превращает в проверку. Уровень — middle+ или senior в тестировании.Чертежи машиностроения сильно усиливают кандидата.Без них на старте тоже рассматриваем: в чертежи всё равно придётся вникать,и это часть работы,а не факультатив. Как пользоваться Cursor и Claude Это основной рабочий инструмент,наравне с самим продуктом. Нужен человек,который уже работает в Cursor и с Claude и умеет ставить им точный вопрос: что проверить,какой случай собрать,какой документ или черновик задачи подготовить,где модель,скорее всего,ошиблась.Правильный вопрос получается из своего опыта.Человек без экспертизы в тестировании получает от модели уверенный и пустой ответ.Нам нужен тот,кто ответ проверяет и отбрасывает. Через Cursor и Claude он быстро разбирает входящую задачу,готовит документы,собирает черновик проверки и снимает с себя ручную писанину.Решение,что является дефектом,остаётся за ним. Сюда же входит ловля следов черновой работы с ИИ в самом продукте.Лишняя кнопка,которой никто не просил.В боевой базе учётки вроде admin,test и случайного имени.Режим или флаг,который появился сам по себе и который страшно включать.Такие вещи нужно называть команде в лоб,пока они не доехали до заказчика.

• Ломать клиент
• Проходить путь технолога и рядом с ним искать,где путь разваливается: отмена в середине,повтор после ошибки,обрыв связи во время расчёта,чужой файл,узкое окно,тёмная тема,повреждённые настройки,второй запуск подряд.
• Критиковать интерфейс письменно: что на экране мешает,что называется не так,какое действие лишнее,где человек не понимает,что произошло.
• Принимать установщик на чистой Windows: установка,первый запуск,обновление,удаление,один живой расчёт.
• Проверять 3D и 2D DXF: модель живая и про деталь с чертежа,контуры на плоскости эскиза в миллиметрах.
• Бить по трём алгоритмам
• Отдельная цель роли — чтобы конкретное «горячо» получили три части продукта:
• распознавание чертежа;
• построение 3D-модели;
• назначение обработки: станок,инструмент,установы,операции.
• Для этого человек собирает сложные производственные случаи и раскладывает их в корзины проверки по сложности: обычный лист,неприятный,редкий и злой.Корзина живёт в репозитории вместе с ожидаемым результатом.
• Приоритет такой.Сложные случаи на производстве встречаются примерно в одном из десяти листов.Если программа выдерживает их,обычная ежедневная масса закрывается вместе с ними.Оговорка,которую держим в голове: цеха разные.Где-то почти вся партия состоит из непохожих друг на друга деталей,и победа сидит в мелких отличиях оформления,а не в одном «среднем» чертеже.
• Знание ЕСКД,размеров,допусков,посадок,резьб,фасок и шероховатости сильно ускоряет эту работу.Пока его нет,сложные листы разбираем вместе с командой,а кандидат наращивает чтение чертежа на этих же корзинах.
• После обновления алгоритмов сверяет продукт с исследовательским контуром на тех же листах.Расхождение оформляет как дефекр: лист,ожидание,факт.
• По партии фиксирует цифры: сколько листов дошло до STEP,сколько расчётов вернулось с внятной обработкой,где расхождение с эталоном.
• Веб и сервер расчёта
• Проверять админку теми же глазами: вход,учётки,стоимость,очередь заданий.В том числе мусор,который не должен жить в боевой базе.
• Проверять ответ расчёта целиком и его отказы: сервер недоступен,ключ не принят,задание с ошибкой,нет техкарты или G-code,связь пропала в ожидании.
• Следить,чтобы стоимость в клиенте и в админке была одной и той же.
• Автотесты
• Закреплять автотестом на Python и pytest тот сценарий,который уже стабильно ломается или уже стабильно обязан проходить.
• Покрывать клиент,контракт результата и сравнение листа с эталоном.
• Отделять быстрый прогон от проверок,которым нужна сеть или внешнее распознавание текста.
• Разбирать красный прогон: дефект продукта,устаревший эталон или дрожащий тест.
• Держать смоук веба.
• Нагрузка
• Гонять очередь расчёта: несколько заданий сразу,время до ответа,обрыв,повторная отправка.
• Замерять анализ на компьютере,похожем на цеховой: время этапов,память,крупный лист.
• Смотреть веб при нескольких сессиях.
• Фиксировать,что делает программа,когда внешний сервис распознавания текста упирается в лимит.
• Писать вывод порогом: при какой нагрузке пилот на одном рабочем месте ещё годен и где он кончается.
• Требования,задачи и рутина инженера
• Писать ТЗ так,чтобы по нему можно было и сделать,и принять: экран,действие,условие,что видит человек,чем кончается ошибка.
• Ставить задачу разработчику с листом,шагами,ожиданием,фактом и кодом прогона из журнала.
• Снимать короткие видео дефекта и сценария,когда словами легко разойтись.
• Готовить сопроводительные документы к проверке и к выдаче версии.
• Входящую задачу разбирать быстро: сам формулирует вопрос к Cursor или Claude,проверяет черновик и доводит до вида,с которым уже можно работать.
• Новое действие в программе сопровождается пунктом пользовательской логики и проверкой.Термины берём из словаря продукта: чертёж,деталь,анализ,расчёт,задание,сервер расчёта,техкарта,G-code,настройки установки.
• Релиз и поддержка
• Перед выдачей версии заказчику проходить короткий контур: быстрые тесты,смоук,корзины чертежей без регрессии,сборка,установщик,чистая Windows,один живой расчёт.
• Разносить дефект по месту: окно,распознавание,построение модели,назначение обработки,сервер расчёта,веб.
• Из обращения поддержки собирать воспроизводимый случай.
• Алгоритмы распознавания,построение модели и CAM-ядро пишут разработчики.Инженер по качеству приносит случаи,на которых этим алгоритмам плохо,и не даёт слабому месту остаться «на потом».
• Ожидаем
• Опыт тестирования от трёх лет.В работе уже был десктоп на Windows или промышленное ПО.
• Привычку ломать сценарий,а не только подтверждать счастливый путь,и писать это так,чтобы разработчик повторил дефект без созвона.
• Прямой письменный русский: короткие замечания по продукту и интерфейсу,без обтекаемых формулировок.
• Умение дослушать собеседника и переформулировать его боль в проверку.
• Рабочий опыт с Cursor и Claude: свои задачи,свои вопросы,проверка ответа модели.На собеседовании это смотрим на живом примере.
• Python и pytest: чужой набор тестов читаете и дополняете.
• Веб: формы,роли,ошибки API,смоук в Playwright или аналоге.
• Хотя бы один нагрузочный прогон с отчётом: инструмент,профиль,порог,вывод.
• Git на уровне ветки и разбора упавшего прогона.
• Сильно усилит отклик
• Чтение машиностроительного чертежа и готовность самому собирать сложные производственные случаи.
• Опыт ОТК,технолога,CAM,метрологии или внедрения САПР.
• STEP,DXF,квалитеты и поля допуска.
• Уже собранные наборы проверок,разложенные по сложности.
• Приёмка установщика Windows.
• Нагрузка очередей и долгих заданий.
• Как устроена работа
• Объект проверки — клиент «Технолог.ИИ»,веб-админка и сервер расчёта.
• Сложные листы важнее толстой пачки одинаковых.Корзины ранжируем по сложности и пополняем с реальных производств,помня,что у каждого цеха свои мелочи.
• Автотест закрепляет уже понятый дефект или уже понятный обязательный сценарий.
• Дефект без шагов и ожидания в работу не берём.Замечание по интерфейсу без примера экрана тоже.
• Пилот — одно рабочее место заказчика.Нагрузку считаем для него и отдельно говорим,что будет при нескольких одновременных расчётах.

Что предлагаем