QA-инженер (middle+)

Важно

• Работа полностью удалённая
• Исключительно на фултайм. Без совмещений в рабочее время (личные дела, личные проекты, фриланс, подработка, обучение и т.д.)
• Агентствам и фрилансерам — просьба не откликаться

О проекте

Наш проект — стартап «MiOON», базируется на Пхукете (Таиланд). Занимаемся разработкой собственного продукта — агрегатор (сдам / продам) коммерческой недвижимости, готовый бизнес, земельные участки, виллы.

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

Сразу уточним важный момент: это не короткий проект и не роль «только на MVP». Мы ищем человека в долгую — после запуска нужно будет дальше развивать процессы качества, расширять автотесты и удерживать стабильность продукта по мере роста.

Что у нас сейчас

• Проект на стадии подготовки к MVP
• До этой позиции качество держалось гибридно: разработчики прогоняли smoke на своих фичах, CTO ловил UX-проблемы при ревью
• Сейчас открывается первая выделенная QA-позиция — вы строите процесс с нуля
• Базовая инфраструктура автотестов заложена (pytest на backend, Vitest на frontend, Playwright для e2e — структура есть, наполнение минимальное)
• AI/LLM-инструменты — встроенная часть рабочего процесса команды, не «эксперимент»

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

Тестовая стратегия и процессы - Построить тестовую стратегию релиза с нуля: что покрываем regression, что smoke на каждый релиз, что exploratory - Завести bug-report template и шкалу severity, синхронизировать команду по процессу - Выбрать систему тест-менеджмента (TestRail / Allure / Notion / собственное решение — на ваше усмотрение) - Вести регрессионный лист и поддерживать его актуальным

Ручное и exploratory тестирование - Проходить ключевые пользовательские флоу на staging перед каждым релизом - Тестировать новые фичи на основе ТЗ и обсуждений с продуктом - Проводить exploratory-сессии для поиска нестандартных багов - Тестировать мультиязычный интерфейс (три языка) и mobile-first-адаптив

Автоматизация - Закладывать базу e2e-автотестов на Playwright: критический путь (регистрация → создание объявления → модерация → публикация) обязателен - Писать API-тесты для проверки backend-эндпоинтов - Интегрировать автотесты в CI на GitHub Actions - Бороться с flaky-тестами и поддерживать стабильность набора

Релизы и инциденты - Координировать regression-тестирование релиз-кандидата - Совместно с CTO принимать go / no-go-решение перед релизом - Делать post-release smoke в production - Разбирать продакшен-инциденты в части QA: что должно было быть поймано в тестировании, что добавить в регрессию

Командная работа - Участвовать в ревью спецификаций новых фич и задавать вопрос «как это тестируется?» - Работать в связке с разработчиками как партнёр, а не как контролёр - Объяснять баги конструктивно, доводить до исправления

Работа с AI/LLM-инструментами - Использовать AI-ассистентов (Claude, Cursor, GitHub Copilot и аналоги) для генерации тест-кейсов, edge-кейсов, тестовых данных, Playwright-скриптов - Применять LLM для bug triage и анализа Sentry-логов - Грамотно валидировать AI-сгенерированные тесты — что они реально проверяют, а не имитируют - Видеть, где AI экономит часы, а где даёт мусор (особенно в exploratory и в работе с edge-кейсами)

Наш стек

• Backend: Python / FastAPI / PostgreSQL
• Frontend: Next.js / React / TypeScript / Tailwind / shadcn/ui
• Тесты: Playwright (e2e), pytest (BE), Vitest (FE)
• CI: GitHub Actions
• Observability: Sentry, PostHog, structured logs
• AI/LLM-инструменты в рабочем процессе (Claude, Cursor, GitHub Copilot и др.)

Что важно уметь

• Уверенно строить тестовую стратегию для продукта с нуля
• Иметь реальный опыт с Playwright, Cypress или Selenium — не «открыл туториал», а писали, поддерживали, ловили flaky
• Уметь тестировать REST API (Postman / Insomnia / curl / собственный скрипт) с пониманием статусов, заголовков, граничных случаев
• Базовое программирование на JavaScript / TypeScript или Python — достаточно, чтобы читать код разработчиков и писать e2e
• Опыт работы с SQL на уровне выборки данных для верификации
• Уметь читать pipeline CI / CD и понимать, где что запускается
• Понимать HTTP, REST, статус-коды, заголовки в контексте отладки
• Активно использовать AI/LLM-инструменты и понимать их сильные и слабые стороны в QA-работе
• Уметь аргументированно сказать «не выпускаем» и не сломаться под давлением срока

Будет плюсом

• Опыт в marketplace / classified / каталогах / агрегаторах
• Опыт работы в маленькой продуктовой команде или стартапе
• Опыт тестирования мультиязычных интерфейсов
• Опыт нагрузочного тестирования (k6, JMeter, Locust)
• Опыт security-тестирования (OWASP Top 10, базовые vulnerability scans)
• Опыт accessibility-тестирования (axe, Lighthouse a11y)
• Опыт визуального регрессионного тестирования (Percy, Chromatic, Playwright screenshots)
• Опыт работы с PostHog, Sentry, Datadog для observability-стороны QA
• Опыт с тестированием платёжных интеграций
• Свой устоявшийся рабочий процесс с AI-ассистентами в QA, которым готовы поделиться с командой
• Знание английского для чтения технической документации

В сопроводительном письме

Достаточно очень короткого письма. Обязательно укажите в самом начале:

QA MiOON Phuket

И в 1–2 предложениях — что в вакансии вас зацепило. Приложите ссылки на портфолио / GitHub / примеры bug-репортов, если есть.

Как будет строиться работа

• Задачи ставятся напрямую внутри продуктовой команды
• Много прямой коммуникации, мало лишней бюрократии
• Важна самостоятельность: вы единственный QA в команде, нужно не только тестировать, но и видеть проблему целиком
• Работа в связке с CTO, backend и frontend-разработчиками
• AI/LLM — рабочий инструмент команды, не запрет и не «костыль»

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

• Полностью удалённую работу
• Прямое влияние на качество продукта на ранней стадии
• Понятный стек без экзотики
• Выплаты 2 раза в месяц
• Возможность вырасти в lead-QA по мере расширения команды

Кого мы точно не ждём

• Тех, кто умеет только прокликивать тест-кейсы в TestRail
• Тех, кто «не пишет код вообще» — здесь придётся писать e2e
• Тех, кто считает «нашёл баги — работа окончена», а не доводит до исправления
• Тех, кто совмещает несколько работ или проектов
• Тех, кто принципиально отвергает AI/LLM в работе