Мы помогаем «Азбуке вкуса» развивать их цифровые продукты с 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 месяца, и они долго входили в проект. Проектная документация была разрозненной, многое передавали просто устно.
Руководитель по тестированию со стороны «Азбуки вкуса» хотел решить проблему разрозненности и устных договоренностей. 3 разные outsource-команды должны были в конечном счете работать как единый организм. Был взят курс на внедрение TMS (*Test Management System или Система управления тестированием).
В нашей ситуации TMS давала объективную отчетность и понятный флоу. В общем, независимо от количества команд и степени погруженности в продукт тестирование должно было работать четко, как часы.
Мы заранее готовились к автоматизации, поэтому тестировали разные TMS внутри своей команды.
«Еще в самом начале сотрудничества мы внедряли в av.ru гибкие решения с перспективой на масштабирование. Помню мы тогда разрабатывали систему внедрения промокодов в ядро расчетов. Уже тогда внутри, у себя, мы начали строить базу тест-кейсов в TMS. Все участники процесса понимали: без хорошего тестирования велик шанс поломать критический коммерческий функционал».
Василий Гребенников, директор wpp.digial (ex- WEB++)
Наиболее подходящей TMS для нас стала testrail.
Весной 2022 года компания Gurock, владелец TestRail, прекратила продление лицензий в России. Поэтому на данный момент клиент ее не использует.
Вот основные параметры, по которым выбрали систему:
Широкий список интеграций. Продукты тестировались несколькими командами с разными внутренними процессами, разными методиками работы. Нам нужна была система, которая позволила бы не ломать эффективный флоу других команд. Идеальным решением было интегрировать привычные сервисы в TMS, чтобы специалисты затратили как можно меньше времени на адаптацию. Такой подход позволил бы не стопорить производство, а мягко «пересадить» специалистов в TMS;
Кастомные поля для тест-кейсов. Большая команда с разным уровнем погруженности в проект и разным уровнем технической компетенции. Каждый специалист должен был с равной успешностью закрывать задачи. Это было невозможно совместить без подробно расписанных тест-кейсов. Подробный тест-кейс давал четкое понимание: где, что, почему, как и когда будем исправлять; что, как и когда исправляли до в этом направлении, какие трудности были и проч. детали.
«Без регламентов было не обойтись. На проекте было много интеграций, за которые отвечали разные команды. Нужно было понимание, к кому конкретно идти с вопросами в случае чего. Регламентировали все. Вплоть до типа связи с ответственными — писать в tg, на почту или сразу звонить по телефону. Время ответа тоже регламентировали — если нет ответа от ответственного №1 через час после обращения, то идем к ответственному №2 и ждем еще час, нет ответа — поступаем следующим образом и проч.».
Михаил Ситников, руководитель QA-направления в wpp.digital (ex- WEB++)
Уже в момент внедрения TMS мы с командой «Азбуки вкуса» приняли решение внедрить еще и автотесты на проект экспресс-меню. Они должны были помочь команде добраться до той части функционала, которую не успевали тестировать.
«Полное покрытие тестами колебалось от 24 до 45 часов за спринт — это много. Грубо говоря, на тестирование есть только один рабочий день в рамках спринта. Скажем, в четверг второй недели. 8 дней разрабатывается функционал, на 9-й тестируется, на 10-й правятся обнаруженные баги».
Михаил Ситников, руководитель QA-направления в wpp.digital (ex- WEB++)
За 8 часов мы могли проверить только ⅓ функционала. Решить проблему, как и любую другую подобного рода, можно было увеличением рабочей силы или автоматизацией. Для инновационной «Азбуки вкуса» естественнее был второй путь.
Пока автотесты были только в разработке, мы приняли решение тестировать в первую очередь интеграции. Остальное попадало под более низкий приоритет. Мы сокращали количество просмотров, прогонов, брали только самые критичные сценарии, чтобы не растягивать спринт. Страдало качество продукта.
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 на наш сайт.