Заводить тест-кейсы руками в тестохранилищах — долго и скучно. Но ведь есть еще много юнит-тестов, которые пишут разработчики. И не всегда понятно, что они покрывают и как пересекаются с E2E-тестами. Head of QA в Авито, Александр Матвеев, на Test Driven Conf расскажет о том, как можно комплексно решить эти две проблемы.

А уже сегодня вы можете прочитать интервью с ним, из которого узнаете, как работают тестировщики в Авито, и какие уникальные продукты они для этого используют.

Расскажи немного о себе — чем занимаешься, в какой компании и кем работаешь?

Я работаю в IT, почти 10 лет и восемь из них в Авито. Пришел туда в качестве обычного тестировщика, потом руководил командой тестирования, в которой было более 20 человек. Участвовал в процессе создания кросс-функциональных команд. Сейчас я Head of QA.

В Авито есть продуктовые и платформенные команды. Отдел QA Center of Excellence, которым я руковожу, относится к платформенным. Мы создаем инструменты для тестирования, следим за процессами, внедряем новые технологии и процессы для того, чтобы поднять качество.

Как в Авито построено тестирование?

Из-за того, что у нас очень много команд, и у них бывает разный контекст (а мы знаем, что тестирование всегда зависит от контекста), тесты тоже построены по-разному. У нас Agile, SCRUM, и это накладывает определенные требования к процессу. 

Расскажу об основной канве. Задачи в спринт берутся с проработанными критериями приемки. От этих критериев наследуются тесты, причем не только E2E, но и все, которые распределены по пирамиде тестирования. Эти тесты автоматизируют и разработчики, и QA-инженеры. После чего, если это необходимо, происходит исследовательское приемочное тестирование. И только потом мы выкатываем результат работы на пользователей. 

У нас есть canary-деплой, при котором новую фичу видит небольшой процент пользователей. Это позволяет посмотреть на ошибки, проверить метрики. И, если все нормально, раскатать получившееся дальше. А если что-то идет не так, быстро откатить и поправить все что нужно.

Наверное, при таком количестве человек, как в вашей компании, сложно сделать что-то без сбора и анализа метрик, в том числе, метрик про тесты?

Да. Мы собираем множество различных метрик и принимаем решения на основе полученных данных. Метрики качества нужно разделить на метрики внешнего качества и метрики внутреннего качества. Последние, например, показывают процент покрытия тестами. Пользователей не особенно интересует, сколько тестов написано на фичу. Им нужно, чтобы она работала. А вот нам важно знать всё о покрытии фич тестами и о том, как эти тесты распределяются по пирамиде тестирования. Если говорить про автотесты, мы смотрим, сколько времени они проходят, какой процент тестов относится к flaky тестам и с какими ошибками падают. 

Как вы понимаете, что тестирования достаточно?

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

А дальше все завязано на экспертизе крутых QA-инженеров, которые сидят в продуктовых командах и проводят исследовательское тестирование, разбираясь, насколько качественно все работает. По согласованию с командой принимается решение, когда нужно выкатывать в прод. Это происходит в том случае, если критических багов не осталось. Кроме того, у нас тестирование «смещено вправо». И мы по canary-релизам судим о том, насколько все хорошо. 

Как распределяются тесты по уровням? Как вы визуализируете эти данные, есть ли какие-то свои продукты?

У нас есть своя собственная система хранения тест-кейсов. Там заведены тестовые модели всех команд. 

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

Кстати, о юнитах стоит поговорить отдельно. Мы называем юнитами как sociable, так и solitary тесты. Мы можем посмотреть, как выстроена пирамида тестирования и по всей огромной кодовой базе Авито, и отдельно по команде, строящей свою пирамиду, и даже по конкретной отдельной фиче. Мы отдельно выделяем блок в тестовой модели и видим, как тесты распределяются по пирамиде.

Как мы этого достигли? Про это я как раз буду рассказывать в своем докладе. Мы научились выгружать тесты из кода и линковать их на тестовую модель. У нас есть страничка с визуализацией, которая позволяет командам увидеть, как у них выстраивается пирамида. В зависимости от данных, на которые они смотрят, происходит приоритизация работы. Есть кусочки небольшого legacy, где E2E-слой довольно большой. Но из-за того, что мы уже почти перешли на микросервисы, в некоторых новых сервисах пирамида выстроена близко к идеальной, общепринятой по индустрии.

Давай поговорим о твоем докладе, раз ты затронул эту тему. Чем он важен для аудитории, чем может быть полезен?

Доклад называется «Как подружить QA и разработку через применение практики хранения тестов в коде». И он как про технологию, так и про подход. В свое время мы в Авито начали внедрять Agile-тестирование и поняли, что инструменты не дотягивают до процессов, которые мы строим. Основная проблема была в том, что QA-инженеры не знали, как покрыты нижние слои пирамиды. И писали очень много E2E-тестов. Соответственно, они были flaky, и все продвигалось очень медленно.

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

Сейчас мы умеем выгружать тесты из кода практически всех языков, на которых мы пишем. И делаем это на всех платформах: iOS, Android, бэкенд, фронтенд. На бэкенде это, например, такие языки как Golang, PHP, Python. Мы умеем находить тесты в коде со всех код-баз, превращать их в тест-кейсы, выгружать в нашу тестовую модель и показывать тестировщикам, что и где покрыто.

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

У тебя будет только теоретический доклад, или порадуешь и практическими примерами?

Я расскажу, как мы создали систему, как она работает. Поговорю об архитектуре и о том, с какими проблемами мы сталкивались, почему сделали так, а не иначе. В общем, инженерные куски будут.

Расскажи, какие метрики вы собираете по тестам и зачем? Какой в них профит для тестировщика и для бизнеса? Кто и зачем просматривает эти метрики?

Если мы говорим о QA-инженере в команде, он смотрит на свою тестовую модель, видит покрытие и понимает, куда ему нужно направить свой фокус внимания. Например, какие-то фичи покрыты плохо, мало, их нужно доделать. Или где-то очень много E2E-сценариев, соответственно, их нужно разносить. 

Кроме того, мы следить за метриками на уровне компании: как у нас проходят тесты, насколько сильно они flaky. Любой flaky-тест требует дополнительного времени инженеров, которые его перезапускают и смотрят, что с ним не так. Это влияет на Time to Market любой фичи, которую мы пытаемся выпустить в продакшен.

Как ты думаешь, зачем нужна конференция по тестированию? 

Мне кажется, что профильная конференция нужна всегда. Для того, чтобы люди встретились и поговорили, обменялись опытом, обсудили насущные проблемы. Если ты пришел послушать отдельные доклады в рамках других конференций, не всегда сможешь найти единомышленников. 

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

Знаю, что у программного Комитета конференции Test Driven Conf есть задача собрать хардкорную конференцию. Не про маркетинг или какие-то пиар-решения внутри компании. Почему важно именно это? 

Я знаю людей из Программного комитета. Им всегда было интересно собирать что-то супер передовое и интересное с точки зрения решений и инженерных подходов в сфере тестирования. Они уже давно искали докладчиков и просили их рассказать о новинках для какой-то небольшой аудитории. 

Совершенно не сомневаюсь в том, что на конференции будут полезные доклады, которые потом можно будет применить в своей работе. Потому что вдохновители этого мероприятия сфокусированы на том, что двигает индустрию тестирования вперед с технологической точки зрения. Можно залипнуть в каких-то процессных подходах, но мы идем в сторону автоматизации всего и вся, и технологии должны подкреплять наши действия.

Как ты думаешь, в чем уникальность конференции Test Driven Conf?

Я жду, что ПК приведет докладчиков из разных компаний. Людей, которые делают что-то уникальное. О таком опыте всегда интересно послушать. 

Кроме того, на конференции будет крутое комьюнити. Это очень важная часть мероприятия. Чем выше ты поднимаешься по карьерной лестнице в QA, тем важнее нетворкинг. Потому что появляются все более сложные проблемы, и нужны товарищи, с которыми можно их обсудить, придя к какому-то общему решению. Или увидеть, что кто-то уже придумал его до тебя.

Конференция об автоматизации тестирования TestDriven Conf 2022 пройдёт в Москве, 28-29 апреля 2022 года. Кроме хардкора об автоматизации и разработки в тестировании, будут и вещи, полезные в обычной работе.

Расписание уже готово, а купить билет можно здесь. С 1 декабря цены на TestDriven Conf вырастут!