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

< о проекте >

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

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

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

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

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

< старт работ >

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

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

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

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

Михаил Ситников

руководитель QA-направления WPP.DIGITAL

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

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

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

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

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

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

Василий Гребенников

директор WPP.DIGITAL

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

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

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

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

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

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

Михаил Ситников

руководитель QA-направления WPP.DIGITAL

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

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

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

Михаил Ситников

руководитель QA-направления WPP.DIGITAL

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

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

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

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

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

Андрей Шахов

руководитель Python-направления WPP.DIGITAL

< решение задачи >

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

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

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

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

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

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

< команда >

над проектом работали

Михаил Ситников

Василий Гребенников

Андрей Шахов

< еще материалы >

рекомендуем посмотреть

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

+1

Тестирование

Разработка

Анализ

Клиент хотел улучшить пользовательский опыт на проекте. Решили стартовать с насущной проблемы — авторизации. Нужно было построить сервис единой авторизации

Тестирование

Разработка

+4

Проектирование