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

Немного о команде. Мы интегрируем локальных платежных провайдеров, т.е. подключаемся к их API и проводим платежи через них, это позволяет нашим клиентам пополнять баланс на нашей платформе и выводить деньги. Это критически важная часть бизнеса всей компании, так как от скорости и качества нашей работы зависит стабильность и рост денежного потока в компанию. В команде у нас 7 системных\бизнес аналитиков, 8 разработчиков и 3 тестировщика, при этом рост команды еще продолжается. Как видно, тестировщиков меньше всего, поэтому важность построения QA процессов критична для нас, так как без хороших процессов такой поток задач будет застревать на тестировании или тестирование будет вообще пропускаться.

Тестирование включено в оценку работ по задаче

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

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

У нас в команде есть максимальный срок интеграции нового провайдера - это 15 дней. В эти 15 дней задача проходит 4 стадии, две из которых тестирование: системный анализ, разработка, тестирование на деве и тестирование на проде. Другие типы задач либо проходят такой же полный цикл, либо включают как минимум одну из стадий тестирования.

Приемочные (Acceptance) критерии определены в задаче до начало работ

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

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

Например, в нашей команде недостаточно просто протестировать решение и перевести задачу в Done, у нас есть еще один статус после - это Live, т.е. открытие решения на пользователей. Перед этим мы должны подготовить необходимые документы для службы поддержки, предупредить остальные отделы об открытии и т.д. Чтобы не забыть все это сделать мы создали чек лист, где указаны все эти дополнительные активности, которые мы должны сделать на каждом этапе при движении задачи. Это нас защищает от человеческой забывчивости, так как есть большая вероятность что-то не выполнить. Также у тестировщиков есть два чек листа для тестов на деве и проде, где подробно описаны необходимые проверки. В этих чек листах зафиксированы проверки, которые нельзя или очень дорого автоматизировать. Например, в чек листе для прода есть пункт про сравнение статуса и комиссий тестовой транзакции у нас и у провайдера. Мы проверяем это в личном кабинете провайдера, так как если будут расхождения, то будущие отчеты наши и провайдера по транзакциям и балансу будут расходиться, что в конечном счете приведет к убыткам нашей компании.

“Встреча трех амиго”. Определение объема работ до начала работ и ревью результата

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

Встреча до начала работ

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

В команде, мы проводим так называемое “ревью аналитики”. Оно заключается в том, что создается созвон на всю команду, или хотя бы на разработчика и тестировщика, кто будет реализовывать решение, где идет обсуждение API провайдера и его особенностей, требований к интерфейсу и флоу. На встрече мы не обсуждаем тесты и приемочные критерии, так как нам удалось стандартизировать и объединить документацию аналитика с QA так, что она и есть описание кейсов которые нужно автоматизировать и проверить. А многие дополнительные активности мы давно прописали в чек листах и выполняем их по ходу продвижения задачи.

Встреча перед релизом на прод (демо)

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

• получившийся результат соответствует изначальной идее и требованиям?

• на сколько текущие баги или недоработки критичны и можем ли мы выпускать продукт с ними?

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

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

Документирование процесса релиза и пострелизной активности

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

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

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

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

Реализация Unit тестов

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

Если покрытие юнит тестами будет расширяться, то это даст большую уверенность разработчикам, что код работает как задумано и будет меньше багов при end-to-end тестировании. Также это уменьшает количество end-to-end тестов, как как часть проверок можно легко отдать на уровень юнит тестов. К тому же, многие современные хостинг системы хранения кода, такие как GitLab, Github и другие, имеют встроенный функционал по измерению покрытия кода юнит тестами и возможность блокирования pipeline сборки, если покрытие снизилось. Все это настроить и сделать жестким правилом не составляет большого труда.

Автоматизация ручных проверок

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

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

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

Запуск автотестов в CI

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

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

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

Разработчики тоже пишут автотесты

Обязанности Quality Assurance инженера можно рассматривать, как обеспечение качества на всех этапах, а не только на этапе тестирования. Современный QA инженер - это как Devops, он организует процессы, интегрирует необходимые инструменты, реализует тестовый фреймворк, консультирует и привносит лучшие практики как эксперт в тестировании, т.е. обеспечивает всем необходимым команду для обеспечения лучшего качества выходного продукта на всех этапах.

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

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

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

Итоги

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

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

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