Quality engineer / Тестировщик с опытом ЕСКД

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

Quality engineer / Тестировщик с опытом ЕСКД «Типбокс» — программа для технолога на Windows. Технолог загружает чертёж детали в PDF, программа разбирает его прямо на этом компьютере и строит данные детали, 3D и STEP. Дальше деталь уходит на расчёт обработки, а назад приходят станок, инструмент, установы, операции, техкарта, G-code и стоимость. Рядом работают веб-админка и сервер расчёта: учётки, стоимость, очередь заданий. Если слабое место доезжает до цеха, это дорого. Нам нужен человек, которому не всё равно, что именно доедет. Мы ищем инженера по качеству, который одновременно работает как аналитик: разбирает входящую задачу, формулирует требование так, чтобы по нему можно было и сделать, и принять, ставит задачу разработчику и сам принимает результат. Уровень — middle+ или senior. Лучше у нас получается через поиск слабых мест: человек пытается сломать программу, заходит с непривычной стороны и находит баги раньше заказчика. От интерфейса ждём прямую критику — лишний шаг, непонятная подпись, кнопка, после которой страшно нажимать, экран, на котором технолог теряется. О находках говорит прямо и полностью: смягчать формулировку, чтобы никого не задеть, не нужно. При этом умеет дослушать разработчика, технолога или заказчика и превратить замечание в проверку или в задачу. 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 на уровне ветки и разбора упавшего прогона.
• Усилит отклик уже собранные наборы проверок по сложности, приёмка установщика Windows, нагрузка очередей и долгих заданий, знание STEP, DXF, квалитетов и полей допуска.
• Как устроена работа
• Объект проверки — клиент «Типбокс», веб-админка и сервер расчёта. Сложные листы важнее толстой пачки одинаковых: корзины ранжируем по сложности и пополняем с реальных производств. Автотест закрепляет уже понятый дефект или обязательный сценарий. Дефект без шагов и ожидания в работу не берём; замечание по интерфейсу без примера экрана тоже. Задача разработчику без условия приёмки тоже. Пилот — одно рабочее место заказчика; нагрузку считаем для него и отдельно говорим, что будет при нескольких одновременных расчётах.

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