Привет! Меня зовут Александр, я SDET-специалист в SimbirSoft. В этой статье я расскажу, как можно покрыть разрабатываемую часть проекта автотестами на ранних этапах его разработки, если в команде отсутствуют аналитики и присутствуют задокументированные требования только по основному функционалу. Эта статья будет интересна как джунам, так и техническим специалистам middle и выше, а также руководителям команд (team leads) и техническим лидам (tech leads).
Я поделюсь тем, как в такой ситуации были настроены процессы в нашей команде. Мы работаем над проектом с утвержденной микросервисной архитектурой с внутренними и внешними сервисами. Команда работает по Scrum-методологии и состоит из тимлида, разработчиков сервисов, QA и SDET-специалистов. От заказчика поступила лишь основная информация о том, что должен делать продукт и на каких платформах его можно будет использовать. Именно эта информация и была задокументирована в виде требований.
Содержание
Последовательность действий QA-команды по составлению документации
Как провести анализ тестового покрытия проекта с минимумом требований?
Как распределить обязанности по ведению тестовой документации?
Как создать проект с автотестами в условиях ограниченных требований?
Последовательность действий QA-команды по составлению документации
Итак, для начала разберем план задач для команды:
1. Изучение и тестирование функциональных требований к бизнес-процессам продукта.
2. Выбор техники тест-дизайна и покрытие работы сервисов первыми тестами QA-специалистами.
3. В результате может возникнуть необходимость внесения дополнений к имеющейся документации.
4. Эти дополнения станут предметом обсуждения с командой, а затем с заказчиком.
Стейт-машина и сценарии использования
На этом этапе QA-специалисты могут составить тестовое покрытие работы каждого сервиса, тесты взаимодействия сервисов через отправку и прием сообщений, а также провести тестирование frontend. Для этого им и SDET-специалисту следует понять рабочие процессы и изучить API-документацию проекта.
Для создания первого набора тестового покрытия необходимо понять общий бизнес-процесс работы разрабатываемого продукта, для которого еще не существует тестовой документации. В этом может помочь описание стейт-машины. Данный паттерн позволяет описать взаимодействие сервисов при отсутствии сильной связанности между компонентами кода, находясь при этом в одном из возможных состояний программы и последовательно переходя в следующее состояние (например: этап загрузки файла → этап проверки файла и т. д.).
В нашем примере для web/backend может подойти создание Spring State Machine. В ней будет выполняться основная логика работы программы при взаимодействии с пользователем: загрузка файла → обработка файла → предоставление ссылки на загрузку результата обработки или вывод информации об отмене процесса. Это станет первым этапом создания алгоритма последовательных проверок процесса.
На рисунке ниже представлен бизнес-процесс работы стейт-машины и её переходы между состояниями при возникновении определенных событий. Данный процесс станет предметом обсуждения с командой, в него будут вноситься изменения и дополнения для дальнейшей реализации (например, с помощью библиотеки Spring State Machine, фреймворка Camunda или других инструментов).
После реализации стейт-машины появляется общее понимание работы, и можно приступить к составлению стратегии тестирования.
Стратегия тестирования и план тестирования
В нашей команде работают QA-специалисты, ответственные за создание стратегии тестирования, SDET-специалист может им помочь, особенно если он понимает работу реализованной стейт-машины.
Например, при авторизации в системе пользователя для каждой из ролей имеется определенный набор прав (который впоследствии будет дополняться). Весь набор возможных комбинаций невозможно проверить на определённом этапе без доступа к коду UI тестового стенда, так как он ещё не реализован. Здесь SDET-специалист может провести проверки на backend тестируемой версии на соответствие фактического результата ожидаемому и при положительном результате — включить данную проверку как пройденную в актуальную тестируемую версию. Таких случаев может быть множество, поэтому в стратегии тестирования можно разделить некоторые проверки:
frontend для QA-специалистов
backend для SDET-специалистов
При этом учитываются все виды тестирования, которые могут покрыть автотесты (т.е. тестирования удобства использования изначально предназначено для frontend и т.д.)
Для SDET-специалиста при тестировании backend хорошей практикой будет тестирование каждого отдельного сервиса обертками. Для этого есть 2 варианта:
1. Если у SDET-специалиста нет доступа к backend-коду проекта или он не знает языка программирования backend-кода:
В тестируемом сервисе считаем количество комбинаций входных и выходных данных, на основании этого считаем количество тестов. После покрытия каждого модуля — строим граф их взаимодействия, где отмечаем критические сценарии, основные сценарии и нефункциональные. Проанализировав риски для бизнес-процессов, делаем минимально нужную выборку тестов, расставляем им приоритеты и получаем числовое значения покрытия. Для API-тестирования можно логировать исходящие API-запросы для понимания их общего объема.
2. Если SDET-специалист имеет доступ к backend-коду и понимает его составляющие:
На основании этого он может создавать автотесты на проверку по заранее известным видам и типам входных данных, обязательным и необязательным полям моделей объектов, возможным видам ошибок и разделить эти проверки на обязательные и необязательные. Также это может помочь в API-тестировании при отсутствии API-документации на проекте, так как станут известны адреса и типы запросов при взаимодействии с внешними сервисами.
План тестирования пишется каждый раз на каждый конкретный вид тестирования. Например, у нас есть тест-лист, в котором тесты сгруппированы по единому признаку, в том числе в плане реализации тестирования — и мы конкретно на этот вид/этап/форму тестирования пишем отдельный тест-план.
В результате строится вся тестовая документация:
- стратегия тестирования;
- норматив по обеспечению качества с дефинициями (например, «Результатом процессов контроля качества является репорт. Процесс получения данных о качестве реализуется тестированием»;
- иерархия документации (тест план на какой-то этап со ссылками на тест-планы каждой фазы по индексам);
- тест-листы для каждого тест-плана нижнего уровня;
- тест-репорты после выполнения тестирования.
В итоге при наличии стратегии тестирования мы получаем законченную отчетную единицу — тест-план вместе с тест-лисом и тест-репортом (рис.2). На основании нескольких репортов создается репорт более высокого уровня, где QA-специалист формирует нужные метрики и обязательную оценку/анализ/интерпретацию результатов.
Как провести анализ тестового покрытия проекта с минимумом требований?
Наша команда выделила самые острые вопросы и в процессе обсуждения и ответила на них так:
Нужно ли дополнить требования (если да, то каким образом)?
Скрытый текст
Дополнительную информацию для требований может дать пользователь – специалист в области предназначения продукта или техподдержка по продукту компании.
Какие техники тест-дизайна использовать?
Скрытый текст
Исследовательское тестирование, диаграмма пользовательских ролей, угадывание ошибок и другие техники (зависит от специфики разрабатываемого проекта).
Кто будет заниматься проектированием тестов?
Скрытый текст
Тест-кейсы пишет ручной тестировщик или fullstack (может автотестер, это будет рассмотрено дальше).
Нужно ли тестировать имеющиеся требования?
Скрытый текст
Да, желательно на первичной стадии разработки ПО, когда ещё не написан код.
Добавим еще немного вводных к проекту. Прежде чем приступить к интеграции продукта с внешними сервисами, команда работает над внутренними сервисами, которые общаются друг с другом с помощью брокера сообщений. У команды есть понимание, как должен работать основной функционал (например, авторизация пользователя или заказ товара) и что для этого требуется. UI-версия продукта также разрабатывается, впоследствии она будет дополняться новыми функциями.
Разработчик, прежде чем отправить код на ревью в репозиторий, самостоятельно проверяет сервис на работоспособность, поэтому хорошей практикой будет, если юнит-тесты своих сервисов они будут делать самостоятельно.
Отправка и/или прием сообщений из брокера происходит определенным образом (например, в виде информации JSON-формата), поэтому нужно знать результаты позитивных и негативных проверок (как авторизован пользователь, что должно быть указано в body при отправке/получении сообщения, какие коды ответа, основные и дополнительные headers и т. д.). Тестировщик может написать тесты с отправкой данных через брокер и с проверкой полученных данных.
Всё это должно быть учтено в API-документации, составленной разработчиком сервиса.
Выбор техник тест-дизайна полностью зависит от специфики разрабатываемого проекта. Если SDET-специалист подключился к проекту после QA, то дальнейшее развитие тестовой документации будет проводиться с учетом их выбора техник. Здесь нет предпочтений, главное — наличие связи тестовой документации с требованиями.
Как распределить обязанности по ведению тестовой документации?
Итак, QA-специалисты изучили и дополнили первую документацию, выбрали техники тест-дизайна и создали первые тест-кейсы (возможно, провели первый ручной прогон тестов).
SDET-специалист начинает изучать тестовую документацию и, возможно, обнаружит, что составленные тест-кейсы не оптимизированы для автоматизации. Например, в тест-кейсе, который проверяется на frontend и backend, много шагов с равноценными ожидаемыми результатами, и эти шаги стоило бы разбить на отдельные тест-кейсы. Или тест-сьют не учитывает все возможные виды тестовых данных, кодов ответов, комбинаций входных параметров (или сделан 1 тест-кейс на несколько комбинаций) и так далее. Это приводит к расширению возможного тестового покрытия.
Поэтому важно распределить обязанности по ведению такого вида документации для экономии времени сотрудников на решение возникающих вопросов. Здесь нужно решение тимлида, на какой уровень тестовой документации будет иметь доступ SDET-специалист. В нашем примере будет полезно, если будет доступ к созданию и изменению тест-кейсов, а также составлению баг-репортов. В любом случае ведение тестовой документации является процессом обсуждения QA и SDET на протяжении совместной работы над проектом.
Как создать проект с автотестами в условиях ограниченных требований?
Прежде чем создавать проект с автотестами, SDET-специалисту нужно согласовать с командой, что требуется от автотестов кроме основных функций (кто будет просматривать проект кроме команды, какие виды тестирования он включает и другое). Следует учесть, что тестовых стендов пока нет в наличии, аналитиков на проекте не было и не предусмотрено их появление в будущем. Поэтому имеет смысл выбрать подходящие инструменты и практики для проекта.
Например, для API-тестов заранее подготовить API-спецификации, подумать о размерности возможных тестовых данных (1 килобайт, 1 мегабайт, 100 мегабайт и так далее) и где они будут храниться. Или, если сервисы запускаются с помощью контейнеризации, удобно будет подключить соответствующие плагины в IDE (аналогично с наличием баз данных). После добавления CI/CD на проекте следует учесть возможность многопоточного параметризованного тестирования при выборе тестового фреймворка (заранее задать вопрос команде).
Какие сложности могут возникнуть в процессе создания автотестов без наличия явных требований и способы их решения?
1. Необходимость тестирования при отсутствии требований на верстку
Рассмотрим первую ситуацию на примере тестирования UI, скажем, главной страницы продукта.
После добавления новых тестовых данных в процессе тестирования верстки при изменении размеров экрана может наблюдаться непропорциональное смещение элементов страницы (они становятся ближе друг к другу, часть текста переносится на другую строку и так далее). При этом все элементы отображаются и выполняют свои функции, но с точки зрения пользователя читать текст становится неудобно (в случае с мобильным приложением часть кнопок может закрывать другие кнопки, и их становится труднее нажимать).
Такие моменты должны быть описаны в техническом задании проекта (задача аналитика) и указаны в плане тестирования (задача QA-специалиста). Однако если этого не было сделано, в подобных ситуациях следует составить баг-репорт.
Получается, что автотест проходит заданный алгоритм действий, но при ручном тестировании возникают проблемы для пользователя, либо страница теряет прежнее визуальное восприятие. Это предмет обсуждения с командой. В результате либо автотест становится излишним, либо требования к расположению элементов страницы дополняются и документируются.
В целом, после создания каждого тест-кейса следует добавить ссылку на требование. Это обеспечит однозначное понимание ожидаемого результата.
2. Необходимость тестирования при отсутствии доступа к коду проекта
Рассмотрим вторую ситуацию на примере API-теста взаимодействия сервисов через брокер сообщений.
После выполнения последнего шага автотест был пройден, но тело ответа фактического результата отличается от ожидаемого. Найти причину этого без помощи разработчика невозможно, так как еще не было составлено API-документации на данный запрос. Поэтому является ли ожидаемый результат актуальным, или брокер неправильно обработал сообщение (отправил из другого топика), или сервис сработал по-другому, неизвестно, так как SDET-специалисту не были выданы доступы к коду проекта (у него есть доступ только к проекту с автотестами, над которыми он работает). В случае отсутствия связи с разработчиком остается оформить баг-репорт.
В таких случаях следует уточнить и задокументировать требование до составления тест-кейса.
Как актуализировать требования на уровне команды (по умолчанию, Scrum с QA и разработчиками, нет аналитиков и DevOps)?
Автотесты пишутся на устоявшийся функционал, который был протестирован вручную (для отдельных модулей также проверены создавшими их разработчиками), и на него составлена тестовая документация. Проект встраивается в CI/CD, настраивается график запусков тестов (по триггеру, по расписанию и т.д.) и способ предоставления отчетов о тестировании. В дальнейшем он будет дополняться новыми автотестами.
Если на проекте нет ответственного за актуализацию требований и CI/CD еще не настроен, то тестирование и автотестирование становится проблематично. При внесении изменений в процессе разработки автотесты будут падать по непонятным причинам, так как отсутствует отслеживаемость ожидаемого результата. Количество упавших в таких случаях тестов заранее неизвестно. Поэтому требования нужно актуализировать на уровне всей команды. В этом поможет ведение документации каждой ветки каждого сервиса в репозитории, наличие инструкции по запуску и настройке и, самое главное, истории изменений. Необходима постоянная коммуникация между всеми участниками процесса разработки по каждым возникающим вопросам касательно требований к проекту.
Со временем часть тестовой документации может потерять актуальность, и ее заменит другая документация. Новый человек в команде сможет быстрее пройти онбординг, если поддерживать документацию в актуальном состоянии. До появления тестовых стендов SDET-специалист сможет тестировать наиболее актуальную сборку проекта на своей локальной машине и в случае, если самые актуальные изменения одного из сервисов находятся не в ветке разработки (в ветке одной из фич), то это будет учтено согласно документации.
Вывод
В заключение хотелось бы сказать, что работа над проектом с минимумом задокументированных требований и отсутствием специалистов по аналитике и DevOps вызывает дополнительные трудности. Так как каждый участник процесса выполняет свою часть работы, то он может не увидеть актуальные изменения в разработке всего проекта и поэтому тратить время на решение трудностей из-за неучтенной информации.
Из этого можно сделать вывод, что здесь важно усилие всей команды для ведения и дополнения документации, в том числе и тестовой. В качестве решения поможет создание командой разработчиков документа с описанием процесса внутри команды, содержащим Gitflow, информацию о работе с карточкой задания (когда делать мерж после ревью кода, когда тестирование в зависимости от статуса карточки и другое). SDET-специалисту при составлении проекта автотестов следует учесть все нюансы состояния документации и при необходимости помочь коллегам в актуализации требований. В дальнейшем это приведет к сокращению количества исправлений, а возможно, и к полному их отсутствию.
Спасибо за внимание! Подписывайся на наши соцсети и блог, где мы публикуем другие полезные материалы, в том числе и для SDET-специалистов: