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