У тестировщика есть множество возможностей улучшить качество продукта и сделать работу команды более комфортной.
Главное — обсуждать любые изменения с командой и внедрять только то, что удобно и полезно каждому.
Меня зовут Виктория Дежкина, я отвечаю за тестирование ряда продуктов в дирекции больших данных X5 Retail Group. В последней части статьи я начал рассказывать о том, как мы меняли процессы в продуктовой команде «Системы автоматизации закупок торговой сети».
Релизы продуктов постоянно задерживались на несколько дней и часто выходили «сырыми».
Мы изменили порядок раскладки кода и планирования задач, что позволило сократить цикл релиза на несколько дней, но нам всё равно предстояло разработать оптимальный формат постановки и приёма задач, установления точек тестирования в цикле релиза и научиться расставлять приоритеты в задачах по устранению дефектов.
Формат постановки и принятия задач и дефектов
От того, как поставлена задача, во многом зависит, насколько быстро и правильно она будет выполнена.Задачи можно описывать по-разному, например, с помощью пользовательских историй, отражающих потребности конечного пользователя системы.
Звучит это примерно так: «пользователь хочет получить отчет при нажатии зеленой кнопки».
Недостаток такого подхода в том, что он не объясняет, что будет «под капотом» этого решения.
Пользовательские истории оставляют разработчикам слишком много свободы, и иногда это становится проблемой: команда начинает изобретать велосипед или создавать что-то слишком трудоемкое.
А учитывая, что в среде быстрой разработки времени на полную документацию почти никогда не хватает, при таком подходе вы получаете загадочный код, который очень затрудняет интеграцию в продукт новым разработчикам.
Мы обсудили несколько вариантов проектирования задач и дефектов и остановились на «гибридном» подходе: вариант использования + технические подзадачи.
Бизнес-заказчик пишет use case, то есть описывает варианты использования нового функционала, и на основе этого аналитик и тестировщик создают для разработчиков технические подзадачи.
В описание проблемы в Jira мы добавляем вариант использования, из которого она сделана, или тест-кейс, позволяющий воспроизвести ошибку, при этом название и описание основной проблемы остается «читабельным для человека».
Давайте посмотрим, например, что находится внутри дефекта под названием «Пользователь не понимает, как обрабатываются ошибки, возникающие при выборе ставки на покупку».
Описание задачи содержит:
- случай, с помощью которого можно воспроизвести ошибку;
- реальный и ожидаемый результат;
- подзадачи для бэкенда и фронтенда с четкими инструкциями для разработчиков, что нужно исправить.
«Бэкенд: для заданного API отправить во фронтенд соответствующий ответ» + матрица вариантов, показывающая, какие ответы должны быть в каждой из возможных ситуаций.
«Фронтенд: для данного API в зависимости от ответа бэкенда выводить соответствующий текст ошибки» + матрица вариантов.
Если все подзадачи закрыты, дефект возвращается на повторное тестирование.
При обнаружении дополнительных проблем соответствующая подзадача создается заново.
Оказывается, соответствующее правило описания дефектов:
- Создайте задачу с описанием функциональной проблемы, кейсом для воспроизведения ошибки и ссылкой на историю, в ходе которой был обнаружен дефект.
- Добавьте в задачу две подзадачи для бэкенда и фронтенда.
Фронтенд-подзадачи содержат дополнительную информацию: на какой странице, в каком окружении находится дефект, какой API или компонент работает некорректно, что именно нужно исправить, а также ссылку на вариант использования, описывающий правильное поведение.
Backend-подзадачи содержат описание того, в какой среде обнаружена ошибка, что это за API, какие параметры передаются, какой ответ получен, причина, по которой реализованная логика считается некорректной со ссылкой на документацию, а также инструкции по что именно нужно изменить.
Что это дало? Такой подход позволял нам в любой момент понять, что не так с функционалом со стороны пользователя, на каком этапе работы над дефектом и в зависимости от нагрузки на бэк и фронт по-разному расставлять приоритеты подзадач по одному и тому же дефекту.
В результате еще до начала разработки вся команда понимает, какая часть каждой задачи затронет лично его, и в результате каждая задача содержит информацию: как она разрабатывалась, как тестировалась, есть ли на нее документация, а также что в нем исправлялось в процессе разработки.
Этот подход используется только на нашем продукте, потому что для нас он оказался наиболее удобным.
Другие продукты Дирекции больших данных X5 используют собственные схемы: например, User Stories с AC. Казалось бы, наш вариант вообще не помогает ускорить разработку, поскольку требует большего количества шагов для начала работы.
Но это неправда.
Мы организовали процесс таким образом, чтобы тестирование проводилось параллельно с разработкой.
Тем самым разработчик не сидит без дела, пока тестировщик прорабатывает и максимально локализует задачу.
Плюс мы всегда видим, какой конкретно разработчик работал над задачей и как он ее реализовал — это позволяет нам понять в будущем, какой разработчик быстрее сможет справиться с новыми подобными задачами.
Логика проста: чем меньше разработчик делает вещей, не связанных напрямую с написанием кода, тем лучше, а наиболее точная локализация дефекта позволяет глубже задуматься о возможных связях и проблемах, вызванных конкретной ошибкой.
Также может возникнуть вопрос, не мешают ли правила, которые мы установили в нашем продукте, формированию единых стандартов тестирования и разработки в отделе.
На самом деле нет: общие правила отдела определяют, что должна содержать задача на определенном этапе разработки, и мы отвечаем этим требованиям, просто работаем над задачей на более ранних стадиях.
Тестовые моменты
Мы долго обсуждали вопрос, на каком этапе проводить тестирование.Поначалу идея заключалась в том, чтобы проверять каждую отдельную задачу в локальной ветке, но при таком подходе было бы невозможно проверить, как эти задачи работают вместе, а их конфликты выявлялись бы только на этапе собранного релиза, когда он будет готов.
слишком поздно что-либо менять.
Поэтому мы договорились тестировать каждую задачу отдельно, но на одном тестовом стенде.
Сначала мы хотели выкатить сразу несколько задач, но я уже выше рассказал, какие риски таит в себе эта идея.
По одному гораздо быстрее.
Это известный эффект: уменьшение количества параллельных задач не замедляет, а наоборот ускоряет процесс.
В Канбане, например, есть такое понятие, как WIP-лимит (WIP — незавершенная работа), который ограничивает количество задач, решаемых одновременно каждой ролью.
В итоге мы установили пять пунктов, где тестировщики активно участвуют в процессе разработки:
- На стадии документации.
Мы следим за тем, чтобы не возникало задач, противоречащих логике уже сделанного, и фиксируем детали реализации каждой задачи.
- На этапе постановки проблемы.
Обсуждаем с аналитиком все возможные случаи, связанные с задачей, и учитываем их при формировании задачи.
- На этапе планирования.
Мы обсуждаем, как запланированное внедрение может помешать соответствующей функциональности и какие проблемы это может вызвать.
Согласовываем все критические дефекты с продуктом и завершаем спринт.
- На стадии подготовки к выпуску.
Каждую задачу мы тестируем итеративно на тестовом стенде, а за день до запланированного релиза собираем все задачи вместе и тестируем их на одном стенде.
- После выпуска.
Проверяем, как работает релиз в продакшене.
Сейчас (выходит раз в неделю):
Правила взаимодействия связки «бэкенд — тестирование — фронтенд»
Когда в API между бэкендом и фронтендом отправляется много разных данных, не всегда понятно, для чего они нужны и как взаимодействуют. Из-за этого могут возникнуть поломки на передней части.Например, номер расчета потребность кал передается из бэк-офиса.
Номинально это один параметр, но для проведения расчета вместе с ним из подложки нужно «вытащить» еще восемь полей.
Если вы не передадите их вместе с номером калькуляции, эта операция не будет выполнена во внешнем интерфейсе.
Чтобы избежать подобных ситуаций, мы начали описывать передаваемые параметры, указывая их в комментариях к подзадаче разработки API в Jira, где объяснялось, какими данными будут обмениваться бэк и фронт. Мы старались поддерживать описания всех API в фреймворке Swagger, но с его помощью при автоматической генерации документации не удалось донести до фронтенда, что именно бэкенд будет делать с переданными параметрами.
Поэтому мы сошлись на том, что если мы говорим о параметре, который не просто пишется на бэкенде, а использует другие параметры, то в задаче необходимо описать его назначение.
Также мы стали контролировать обозначение переменных, чтобы в однотипных API все поля были стандартизированы.
Наш продукт состоит из микросервисов, и каждый может иметь свои имена полей.
Одно поле с названием поставщика может содержать поставщика, другое поле может содержать идентификатор поставщика, третье поле может содержать имя и т. д. При переносе этих данных в один фронтенд-компонент могут возникнуть трудности, поэтому мы прошлись по всем параметрам и начали стандартизировать все имена переменных.
Для этого мы собрали сводную таблицу всех текущих обозначений, таблицу всех фронтенд-компонентов и используемых ими переменных (с чем фронтенд-разработчик очень помог) и сравнили их.
Теперь все новые API получают стандартные имена переменных, а старые API корректируются при возникновении задач по их улучшению.
Ускорение работы по исправлению дефектов
На этапе постановки задачи приоритеты определяет бизнес-заказчик — он лучше знает, что и в каком порядке необходимо для разработки продукта.Но после выкатки на dev, когда появляются задачи по исправлению дефектов, тестировщик расставляет приоритеты.
Иногда возникает необходимость срочно изменить приоритеты этих задач — например, мы обнаруживаем мелкий дефект в бэкенде, без исправления которого фронтенд-команда не может приступить к его исправлению.
Раньше в таких ситуациях мы сразу шли к разработчикам и просили изменить приоритет задач, но это их отвлекало.
Поэтому мы договорились, что будем обращаться только в определенные моменты — после заморозки кода, до 5 раз в день.
Что это дало? Мы перестали снижать продуктивность разработчиков внезапными запросами, избавились от простоев и увеличили время проработки задач аналитиками.
Более того, благодаря тому, что задачи у разработчиков больше не появляются спонтанно, мы всегда знаем, у кого какая нагрузка, кто работал над задачей раньше и сможем с ней справиться быстрее.
В результате мы гораздо лучше понимаем, успеем ли мы подготовить релиз по графику или нет. Эти меры, вместе с единой логикой развертывания кода для разработки, выпуска и производства, позволили сократить срок исправления дефектов с 3 дней до 3-4 часов.
Результаты
За 9 месяцев работы нашего продукта «Автоматизация закупок» нам удалось сократить цикл релизов от 2,5 недель до 1 недели с возможностью ежедневного выпуска, что значительно повышает стабильность релизов.Что изменилось:
- Мы избавились от необходимости исправлять дефекты после разработки, так как на этапе подготовки задачи перенесли эту работу на максимум.
- Мы сократили срок исправления дефектов с 3 дней до 3-4 часов.
- Мы получили возможность выкатывать релизы «по команде».
Теперь мы можем в любой день собраться, выкатить задачи, и к вечеру все будет готово и отлажено.
- Мы повысили прозрачность процессов для всех участников процесса: теперь все разработчики и тестировщики команды понимают, что происходит в данный момент, кто какими задачами занят, сколько еще времени нужно на разработку и исправление ошибок и т.д. .
- Тестировщики и разработчики находятся в одной лодке (повторяйте это как мантру!), поэтому первое, что нужно сделать тестировщику — это найти общий язык с командой и выяснить, что их больше всего беспокоит, заручиться их поддержкой.
Менеджер по доставке и разработчики стали моими союзниками и партнерами в команде.
- Готового идеального решения не существует, и его нужно искать.
Тестировщик никому не навязывает своих правил, он адаптируется к команде и меняет свои подходы вместе с ней, сохраняя при этом образ светлого будущего и мягко реализуя меры для его достижения)).
- Слишком строгие ограничения и стандартизация – не тот метод. Если переборщить, команды могут потерять гибкость.
Но принцип создания этих правил будет тот же: установить порядок выкладки кода, найти оптимальные точки для тестирования, документировать код и API. Параллельно с работой внутри продуктов мы разрабатываем правила, которые призваны облегчить взаимодействие между продуктами, и об этом мы обязательно поговорим в следующих материалах.
Таким образом, Дирекция больших данных постепенно формирует стратегию развития качества продукции.
Теги: #ит-инфраструктура #api #тестирование #фронтенд #тестирование ИТ-систем #аналитик #автоматизация #разработчик #код #задачи #продукт #стабилизация #дефект #повторное тестирование
-
Hr Это Зло
19 Oct, 24 -
Авторизация Отклонена
19 Oct, 24
