Новая функциональность без багов на примере биллинга для мобильного оператора

Ноль ошибок по итогам интеграционных тестов – тут речь о тестировании новой функциональности на бизнес-приемке на стороне оператора. Пара слов о том, как устроено это тестирование.

Мы выпускаем новые версии нашего биллингового софта по графику, 6 раз в год. Даты отгрузок релизов известны заранее. На момент написания этой статьи у нас уже есть запланированные даты релизов на весь следующий год.

Такая специфика связана с гонкой сотовых операторов за time-to-market. Главный принцип: абонент должен регулярно получать новые фичи биллинга. Платежи через смартфон, сохранение номера при смене оператора, возможность продавать неиспользованный трафик – обновления могут быть разными.

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

У нас на стороне разработки биллинга в релизе участвует порядка 70 человек. Это 5-6 команд, каждая со своей специализацией: аналитика, разработка (несколько команд), функциональное тестирование, интеграционное тестирование.

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

Зона дискомфорта

На момент начала описываемой истории, два года назад, мы имели следующую картину:

• команды в конце цепочки разработки бывали перегружены;
  
• «пора отдавать следующей команде, а предыдущая только-только начала свою часть работы»;
  
• заказчик мог находить после наших циклов тестирования в районе 70 ошибок.
  

Ошибки, которые можно было найти по результатам интеграционных тестов, могли быть минорными («часть сообщения отображается в виде прочерков») или даже критическими («не происходит переход на другой тариф»).

Через год мы смогли снизить число ошибок до 10-15, к середине 2020 – до 2-3. И вот в сентябре нам удалось достичь целевого нулевого показателя.

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

Точки роста

Главный инструмент интеграционного тестирования – тестовый стенд. Там происходит эмуляция деятельности абонента.

Общие стенды

На тестовые стенды накатываются дампы с продакшена – чтобы можно было тестировать в условиях, максимально приближенных к боевым.

Загвоздка в том, что дампы на наших стендах и стендах заказчика могли отличаться. Оператор делает дамп, передает нам, мы тестируем новую функциональность, отлавливаем и чиним баги. Отдаем готовую функциональность заказчику, коллеги на той стороне начинают тестировать. Наши и их дампы могли отличаться по актуальности: мы тестировали на июльском, оператор – на августовском, например.

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

Что мы сделали: договорились, что схемы данных, на которых происходит тестирование, будут одинаковые, и в целом у нас будет общий стенд.

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

Проверка настроек перед тестированием

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

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

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

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

Что мы сделали: ввели процедуру проверки нами настроек на стороне заказчика перед началом тестирования на стендах оператора.

Процедура такая: заказчик выбирает кейсы, которые мы показываем на настроенном стенде. Запускаем тесты. Если ошибки есть, мы их оперативно исправляем; если нет – тест считается пройденным.

Дополнительные коммуникации вокруг документации

Проверка настроек перед тестированием вдобавок к описанию этих настроек в мануалах – это один пример дополнительных коммуникаций вокруг документации. Были и другие.

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

Наши технические писатели организовали воркшопы для обучения сотрудников заказчика по использованию новой функциональности.

Процесс передачи документации стал менее дискретным, более непрерывным: новая информация, уточнения, рекомендации – теперь могли досылаться частями после “отгрузки” основных мануалов; по мере появления или по потребности.

Все это позволило лучше информировать заказчика о новой функциональности и через это уменьшить число ошибок на интеграционных тестах.

Экспертиза по работе со сторонними системами

Для разработки биллинга нам нужно уметь вести учет трафика. Для этого существуют отдельные PCRF-системы. Учет звонков происходит в одной базе, SMS там же, а трафика – в другой базе; и есть специальное ПО, которое это все синхронизирует.

При этом PCRF-системы – это сторонний проприетарный софт. То есть "черный ящик": мы отдаем туда данные, получаем что-то в ответ, но не можем контролировать, что происходит внутри. И тем более не можем ничего там менять.

Что мы сделали: завели отдельную внутреннюю базу знаний по PCRF. Каждый инцидент, каждый вариант настройки, каждый инсайт – все записывалось и шарилось в команде.

В итоге мы стали неплохими пользователями PCRF-системы, можем ее настроить и понимаем, что она должна делать. Это позволяет экономить время на простых инцидентах. Со сложными случаями, конечно, все равно обращаемся за помощью к разработчикам системы.

Больше стендов

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

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

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

Что мы сделали: завели отдельный стенд для каждого тестировщика.

Это позволило нам убрать ошибки, которые случались из-за «поздно дошла моя очередь к стенду, не успел».

Виртуализация

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

Что мы сделали: задействовали виртуализацию.

Копирование виртуальных машин со всеми нужными настройками, предустановленным софтом и автоматизация этого процесса помогли сократить время подготовки стенда до «в пределах дня».

Планирование

Ошибки из интеграционных тестов – это еще и результат просчетов в планировании релиза. Замахнулись на много, на момент фиксированной даты релиза успели не все.

Что мы сделали: ввели промежуточные дедлайны для каждого этапа разработки. “Если известна конечная дата, то известна и каждая промежуточная" – такой принцип помог нам лучше контролировать скорость движения к цели релиза.

Саппорт и релиз параллельно

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

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

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

Деление было условное: не обязательно половина туда, а половина сюда. Мы могли перебрасывать людей между группами по необходимости. Со стороны могло выглядеть, как будто ничего не поменялось: вот человек из команды, за спринт он и багами позанимался, и новыми фичами. Но по факту выделение отдельных групп было улучшением из разряда “теперь мы можем выдохнуть”. Сфокусированность каждой группы и распараллеливание работ между группами сильно нам помогли.

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

Главный инструмент

Улучшение, которое помогло нам больше всего – честные постмортемы.

Кто-то называет это ретроспективой, кто-то – анализом итогов; у нас в команде прижилось слово «постмортем». Все описываемые в этой статье улучшения были придуманы на постмортемах.

Принцип простой: случился релиз, нужно собраться и честно обсудить, как все прошло. Звучит просто, но в реализации есть подводные камни. После «неудачного» релиза у людей в команде бывает настроение «некогда языками чесать, нужно дело делать». Кто-то может приходить на постмортемы и отмалчиваться (и таким образом, не озвучивать часть потенциально полезной информации).

Собрать полную картину

Приглашаем расширенный состав участников. Разработчиков, тестировщиков, аналитиков, менеджеров, руководителей – всех, у кого есть желание высказаться. Организационно собрать всех-всех не всегда получается. Это ок, так тоже работает. Речь о том, чтобы не отказывать в участии коллегам с формулировкой “мы тут в своей команде итоги подводим, вы в своей подведите”. Работа со стендами, код, процессы, взаимодействие – стремимся не упустить из виду ни одного аспекта.

Не хвататься за все сразу

Ок, по итогам постмортема мы придумали 30 точек роста. Сколько брать в работу? Может, у нас получится решить все до следующего раза? Для нас лучше всего сработал формат «выбрать 2-3». При таком раскладе есть фокус, и усилия людей в команде не распыляются. Лучше сделать меньше, но полностью, чем много, но не довести до ума.

Не мудрить с форматом

Существует масса подходов к проведению постмортемов. Фасилитационные практики, приемы из дизайн-мышления и латерального мышления, техника Голдратта и других уважаемых экспертов. По нашему опыту, для старта достаточно здравого смысла. Записали проблемы, сгруппировали, выбрали несколько кластеров, отодвинули в сторону остальное (см. предыдущий пункт), обсудили, зафиксировали план. Когда есть единая цель, найти общий язык не так сложно.

Брать в работу

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

Постмортем может быть довольно болезненным процессом. Разговаривать о неуспехе, еще и в конструктивном ключе, непросто. Но побороть дискомфорт – стоит того. Уверен, что без постмортема нам не удалось бы придумать и реализовать все те вещи, которые помогли достичь цели в ноль ошибок в релизе.

Самый главный инструмент

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

Самый главный инструмент – вовлечение команды.

У вовлечения есть инструментальная сторона. Например:

• если работаем сверхурочно, то начальник рядом с командой, помогает руками;
  
• если подбадривать команду трекингом прогресса, то найти наглядные метрики (для числа ошибок – несложно).

И дальше в том же духе.

Есть у вовлечения и сложно формализуемая сторона – способность делиться с командой своей верой в успех. Мы ведь с командой не то, чтобы заглянули в брошюру с ценностями компании, увидели там «сильнее вместе» и решили, что, бинго, решение найдено. Мы видели примеры, как непростые цели можно достигать через объединение усилий. У нас в команде были люди, кто верил в успех и стремился передать это убеждение коллегам. Остальное – дело техники.

Люди – самое главное.

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

Нам с командой еще многое предстоит сделать в борьбе за качество релизов и оптимизацию time-to-market. Сделать регулярно воспроизводимым результат с нулем ошибок на интеграционных тестах, автоматизировать регресс.

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