Начинаем

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

Я начал свой путь в компании в конце 2017 года с должности специалиста технической поддержки, некоторое время поддерживал скрипты на python, а затем в мае 2019 года стал тестировщиком.

Здесь и далее я буду употреблять именно слово “тестировщик”, так как согласен с мнением, высказанным в книге “Agile Testing”, что в попытке называть специалистов QС или QA больше желания уйти от негативных ассоциаций низкоквалифицированной должности, чем реальных расширений компетенций. Тем не менее тестировщик в agile, как правило, более t-shaped и оказывает влияние на весь процесс разработки ПО. О выделенных ролях QC и QA, не занимающихся непосредственно тестированием, речи мы не ведем.

В мае 2021 года мне предложили занять должность тест-лида, которая со временем трансформировалась в тест-менеджера. В течение этих трёх с половиной лет мы пару раз меняли подходы к процессам в тестировании: сначала по собственной инициативе, а затем вместе с переходом компании на методологию SCRUM. Мы хотели всё и сразу, убеждались, что это невозможно, интуитивно находили более полезные сценарии действий.  А потом читали в книжках, что так давно уже все делают – но без набитых шишек нам бы и не удалось осознать, что это именно то, что нам нужно в наших условиях. Итак, приступим.

Что тестируем?

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

1. Управление пользователями и их счетами. 

Звучит просто, но на самом деле это три сервиса, один из которых совсем не микро и работает в трёх режимах. А помимо перечисленного в них ещё зашита логика аутентификации и авторизации, доступов, ролей, маржинальных рисков, комиссий, отчётов – и это только вершина айсберга. Есть ещё обработка трейдов и прочих транзакций, роллбэки и мирроринг … (по идее уже где-то здесь мозг должен перестать воспринимать непонятный набор слов и переходить в режим ожидания, когда глаза выхватят следующий пункт).

2. Управление финансовыми инструментами и историческими рыночными данными. 

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

3. Интеграции контрагентов, проведение заявок клиентов. 

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

4. Прокси между вышеперечисленными сервисами и торговыми платформами, а также API для клиентов (HTTP и FIX).

Казалось бы просто “взял-отдал”, но ситуация осложняется максимальным количеством зависимостей и стремлением избегать избыточной нагрузки на отдельные сервисы.

Как правило, потребители получают данные сервисов посредством REST API, из HTTP стримов и по бинарному сокету на protobuf (для подключения к которому в целях тестирования у нас есть собственные python клиенты).

Сколько нужно тестировщиков?

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

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

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

• Тестовый долг. Где-то исторически сложилось так, что в наличии хороший набор регрессионных автотестов, а где-то не успевают писать тесты на свежий функционал.

• Дополнительные активности и рабочие обязанности. Например, если в компании бизнес-аналитики отсутствуют как класс, это не означает, что их работу никто не выполняет – просто её выполняют в меньшем объёме и не так профессионально все остальные. На продакшене возникают инциденты – кто-то должен их исследовать (или как минимум объяснить, как это работает).

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

В команде 1 основного нашего поддомена, соотношение стремится к 1dev-1qa: здесь бОльшая вариативность проверок и вероятность регресса, безусловная необходимость увеличения покрытия автоматизацией тестов. 

В команде 2, где достаточно предсказуемый функционал, хитрой логики немного, и уже существует хорошее покрытие автотестами: 2dev-1qa. 

В команде 3 соотношение 1,3dev-1qa  из-за слишком большого количества абсолютно разных интеграций, в протоколы которых необходимо вникать. А кроме того их требуется не только тестировать, но ещё и поддерживать на стейджевом окружении, где их могут использовать и другие команды (назовём это внутренним бета-тестированием). 

В команде 4 неожиданно 1dev-1qa из-за множества зависимостей и легаси-тестов, которые приходится поддерживать и переписывать под новые реалии (об этом позже).

Онбординг

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

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

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

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

Как тестируют в командах?

Новые фичи

В данный момент мы пришли к следующей модели:

1. И разработка, и тестирование задачи стартуют одновременно. Тестировщики составляют план, с которым также могут ознакомиться и разработчики. Что это даёт? 

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

• Разработчик заранее понимает, как будет тестироваться и использоваться функционал, что позволяет реализовывать его более удобным для этих целей (ATDD).

• Согласовывается набор кейсов, который будет закрыт либо юнит-тестами разработки, либо интеграционными тестировщиков, таким образом избегая дублирования, если на то нет оснований.

2. Тестировщик приступает к написанию автотестов на пока ещё не написанный код (progression testing). К моменту выкатки разрабатываемого функционала на тестовое окружение уже готов небольшой набор автотестов. Это позволяет:

• Получить быстрый отклик сразу после выкатки функционала без переключения контекста разработчика на другую задачу (к тому же запустить тесты может и сам разработчик).

• Уменьшить время на ретест в ближайшем будущем.

• Обрести уверенность в жизни фичи после релиза за счёт пополнения набора регрессионных тестов.

Написание автотеста (хотя бы одного) является составной частью тестирования задачи – и без него невозможно перевести её в статус ready for release, с этим согласна вся команда. Естественно, есть задачи, написание автотеста для которых невозможно или слишком дорогостояще, но в большинстве случаев это не так.

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

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

Всё это позволяет уменьшить время простоя задачи в ожидании (в процессе движения карты из статуса разработки в тестирование и обратно), а также затраты на переключение контекста.

Старые тесты

Каждый новый тест пополняет собой набор старых тестов – а их тоже нужно поддерживать в рабочем состоянии. Некоторые из них начинают падать по независящим от сервиса причинам – из-за проблем с инфраструктурой или изменений в смежных командах (о которых забыли или не успели сообщить), во всё это нужно незамедлительно вникать. Некоторые тесты начинают вести себя ненадёжно, периодически падая без видимой на то причины (flaky) – с ними тоже что-то требуется делать (выключать/рефакторить/исследовать). Для этого выделяется дежурный на спринт, который:

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

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

• Может привлекаться к другим задачам автоматизации: подготовке к использованию на других окружениях (помимо тестового), увеличению покрытия, рефакторингу тестов под новые стандарты.

Время, которое тратится на анализ, не учитывается в капасити спринта. Но исследование и поиск неучтённых факторов, вызывающих периодические падения тестов – задачи, которые нельзя откладывать. Поддержка текущего набора автотестов – это часть работы в спринте, соответственно, потребность её вести должна учитываться при планировании. Время, выделяемое на эту активность – отличный индикатор сбалансированности команды. Как правило, стараясь отвечать интересам бизнеса и поставлять новый функционал, подобная работа тестировщиков получает низкий приоритет и откладывается, что сигнализирует о том, что в команде дисбаланс dev/qa.

Релиз

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

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

• Производит приемочное тестирование (вручную и автотестами).

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

• Наблюдает посредством мониторинга и метрик за состоянием релизных версией на стейджевом окружении оставшиеся дни до релиза на продакшн (в нашем случае это два дня).

Шифт-лефт

В течение текущего спринта тестировщики привлекаются к анализу задач для спринта будущего. 

• Обязательно определяются критерии приёмки, которые затем автоматизируются первыми. 

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

• Совместно с разработкой разрабатывается decision table, в которой учитываются все параметры, которые могут влиять на логику функционала.

• Тестировщики озвучивают вопросы, возникающие при ознакомлении с отобранными задачами, ответы на которые продакт-оунер должен получить к моменту планирования спринта. 

• Тестировщики имеют право отказать во включении задачи в спринт, если не до конца понимают, что и как проверять. 

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

Документация

Во всей этой суете (всё, что описано выше, происходит в течение двух недель) остаётся мало места документации, но тут то как раз и пригождается история с обязательными автотестами, которые пишутся так, чтобы они самодокументировали себя (щепотка BDD). В TMS вносятся только:

• трудноавтоматизируемые, но жизненно необходимые кейсы, 

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

Помощь командам

Автоматизаторы

Все наши тестировщики носят шильдик “Automation QA Engineer”, так как написание новых и поддержка старых автотестов входит в должностные обязанности каждого из них. Но помимо тестировщиков в командах у нас есть небольшая отдельная команда автоматизаторов, можно даже сказать SDET. 

Кто главный враг тестирования в agile-командах? Очень сжатые сроки. 
Кто главный помощник в преодолении этого врага? Автотесты. 
Что может быть хуже всего? Когда автотесты не помогают экономить время, а пожирают его. 

Одной из причин этого может являться трудность их написания и поддержки. Из-за множества связей между сервисами и невозможности полноценного независимого тестирования каждого из них, у нас единый репозиторий с общим фреймворком автотестов на python с использованием pytest для всех сервисов торгового бэкенда. В нашем случае это облегчает работу, так как каждая команда имеет возможность переиспользовать код при обращении к соседнему сервису для предустановки данных или проверки результата. 

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

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

• Создаёт сервисы и библиотеки, облегчающие доступ к тестовым данным (например, прокси-сервер, подключающейся к стримам, к которому тесты обращаются посредством http-запросов, когда необходимо проверить получение данных в стриме).

• Производит рефакторинг и оптимизацию кода, решает возникающие технические проблемы.

• Настраивает CI (пример реализованного пайплайна в CI: ru или en).

• Настраивает и пишет линтеры.

• Реализует информативные сообщения о результатах прогона тестов.

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

Словом, сильно экономит время коллегам в проектных командах.

Тест-менеджер как PMA (project manager in agile)

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

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

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

• Продакт-оунер на планировании с командой решает, когда именно, в каком спринте их реализовывать.

Таким образом задачи находятся под общей ответственностью команды, ресурсы, время и приоритеты в командах определяет продакт-оунер, а стратегия тестирования постепенно реализуется. Как и в случае с капасити, выделяемым на поддержку текущего набора автотестов, движение данных задач и скорость их реализации является отличным индикатором баланса dev/qa.

Книжный клуб

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

• Выбираем книгу по наиболее актуальному или “больному” вопросу.

• Определяем график чтения глав для еженедельных необязательных созвонов.

• Обсуждаем прочитанное через призму опыта и ситуаций на текущих проектах.

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

Что классно?

Подведём итоги – что нам нравится? 

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

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

И, вместе с тем, классно профессионально расти. А ещё наблюдать, как тестирование всё больше становится понятным другим членам команды, и подходы и инструменты тестирования становятся общим делом.

Что не очень?

Озвученное выше, конечно же, близкое к идеальному видение того, как должны быть настроены процессы тестирования. Проблемы никуда не деваются и в разных командах время от времени проявляются по-своему. Среди прочего:

1. Превалирование бизнес-задач перед техническими. 

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

2. Отсутствие сбалансированности команд. 

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

3. Мониторинг тестовых окружений. 

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

4. Слабое кросс-командное взаимодействие. 

Компания по-разному решает эту проблему, тестирование со своей стороны пытается идти двумя путями: прицельное отслеживание тех, кому могут навредить изменения функционала, и адресное обращение на взаимодействие с ними, а так же тестовая документация наиболее вероятных путей использования наших платформ. Выделение новой роли тестировщика, который проводит e2e-тесты (backend only) для старых и новых проходящих через все компоненты фич, будет той стеной, которая на ранних этапах выявляет все недоработки. 

Минута рекламы: возможно, именно вы будете тем человеком, который поможет нам решить эти проблемы, в данный момент у нас открыты вакансии тестировщика бэкенда, в том числе в две новые команды! (Вакансии)

Пора закругляться

Редактируя статью, понимаешь, как много можно было бы ещё рассказать, но тогда она разрастётся до неприличия. Однако нужно вовремя остановиться: пусть это будет беглый обзор для знакомства. А в интересующие детали можно погрузиться в комментариях или даже в продолжении, если оно потребуется. Задавайте вопросы, делитесь мыслями, до новых встреч!