Модульное тестирование в современных командах

Для кого эта статья?

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

Для каких команд это подойдёт?

Я хотела бы показать вам процесс внедрения модульного тестирования для 2-х типов команд. В командах, которые работают по гибкой методологии и в командах, которые выбрали для себя каскадный стиль работы.

Ниже на диаграмме показано схематическое устройство команд по ролям:

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

Чем модульное тестирование отличается от обычного?

Теперь хотелось бы рассказать что же такое модульное тестирование и как это реализовано в нашем случае:

Начну с того, что специалистами модульного тестирования являются эксперты в своих областях (под этим чаще всего понимается конкретная система). Они обладают широчайшим бэк граундом и необходимыми техническими навыками. Каждая система требует своих знаний, где-то это экспертные знания Pl/SQL, где-то конкретных языков разработки, а где-то только многолетний опыт работы с конкретной системой. Мы не затрагиваем front-end системы. Мы стоим на страже систем middle и back уровней.

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

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

И второе — это существенное снижение времени на тестирование доработки за счет экспертизы. Интеграционное тестирование смотрит фичу целиком, мы же рассматриваем ее по частям. Какие задачи решает модульное тестирование? Исходя из всего вышесказанного можно подвести черту и ответить на вопрос: какие же задачи решает модульное тестирование?

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

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

Польза внедрения модульного тестирования

После прочтения всего этого возникнет вопрос, а какие плюсы от внедрения модульного тестирования можно получить? Ранее я привела 2 схемы работы команд, и теперь опишу применительно к каждой из них:

Команда, работающая по аджайл методологии. Ниже на схеме приведено место модульного тестирования в команде такого типа:

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

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

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

При наличии в команде модульного тестирования автоматизатора (а он у нас есть!), на выходе мы также получаем автоматизированные модульные тесты! Это может быть набор тестов на каком либо выбранном тестовом фреймворке, либо набор скриптов, которые объединены в единый пак и вызываются по требованию/расписанию. Далее эти тесты включаются в некий регресс пак, который содержит в себе и автоматизированные модульные тесты и тесты отдела автоматизации (чуть позже мы рассмотрим, чем они отличаются) и прогоняется перед выводом задач спринта на бой. Что он нам дает думаю ясно и без моих пояснений.

Также допускается, подключение интеграционного тестированию параллельно с модульным тестированием. Пока команда тестирования через фронтовые системы дойдет до middle или back систем, тестирование будет выполнено уже более чем на 70-80%. Т.е. никаких простоев, связанных с необходимостью правки кода, у них не будет. Это что касается аджайл-команды.

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

Тут мы видим, что интеграционное тестирование начинается после окончания модульного. Это основное и принципиальное отличие от уже рассмотренного варианта. Пока задача не ушла с модульного тестирования, интеграционное тестирование не начинается. Готовятся тестовые сценарии, тестовые данные.

В остальном процесс не меняется, те же данные на выходе и те же плюшки, что и в agile командах.

Чуть выше я обещала поговорить о том, чем же отличаются автоматизированные модульные тесты, от автотестов команды автоматизации. Отличие очень простое и на поверхности. В 99% команда автоматизации автоматизирует не конкретную доработку, а процесс.

Рассмотрим на примере запроса информации по карте через интернет банк. Команда автоматизации пишет кейс на уровне фронта (логин/переход на вкладку/выбрали карту/нажали кнопку запросить баланс) Все мы знаем сколько по времени будет выполняться такой тест. А на выходе мы получим либо есть информация, либо ее нет. В очень редких случаях мы получим понимание в какой системе/каком функционале произошла ошибка.

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

Как внедрить модульное тестирование?

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

Для начала нужно принять как данность, что не все понимают что вообще за зверь — модульное тестирование. Необходимо провести некоторую разъяснительною работу среди команды и доступно изложить всё то, что рассматривалось выше по поводу отличий такой команды от классических тестировщиков.

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

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

1. Найденные на этапе модульного тестирования дефекты. (тут можно провести аналогии с ранее найденными дефектами того же уровня и показать разницу во времени простоя команды до момента их устранения)
2. Качество переданного в интеграционное тестирование функционала.
3. Реакцию разработчиков, с которыми будут говорить на понятном им языке.
4. В случае добавление в процесс модульного тестирования автоматизации — готовые автоматизированные модульные тесты, позволяющие в будущем уйти от части ручных проверок функционала.

Заключение:

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

1. Сократить количество пропущенных дефектов.
2. Ускорить процесс вывода нового функционала до конечного пользователя.
3. Амортизировать процесс взаимодействия между командами ручного тестирования и разработкой.
4. Создать и поддерживать накопительную базу низкоуровневых автотестов, не зависящих от изменений интерфейсной части.

ссылка на оригинал статьи https://habrahabr.ru/post/317788/