QA инженер

Туту  — сервис путешествий, где можно купить билеты на поезда, самолёты и автобусы, посмотреть расписание пригородных поездов, найти туристические путёвки, забронировать отели и экскурсии, почитать отзывы на вагоны и самолёты, посмотреть, где там розетки и пеленальные столики, увидеть фото и пропасть на полжизни.

В команде ж/д мы делаем лидирующий сервис онлайн-продаж билетов на поезда, помогаем людям путешествовать на поездах удобнее и проще.

Наш продукт появился на заре онлайн-сервисов, с тех пор мы активно развиваемся. У продукта 400 тысяч посетителей в сутки, рост показателей идёт со скоростью стартапа, несмотря на 15 лет существования. У нас можно не только посмотреть расписание и купить билеты, но и узнать больше о поездах из отзывов наших покупателей, получить подсказки и рекомендации самых удобных мест, автоматически выкупить билеты, когда они появляются в продаже, и решить множество других задач.

Мы ищем QA-инженера, который будет заниматься решением задач команды с высоким качеством и в установленные сроки, участвовать в развитии и поддержке сервисов ассортимента и допуслуг для клиентов, прорабатывать решения, ориентированные на долгосрочные перспективы и создавать общие инструменты и компоненты, полезные для всей компании.

‍

Немного про стек

Тесты: Go testify (GoLang), Allure TestOps, Codeception (PHP).

Монолит: PHP, MariaDB, React.

Сервисы:

— Backend: GoLang/PHP, MongoDB, Openshif.

‍

Основные задачи

— Работа с ключевыми целями продукта: участие в разработке решений, направленных на достижение целей команды и бизнеса. Анализ проблем и внедрение улучшений для повышения качества продукта.

— Автоматизация тестирования: написание и поддержка автотестов (80% автоматизация, 20% ручное тестирование). Формирование схемы тестового покрытия в соответствии с пирамидой тестирования. Развитие фреймворков автоматизации тестирования. Интеграция автотестов в CI/CD пайплайны. Настройка и подключение отчётов к тестам.

— Тестовая инфраструктура: постоянное улучшение инструментов и подходов к тестированию. Поддержка стабильности тестовой среды. Автоматизация ручных процессов тестирования для повышения эффективности команды.

— Обеспечение качества в SCRUM-команде: проведение коучинга разработчиков в области обеспечения качества. Участие в обсуждении и формировании требований с точки зрения тестирования. Участие в релизных циклах: анализ результатов автотестов, выявление и подсвечивание проблем команде, апрув релиза.

— Документация: составление, поддержка и актуализация документации по качеству продукта. Разработка и ведение тест-кейсов.

— Оптимизация процессов и DevOps: участие в решении задач, связанных с доставкой кода (release management). Использование и развитие DevOps-подходов для улучшения процессов поставки. Оптимизация TTM (Time to Market) через улучшение процессов и инструментов команды.

— Анализ и развитие: выявление слабых мест в продукте, процессах и тестовой инфраструктуре. Разработка и внедрение решений для устранения проблем. Постоянное развитие компетенций в области автоматизации тестирования и QA в целом.

‍

От вас нужно

— Опыт работы в роли QA от 3 лет.

— Знание методов и методик тестирования, принципов распределения покрытия тестами согласно пирамиде.

— Понимание процессов тестирования и разработки.

— Опыт тестирования web-приложений (UI / Backend / API).

— Опыт разработки автотестов на уровне e2e (acceptance) и integration с использованием GoLang/PHP более 1 года.

— Умение разбираться в чужом коде.

— Опыт работы с системой контроля версий (GIT) и командной строкой Linux.

— Опыт работы c инструментами взаимодействия с API сервисов (Postman / Paw).

‍

Про команду и рабочий процесс

В целом в ж/д направлении есть:

Product Owner (PO); Product Manager (PM); Techlead (TL); Dev Team: 8 — Backend; 3 — Frontend; 2 — iOS; 2 — Android; 4 — QA (автоматизаторы), а также подключаемые роли продуктового, системного аналитика, исследователя и дизайнера.

‍

В целевой подкоманде:

3 — Backend; 1 — QA.

‍

Работаем по двухнедельным спринтам.

Есть ежедневный утренний стендап команды ж/д (30 минут).

Раз в спринт:

— Sprint planning (4 часа).

— PBR — обсуждение/прояснение задач (2-4 часа).

— Sprint review (1 час).

—Retro (1 час).

‍

Кто ставит задачи

Задачи формирует Product Owner (PO) на этапе планирования спринта.

‍

Как это происходит

Обсуждение приоритетов: PO рассказывает о целях, которых хочется достичь в продукте, с учётом ожидаемого влияния на продуктовые метрики.

‍

Оценка задач: команда анализирует приоритетные пользовательские истории, обсуждает технические детали и при необходимости декомпозирует задачи на более мелкие.

Формирование цели спринта

‍

В ходе диалога между командой и PO определяется цель спринта.

Цель становится ориентиром для команды и описывает результат, который должен быть достигнут к завершению спринта.

‍
График работы

Есть полная удалёнка, работа из офиса или посещение офиса когда захочется. Это как вам удобнее.