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