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