Мы развиваем B2B CRM/ERP-платформу для металлообработки: заявки и сделки, договоры, контроль оплат, документооборот, логистика и интеграции с внешними системами.
Платформа состоит примерно из 30 микросервисов и работает в production. Основной стек — Java 17, Spring Boot, Kafka, PostgreSQL, MongoDB.
Сейчас мы усиливаем QA-команду. Процессы тестирования уже выстроены, и мы ищем инженера, которому интересно не просто проходить чек-листы, а понимать бизнес-логику продукта и устройство системы, самостоятельно определять, что и как проверять, и отвечать за качество релиза.
Что предстоит делать
- Тестировать новую функциональность и изменения в существующих сервисах платформы.
- Проверять сквозные бизнес-сценарии, проходящие через несколько микросервисов.
- Тестировать REST API напрямую — Postman, Swagger, без UI.
- Проверять состояние данных в PostgreSQL и MongoDB после выполнения операций.
- Разбирать асинхронные сценарии: сообщения в Kafka, интеграции с внешними системами, отложенные и фоновые процессы.
- Локализовать дефекты по логам и Sentry, доводить баг-репорт до воспроизводимого и однозначного.
- Писать и поддерживать тест-документацию: тест-кейсы, чек-листы, тест-планы, регрессионную модель.
- Участвовать в приёмке требований до начала разработки и подсвечивать проблемы в постановке.
- Участвовать в регрессе и приёмке релизов.
Какой тестировщик нам нужен
Нам нужен самостоятельный инженер, который разбирается в том, как устроена система, а не только в том, какие кнопки нажимать. Который по описанию задачи может сам определить зону влияния изменений, придумать сценарии за пределами happy path и объяснить, почему именно их важно проверить.
Мы ожидаем внимания к данным: в ERP цена ошибки — это не «поехала вёрстка», а неверная сумма в договоре, потерянная отгрузка или рассинхронизация между сервисами. Поэтому важно уметь проверять результат по данным и по логам, а не только по экрану.
Для нас важна коммуникация. Хороший баг-репорт экономит часы разработчику: воспроизведение, ожидаемое и фактическое поведение, окружение, логи, оценка влияния. Вопрос к аналитику до начала разработки экономит ещё больше.
Проще говоря, нам нужен человек, который отвечает не за количество найденных багов, а за то, что мы понимаем реальное состояние качества продукта перед релизом.
Инструменты и окружение
- Тестирование API: Postman, Swagger / OpenAPI
- Базы данных: PostgreSQL, MongoDB, SQL-запросы для проверки данных
- Брокер сообщений: Apache Kafka
- Логи и мониторинг: Sentry, Actuator, Prometheus, Kibana
- Тест-менеджмент и трекинг: тест-кейсы и чек-листы, задачи и баги в трекере
- Инфраструктура: Docker, GitLab CI, feature toggles, тестовые стенды
- Авторизация: Keycloak, OAuth2 / JWT
Ожидаем готовности самостоятельно разбираться с новыми инструментами и компонентами системы по мере необходимости.
Что ожидаем
Обязательно
- Коммерческий опыт ручного функционального тестирования веб-приложений.
- Уверенное тестирование REST API без UI: Postman, Swagger, работа с JSON, кодами ответов, авторизацией.
- Уверенный SQL: выборки, join'ы, проверка целостности данных.
- Понимание микросервисной архитектуры и асинхронного взаимодействия между сервисами.
- Умение работать с логами и самостоятельно локализовать дефект.
- Опыт написания тест-документации и поддержки регрессионной модели.
- Опыт тестирования сложной бизнес-логики — CRM, ERP, биллинг, учётные или финансовые системы.
- Умение работать с требованиями: задавать вопросы, находить противоречия и пробелы до релиза.
- Готовность использовать AI-инструменты в работе.
Будет плюсом
- Опыт работы с Kafka или другим брокером сообщений.
- MongoDB.
- Базовая автоматизация: API-тесты, скрипты для подготовки данных.
- Опыт нагрузочного тестирования.
- Понимание BPMN и процессных систем.
AI в работе
Мы используем Claude Code и Codex как часть обычного инженерного процесса, в том числе в тестировании.
Приветствуем использование AI для генерации тестовых данных, разбора логов, подготовки черновиков тест-кейсов и ускорения рутинных проверок.
При этом для нас принципиально важно качество результата:
- AI может предложить набор сценариев, но инженер должен понимать, что именно и зачем проверяется.
- Сгенерированные тест-кейсы проходят такую же проверку, как написанные вручную.
- Баг-репорт должен быть воспроизводимым и проверенным человеком.
- AI не заменяет понимание продукта и ответственность за качество релиза.
Мы за ускорение работы с помощью AI, а не за ускоренную генерацию бесполезных артефактов.
Что предлагаем
- Полностью удалённая работа.
- Оформление по договору с ИП или в штат — как удобнее вам.
- Без регулярных переработок.
- Возможность влиять на процессы тестирования и качество продукта, а не только закрывать задачи по чек-листу.
Как проходит отбор
- Знакомство — около 30 минут
Познакомимся, расскажем о продукте и команде, обсудим ваш опыт и ожидания. - Техническая секция — около 1–1,5 часа
Обсуждаем подходы к тестированию, работу с API и данными, разбираем практические кейсы. - Финальная встреча
Обсуждаем взаимные ожидания и условия сотрудничества.
Стараемся завершить весь процесс за 1–2 недели.