Как организовать тестирование, чтобы ускорить и стабилизировать релизы продукта. Часть 2

    У тестировщика много возможностей повысить качество продукта и сделать работу команды комфортнее. Главное – обсуждать любые изменения с коллективом и внедрять только то, что удобно и полезно для всех.

    Меня зовут Виктория Дежкина, я отвечаю за тестирование ряда продуктов в Дирекции больших данных X5 Retail Group. В прошлой части статьи я начала рассказывать о том, как мы меняли процессы в команде продукта «Система автоматизации закупок торговой сети». Релизы продукта постоянно задерживались на несколько дней и часто выходили «сырыми». Мы изменили порядок выкладки кода и планирования задач, что позволило сократить релизный цикл на несколько дней, но нам еще предстояло выработать оптимальный формат постановки и приемки задач, установить точки тестирования в релизном цикле и научиться приоритизировать задачи по исправлению дефектов.



    Формат постановки и приемки задач и дефектов


    Способ постановки задачи во многом определяет, насколько быстро и правильно она будет выполнена. Описывать задачи можно по-разному, например, с помощью user stories, которые отражают потребность конечного пользователя системы. Звучит это примерно так: «пользователь хочет получать отчет по нажатию зеленой кнопки».

    Минус этого подхода в том, что он не поясняет, что будет «под капотом» у этого решения. User stories оставляют разработчикам слишком много свободы, и иногда это становится проблемой: команда начинает изобретать велосипед или пилит что-то слишком трудоемкое. А учитывая, что в условиях быстрой разработки почти никогда не хватает времени на полноценное документирование, вы при таком подходе получаете загадочный код, сильно затрудняющий интеграцию в продукт новых разработчиков.

    Мы обсуждали несколько вариантов оформления задач и дефектов и остановились на «гибридном» подходе: use case + технические подзадачи. Бизнес-заказчик пишет use case, то есть описывает варианты использования нового функционала, а аналитик с тестировщиком на основе этого составляют для разработчиков технически подзадачи. В описании задачи в Jira мы добавляем use case, из которого она сделана, или тест-кейс, позволяющий воспроизвести ошибку, при этом название и описание у основной задачи остается «человекопонятным».

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

    • кейс, по которому можно воспроизвести ошибку;
    • реальный и ожидаемый результат;
    • подзадачи для бэкенда и фронтенда с четкими указаниями для разработчиков, что нужно поправить. «Бэкенд: для данного API отдавать на фронтенд соответствующий ответ» + матрица вариантов, показывающая, какие ответы должны быть в каждой из возможных ситуаций. «Фронтенд: для данного API в зависимости от ответа с бэка выдавать соответствующий текст ошибки» + матрица вариантов.

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

    Получается соответствующее правило описания дефектов:

    1. Создать задачу с описанием функциональной проблемы, кейсом для воспроизведения ошибки и связкой с историей, в рамках проверки которой был найден дефект.
    2. Добавить к задаче две подзадачи для бэкенда и фронтенда. Подзадачи на фронтенд содержат в себе дополнительно информацию: на какой странице, в какой среде находится дефект, какой API или компонент отрабатывает некорректно, что конкретно надо исправить и ссылку на use case с описанием корректного поведения. Подзадачи на бэкенд содержат в себе описание того, на какой среде найдена ошибка, какой это API, какие параметры передаются, какой приходит ответ, причину, почему реализованная логика считается неверной со ссылкой на документацию, а также указания, что конкретно требуется изменить.

    Также мы отказались от формирования AC (acceptance criteria) на нашем продукте, так как на этапе планирования обсуждаем не только то, что разрабатываем и тестируем, но и как.

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

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

    Такой подход используется только на нашем продукте, потому что он оказался для нас наиболее удобным. В других продуктах Дирекции больших данных X5 используются свои схемы: например, User stories с AC.

    Казалось бы, наш вариант вовсе не способствует ускорению разработки, потому что требует больше шагов, чтобы начать работу. Но это не так.

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

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

    Моменты тестирования


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

    Поэтому мы договорились о тестировании каждой задачи по отдельности, но на одном тестовом стенде. Сначала мы хотели выкатывать несколько задач сразу, но выше я уже рассказывала, какие риски несет в себе эта идея. По одной намного быстрее. Это известный эффект: сокращение количества параллельных задач не замедляет, а наоборот ускоряет процесс. В Канбане, например, есть такая штука, как WIP-лимит (WIP – это work in progress), который ограничивает количество задач, решаемых одновременно каждой ролью.

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

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

    На старте, когда у нас были релизы раз в 2 недели, схема работы выглядела вот так:



    Стало (релиз раз в неделю):



    Правила взаимодействия связки «бэкенд – тестирование – фронтенд»


    Когда в API между бэкендом и фронтендом пересылается много разных данных, не всегда понятно, для чего они нужны и как взаимодействуют. Из-за этого на фронтенде могут происходить поломки. Например, с бэка передается номер калькуляции, demand cal. Номинально это один параметр, но для осуществления расчета вместе с ним с бэка должно «притягиваться» еще восемь полей. Если не передать их вместе с номером калькуляции, на фронтенде эта операция не выполнится.

    Чтобы избежать таких ситуаций, мы стали описывать передаваемые параметры, указывая их в комментариях к подзадаче на разработку API в Jira, где объяснялось, какими данными будут обмениваться бэк и фронт. Пробовали вести описания всех API в фреймворке Swagger, но с его помощью при автоматическом формировании документации не получалось передать фронтенду, что именно бэк будет делать с переданными параметрами. Поэтому мы договорились, что, если речь о параметре, который не просто записывается на бэке, а использует другие параметры, необходимо описывать его назначение в задаче.

    Также мы стали контролировать обозначение переменных, чтобы в однотипных API все поля были стандартизованы. Наш продукт состоит из микросервисов, и в каждом могут использоваться свои названия полей. В одном поле с названием поставщика может быть supplier, в другом – supplierID, в третьем name и т.д. При передаче этих данных в один компонент фронтенда могут начаться сложности, поэтому мы прошлись по всем параметрам и начали стандартизировать все названия переменных. Для этого собрали сводную таблицу всех текущих обозначений, таблицу всех компонентов фронта и используемые ими переменные (с чем сильно помог фронтенд-разработчик) и сверили их. Теперь все новые API получают стандартные названия переменных, а старые API правятся при возникновении задач на их доработку.

    Ускорение работы по исправлению дефектов


    На этапе постановки задачи приоритеты определяет бизнес-заказчик – ему виднее, что и в каком порядке нужно для развития продукта. Но после выкатки на dev, когда появляются задачи на исправление дефектов, их приоритетами командует тестировщик.

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

    Раньше в таких ситуациях мы сразу шли к разработчикам и просили их поменять приоритет задач, но это их отвлекало. Поэтому мы договорились, что будем обращаться только в определенные моменты – после code freeze, до 5 раз в день. Что это дало? Мы перестали снижать продуктивность разработчиков внезапными обращениями, избавились от простоев, увеличили время для проработки задач аналитиком.

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

    Эти меры вместе с единой логикой выкатки кода на dev, релиз и прод позволили сократить период исправления дефектов с 3 дней до 3-4 часов.

    Результаты


    За 9 месяцев работы нашего продукта «Автоматизация закупок» у нас получилось сократить релизный цикл с 2,5 недель до 1 недели с возможностью ежедневной выкатки, значительно повысив стабильность релизов.

    Что изменилось:

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

    BONUS: удалось снизить уровень стресса в команде (я надеюсь), а еще благодаря согласованной работе команды (спасибо деливери) без проблем перейти на удаленку :-)

    Внедряя эти улучшения, мы придерживались нескольких правил:

    • Тестировщики и разработчики – в одной лодке (повторять это как мантру!), поэтому первое, что нужно сделать тестировщику – поладить с командой и узнать, что беспокоит ее больше всего, заручиться ее поддержкой. Моими союзниками и партнерами в команде стали деливери-менеджер и разработчики.
    • Готового идеального решения нет, и его нужно искать. Тестировщик никому не навязывает свои правила, он подстраивается под команду и меняет свои подходы вместе с ней, держа при этом в голове образ светлого будущего и мягко внедряя меры для его достижения)).
    • Слишком жесткие ограничения и стандартизация – не метод. Если переборщить, команды могут потерять гибкость.

    Правила взаимодействия, которые помогли нам ускорить развитие этого продукта, нельзя в чистом виде перенести на другие продукты Дирекции – они устроены иначе, и потребности разработчиков там отличаются. Но принцип создания этих правил будет таким же: устанавливать порядок выкладки кода, находить оптимальные точки для тестирования, документировать код и API.

    Параллельно с работой внутри продуктов мы вырабатываем правила, которые призваны облегчить взаимодействие между продуктами, и об этом мы обязательно расскажем в следующих материалах. Так в Дирекции больших данных постепенно формируется стратегия развития качества продуктов.
    X5 Retail Group
    Все о цифровой трансформации ритейла

    Комментарии 5

      0
      получилось сократить релизный цикл с 2,5 недель до 1 недели с возможностью ежедневной выкатки, значительно повысив стабильность релизов.

      Не вполне понимаю суть этого достижения. Почему не до одного дня? Зачем тянуть неделю?

        0
        Речь идет возможности разработки одного и того же объема нового функционала в более короткий срок. Выкладка проходит недельными циклами не из-за ожидания, а потому что продукт активно развивается и на каждом релизе добавляется крупный кусок нового функционала. Мелкие правки могут выкатываться ежедневно. Более сложные бизнес — задачи — раз в неделю.
        0
        Если всмотреться в иллюстрацию к статье на дворе ночь(многие ушли), но люди все еще лепят тесты.
          0

          Спасибо за интересную статью.


          Расскажите, пожалуйста, о своём подходе к оценке задач.
          Пока входящая задача дойдёт до планирования, над ней уже должны поработать тестировщик и аналитик. Это тоже съедает их время.
          Как устроены эти процессы?
          Оставляете ли в спринте запас на это? Выделяете отдельный день на такой анализ?

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

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое