Внедрили автотесты и TMS в «Азбуку вкуса». Кейс 2017 года

Заказчик

«Азбука Вкуса» — это уникальная омниканальная экосистема питания с собственными фуд-технологиями и фуд-сервисами. 173 магазина в Москве и Санкт-Петербурге.

Задача

Руководитель по тестированию со стороны «Азбуки вкуса» хотел упорядочить процесс взаимодействия (3 разные outsource-команды должны были работать как единый организм), а также ускорить тестирование.

Мы помогаем «Азбуке вкуса» развивать их цифровые продукты с 2014 года. В этом году у нас годовщина — 10 лет счастливых партнерских отношений. Мы сильно ценим партнерство с корпорацией. С Азбукой мы прошли и огонь, и воду, и всякого материала трубы. Поэтому как только выдается возможность — выражаем признательность. В этом году, например, готовим суперпрезенты на годовщину:

Демонстрация суперпрезента

Демонстрация упаковки супер-презента 

Демонстрация упакованного супер-презента

В преддверии юбилея партнерства решили вспомнить с тестировщиками, какие проекты «Азбуки вкуса» оставили след в сердце отдела. Подумали, поболтали и поняли, что для нас это было внедрение TMS и автотестов.

В статье:

• Проблема. Разные процессы, отчеты и сложный онбординг
• Задача №1: Упорядочить процесс
• Решение №1. Та самая TMS для Азбуки
• Задача №2: Даешь автотесты
• Решение №2. Первый раз использовали Gherkin
• Привет, новый флоу!

Проблема. Разные процессы, отчеты и сложный онбординг

Шел 2017 год. Цифровые продукты фудтех корпорации росли. Одной командой тестирования было не обойтись, поэтому тестировали сразу несколько. Только наша команда была задействована на более чем 10-ти проектах. Из того, что помним — активно подключались на av.ru/, экспресс-меню, vkusomania.av.ru, lms.av.ru, market.av.ru.

На сильный рост команды также повлиял переезд сайта av.ru с umi на SAP hybris. Появилась потребность в java-специалистах, поэтому образовалось сразу 2 команды тестирования. Одна занималась поддержкой старой версии сайта, другая — новой.

Еще одним поводом для роста стал запуск новых проектов. Одним из проектов была Вкусомания. На ней мы познакомились с большей частью других команд и с трудностями разрозненности.

Трудность заключалась в том, что все команды работали по разным процессам. Вот последствия:

1. Разная отчетность. Одна команда могла просто отписаться в чате, что все «сделано», вторая — делала отчет в google sheets со списком всех проверок, третья — вела отчетность в confluence. В общем, у всех все по-разному;

«Каждая задача тестировалась без подробных сценариев. Каждый ретест мог выявить баги, пропущенные в прошлый раз. Причиной всему было отсутствие общих критериев выхода из тестирования».

                                                                                                                                   Михаил Ситников, руководитель QA-направления в wpp.digital (ex- WEB++)

2. Сложный онбординг. Новых специалистов подключали каждые 3-4 месяца, и они долго входили в проект. Проектная документация была разрозненной, многое передавали просто устно.

Задача №1: Упорядочить процесс

Руководитель по тестированию со стороны «Азбуки вкуса» хотел решить проблему разрозненности и устных договоренностей. 3 разные outsource-команды должны были в конечном счете работать как единый организм. Был взят курс на внедрение TMS (*Test Management System или Система управления тестированием).

В нашей ситуации TMS давала объективную отчетность и понятный флоу. В общем, независимо от количества команд и степени погруженности в продукт тестирование должно было работать четко, как часы.

Решение №1. Та самая TMS для Азбуки

Мы заранее готовились к автоматизации, поэтому тестировали разные TMS внутри своей команды.

«Еще в самом начале сотрудничества мы внедряли в av.ru гибкие решения с перспективой на масштабирование. Помню мы тогда разрабатывали систему внедрения промокодов в ядро расчетов. Уже тогда внутри, у себя, мы начали строить базу тест-кейсов в TMS. Все участники процесса понимали: без хорошего тестирования велик шанс поломать критический коммерческий функционал».

                                                                                                                                                                     Василий Гребенников, директор wpp.digial (ex- WEB++)

Наиболее подходящей TMS для нас стала testrail.

Весной 2022 года компания Gurock, владелец TestRail, прекратила продление лицензий в России. Поэтому на данный момент клиент ее не использует.

Вот основные параметры, по которым выбрали систему:

• Широкий список интеграций. Продукты тестировались несколькими командами с разными внутренними процессами, разными методиками работы. Нам нужна была система, которая позволила бы не ломать эффективный флоу других команд. Идеальным решением было интегрировать привычные сервисы в TMS, чтобы специалисты затратили как можно меньше времени на адаптацию. Такой подход позволил бы не стопорить производство, а мягко «пересадить» специалистов в TMS;

• Кастомные поля для тест-кейсов. Большая команда с разным уровнем погруженности в проект и разным уровнем технической компетенции. Каждый специалист должен был с равной успешностью закрывать задачи. Это было невозможно совместить без подробно расписанных тест-кейсов. Подробный тест-кейс давал четкое понимание: где, что, почему, как и когда будем исправлять; что, как и когда исправляли до в этом направлении, какие трудности были и проч. детали.

«Без регламентов было не обойтись. На проекте было много интеграций, за которые отвечали разные команды. Нужно было понимание, к кому конкретно идти с вопросами в случае чего. Регламентировали все. Вплоть до типа связи с ответственными — писать в tg, на почту или сразу звонить по телефону. Время ответа тоже регламентировали — если нет ответа от ответственного №1 через час после обращения, то идем к ответственному №2 и ждем еще час, нет ответа — поступаем следующим образом и проч.».

                                                                                                                                   Михаил Ситников, руководитель QA-направления в wpp.digital (ex- WEB++)

Задача №2: Даешь автотесты

Уже в момент внедрения TMS мы с командой «Азбуки вкуса» приняли решение внедрить еще и автотесты на проект экспресс-меню. Они должны были помочь команде добраться до той части функционала, которую не успевали тестировать.

«Полное покрытие тестами колебалось от 24 до 45 часов за спринт — это много. Грубо говоря, на тестирование есть только один рабочий день в рамках спринта. Скажем, в четверг второй недели. 8 дней разрабатывается функционал, на 9-й тестируется, на 10-й правятся обнаруженные баги».

                                                                                                                                   Михаил Ситников, руководитель QA-направления в wpp.digital (ex- WEB++)

За 8 часов мы могли проверить только ? функционала. Решить проблему, как и любую другую подобного рода, можно было увеличением рабочей силы или автоматизацией. Для инновационной «Азбуки вкуса» естественнее был второй путь.

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

Решение №2. Первый раз использовали Gherkin

QA-автоматизаторов со стороны привлекать не стали. Был план проще. Хотели использовать Gherkin (в простонародье «птичий» язык) для «строительства» автотестов.

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

                                                                                                                              Андрей Шахов, ex-руководитель Python-направления в wpp.digital (ex- WEB++)

На написание фреймворка ушло 58 часов Python-программиста и 40 часов тестировщика, чтобы перенести 25% ручных проверок в автоматизацию. QA-команды адаптировались примерно за неделю к работе с автотестами: пощупали, попытались поработать, поняли принцип.

По итогу 2-х месяцев работ мы провели анализ эффективности автоматического тестирования. В итоге мы сократили время на ручные проверки и санити в 12 раз. Раньше ручной прогон 25% функционала занимал 2 часа, теперь — 10 минут.

Немного таблиц, которые мы не стали описывать подробнее, чтобы еще больше не растягивать наш и без того лонгрид:

Привет, новый флоу!

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

И еще раз для закрепления. Наша цель — принести своим трудом пользу бизнесу и пользователям через приложения, сайты и другие цифровые сервисы. О нашей пользе свидетельствуют позиции в рейтингах. Если говорить о тестировании, то в 2024 году мы заняли 12 место в рейтинге агентств по анализу и тестированию сайтов и веб-сервисов среди digital-компании в России и СНГ. Чтобы узнать о других наших заслугах — welcome на наш сайт.