Знакомим с командой обеспечения качества

За каждым багом, который не дошёл до зрителя, и каждой фичей, которая запустилась без боли, стоит целая философия качества. В новом интервью Александр Монетчиков, директор по качеству Иви, рассказал о нашем подходе: тестировщик не сидит в конце конвейера и не ловит всё, что летит мимо, а каждый в команде чувствует ответственность за то, что попадает к зрителю.

В чем заключается философия обеспечения качества в Иви и как устроена команда, которая за это отвечает?

В Иви мы рассматриваем качество не как изолированную функцию тестирования, а как неотъемлемое свойство всего процесса создания продукта. Моя команда, по сути — весь технический департамент, отвечает за всё, что позволяет онлайн-кинотеатру работать: к��иентские приложения, backend-сервисы, инфраструктуру. Конкретно моя роль — смотреть на эту систему под углом качества как конечного результата, так и процессов, которые к нему ведут. У нас около ста человек напрямую вовлечены в работу над качеством. Но наша ключевая философия в том, что за качество, в конечном счете, отвечает вся команда, а не выделенная группа тестировщиков. Глобально в компании мы работаем с полным спектром современных технологий — Go, Python, Swift, Kotlin, TypeScript, K8s, Kafka, Redis, Clickhouse и другими. Если говорить именно про тестирование, то это TestRail и Allure TestOps, Charles Proxy и Postman, Pytest, Jest и прочие. Но именно подход, а не инструменты, является нашим главным активом.

Как в проектах распределяются роли между разработчиками и QA-инженерами? 

Мы сознательно уходим от жёсткого разделения ролей. Как я и говорил, за качество отвечает вся команда. У нас множество кейсов перехода из тестировщика в разработчика, поэтому есть команды, в которых совсем нет выделенных QA-специалистов. Поэтому разработчики активно пишут тесты и тестируют свой код, а QA-инженеры могут брать на себя задачи разработки или аналитики. Вопрос распределения обязанностей решается внутри команды, исходя из логики Agile, где не бывает строго «пригвоздённых» к задаче специалистов и запросов на развитие: каждый имеет свою глубокую экспертизу, но при этом «подкачивает» смежные навыки. Это делает команды гибкими и устойчивыми. Мы поощряем такое размывание жёстких границ, потому что оно стимулирует взаимозаменяемость, повышает качество и уровень ответственности за общий результат. Конечно, это не всегда работает и не каждой команде может подойти в силу специфики, но мы все же стараемся следовать такому подходу.

С какими другими подразделениями взаимодействуете?

Взаимодействие строится по всем фронтам. Лично я постоянно работаю с бизнес-заказчиками и продукт-менеджерами, чтобы понимать стратегический контекст и доносить его до команд. В свою очередь, инженеры в командах напрямую и ежедневно общаются с продактами, дизайнерами, аналитиками и менеджерами. Это не формальность, а необходимость. Основная задача специалистов, отвечающих за качество, — задавать «неудобные» вопросы на самых ранних этапах: «Что произойдёт, если…?», «Как система должна себя вести в этом сценарии?». Раньше тестировщик был тот, кто «заходит в бар и начинает заказывать целое пиво, половину пива, ноль пива, три тысячи пива». В современном мире так нельзя, мы действуем на опережение и сдвигаем тестирование «влево»: QA подключается не в конце, а на этапе зарождения идеи или проектирования. Цель — выявить и исправить потенциальные проблемы на бумаге или в дизайне, что в разы эффективнее, чем править готовый код, и помогает нам не расстраивать и не терять подписчиков из-за багов в продакшене.

Какими своими достижениями за прошедший год гордитесь?

Их два, и они отражают разные грани нашего подхода. Первое — это оперативное достижение: в очень сжатые сроки мы создали, встроили во всю систему и запустили новый продукт — вертикальные сериалы, они же мини-драмы. Это был вызов, который доказал, что выстроенные процессы, командная работа и вовлеченность в результат позволяют быстро доставлять сложные фичи без компромиссов в качестве. Второе достижение — стратегическое. Мы создали и внедрили единую для всех команд систему объективной оценки их процессов на основе данных. Для этого была проведена подготовительная работа: мы унифицировали процессы внутри команд с точки зрения task-трекера, чтобы у всех статусы и этапы были едиными. Собрав и визуализировав в Grafana метрики из Jira и Clickhouse, мы подарили командам мощный инструмент для самоанализа и определения точек роста в их процессах. Теперь можно увидеть, где задачи «застревают»: например, если очередь на тестирование растёт из-за позднего подключения QA. Это позволяет не гадать, а на основе данных системно находить узкие места и осмысленно улучшать процессы.

Как в команде принято отмечать успехи?

Когда мы говорим про большие и крутые события, по типу запуска нового сегмента мини-драм, то это всегда вечеринки, стараемся отмечать с размахом. Но и регулярные релизы без внимания не оставляем. Например, с каждым релизом приложения на Smart TV, а он происходит раз в пару недель, руководитель клиентской разработки приносит в команду пончики. В каждой команде есть какие-то свои ритуалы празднования успехов. Это давно существует внутри культуры нашей компании, если мы что-то сделали хорошо, то нужно обязательно это отметить. Да и в целом мы не скупы на положительный фидбэк.

Как в Иви относятся к ошибкам и инцидентам? 

Мы воспринимаем инциденты как неизбежную часть развития сложной системы и, главное, как бесценный источник для улучшений. У нас действует прое��т «Инциденты», в рамках которого мы фиксируем и анализируем каждый сбой, в том числе оценивая финансовый ущерб. Ключевой принцип — это отказ от поиска «виноватого». Любой серьёзный факап — это всегда цепочка событий и решений, системный сбой в процессах, а не чья-то персональная ошибка. Например, пропажа блоков на главной странице из-за недоработки в коммуникации между командами. Разбор таких ситуаций ведётся спокойно, с целью найти коренную причину и внедрить изменение в процесс или покрытие тестами, чтобы этого не повторилось. Главный урок: качество — это ответственность всей команды и системы процессов в целом, и улучшать нужно именно систему.

Что важно для кандидата, который хочет работать над качеством в Иви?

Прежде всего — понимание связи между технической работой и бизнес-результатом. Нам нужны люди, которые видят, как их код, тест или анализ влияют на конечный опыт миллионов зрителей. Важно желание постоянно учиться и развиваться в смежных областях, то самое T-shaped мышление. Мы ценим инициативу и умение задавать вопросы. Атмосфера в Иви строится на вовлечённости и желании делать классный продукт, поэтому люди часто погружаются в задачи глубоко и по своей воле. Мы не практикуем принудительные переработки, но поощряем ответственность и увлечённость.

Как в компании поддерживают эксперименты и инициативы сотрудников?

Мы обожаем инициативу и даём командам большую свободу для экспериментов. Классный пример — группа сотрудников самостоятельно подключила большую языковую модель (LLM) к нашему хранилищу тест-кейсов, превратив его в интеллектуальную базу знаний по продукту. Теперь любой сотрудник может в чате спросить, как работает та или иная функция. Другой пример — внутренний LLM-чат с разными моделями для всех сотрудников компании, который тоже появился благодаря такой инициативе. Мы не просто разрешаем такие эксперименты — мы их поощряем, потому что именно они часто приводят к прорывным улучшениям в процессах и инструментах, двигая вперед всю компанию. Это лучший способ профессионального роста.

5 советов, как стать самой крутой командой, от Саши Монетчикова и больше о жизни сотрудников Иви — в телеграм-канале!