QA-инженер (первый тестировщик в продукт)

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

Важно • Работа полностью удалённая • Исключительно на фултайм. Без совмещений в рабочее время (личные дела, личные проекты, фриланс, подработка, обучение и т.д.) • Агентствам и фрилансерам — просьба не откликаться О проекте Наш проект — стартап «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 — рабочий инструмент команды, не запрет и не «костыль»

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