Одинокий рейнджер, или как выстраивать тестирование, будучи единственным QA в команде
Привет, читатель! Меня зовут Дмитрий Евсюков, я работаю в Купере старшим специалистом по тестированию. Когда я только пришёл в свою команду, то всё тестировал руками и не мог найти время на автоматизацию. Это приводило к тому, что я не успевал протестировать все задачи в полном объёме и многое откладывалось в техдолг. Сейчас я выработал более умный подход, который помогает мне своевременно разрабатывать автотесты и быстро поставлять функционал на прод без снижения качества.
Думаю, что мой материал будет полезен любому QA, который имеет опыт работы в кроссфункциональной команде.
Кроссфункциональная команда — добро или зло для QA?
Команды в Купере в основном кроссфункциональные. Они состоят из продакта, тимлида, двух-трёх девелоперов и одного QA. Все ключевые роли представлены в одной группе.
Верхнеуровнево у такой структуры есть немало преимуществ. Это и безбарьерная коммуникация, и гибкость, и возможность учиться друг у друга, а следовательно — повышать общую квалификацию команды. Сотрудники видят, как результаты их работы влияют на проект, и за счёт этого более вовлечены.
Однако именно для процесса тестирования у кроссфункциональной структуры есть существенные минусы:
Снижение качества тестирования. Кроссфункциональные команды могут разрабатывать несколько продуктов одновременно. И если наличие двух и более разработчиков позволяет делать это безболезненно, то QA сталкивается с необходимостью постоянно переключать внимание с одного проекта на другой. Тестировщик стрессует и не так вовлечённо и кропотливо работает со списком проверок функционала.
Отсутствие времени на автоматизацию регресса. Вторая проблема исходит из первой. При отсутствии выделенной команды автоматизация тестирования ложится целиком и полностью на QA (если, конечно, у него есть необходимые навыки). Но внедрить автоматизированный регресс бывает затруднительно в условиях дефицита рабочего времени из-за приоритетных задач бизнеса.
Проблемы с тестовой средой. Обойти проблему с настройкой интеграции двух микросервисов тоже нельзя. QA может тратить много времени, чтобы подружить несколько сервисов, в том числе с помощью настройки моков и подготовки тестовых данных. Всё это увеличивает время тестирования и доставки на прод.
Как может действовать QA
Я выделяю четыре классических подхода:
Только ручное тестирование функционала без автоматизации
Test-driven development (TDD)
Перенос разработки API/E2E-автотестов в техдолг
Планирование автоматизации на основе временно́й оценки задачи
Рекомендовать из них я, пожалуй, могу только один. Сейчас расскажу, почему.
Ручное тестирование без автоматизации позволяет QA не иметь знаний по автоматизации (спасибо, Кэп). Но это недолго может быть достоинством. Главный подводный камень тут состоит в том, что для экономии времени приходится покрывать тестами только те кейсы, которые непосредственно связаны с новой бизнес-логикой. Все остальные кейсы при этом пропускаются, а это ключ к багам и инцидентам на продакшене.
TDD — это техника разработки ПО, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Уже лучше, чем тестирование руками, но минусы тоже есть. Такая схемане подходит для команд, которые разрабатывают сразу несколько сервисов или где QA не обладает развитыми навыками автоматизации, чтобы быстро покрывать тест-кейсы автотестами.
Для переноса разработки API/E2E-автотестов в техдолг уже требуется крепкий опыт написания автотестов. Он позволит покрыть регресс автотестами, снизить время на тестирование и повысить качество сервиса. Недостаток заключается в высокой вероятности раздутого техдолга из-за загрузки QA приоритетными задачами.
Планирование автоматизации на основе временно́й оценки задачи нравится мне больше всего. Да, как и в предыдущем пункте, специалист по тестированию должен уметь автоматизировать API/E2E-тесты. Но оно того сто́ит, и моя команда — тому пример.
Нужны ли вам автотесты
Перед тем, как рассказать о том, как устроен процесс автоматизации в моей команде, предлагаю поговорить, зачем вообще нужна автоматизация.
Когда разработчики пишут юнитесты, они покрывают только логику этого метода. Но кто-то должен автоматизировать саму функциональную логику сервиса, то есть бизнес-кейс. Если не вводить автоматизацию, QA будет проводить, можно сказать, частичный регресс. То, какие кейсы могут быть затронуты в той или иной доработке, опирается на усмотрение QA.
Ошибка тем временем может возникнуть абсолютно в любом, даже самом неожиданном, месте. Недостаточно просто проверять конкретный функционал и то, что находится рядом с ним. Желательно полностью покрывать сервис автотестами, и многие крупные компании к этому стремятся.
На мой взгляд, любой команде с большим количеством тест-кейсов нужна автоматизация. Когда у вас больше двух релизов в неделю, без внедрения автотестов очень сложно.
Как мы построили тестирование, чтобы успевать всё
У нас в команде релизы происходят чуть ли не каждый день, поэтому правильное планирование автоматизации очень сказывается на нашей результативности.
Для эффективного совмещения ручного тестирования и автоматизации мы в команде используем подход, который основан на распределении задач по автоматизации в зависимости от story points. (Здесь сразу нужно оговориться, что команда может выбрать для себя любые условные единицы.)
Ранжирование выглядит следующим образом:
Если задача на автоматизацию набирает меньше трёх story points, рекомендуется автоматизировать функционал после этапа ручного тестирования.
Если задача по автоматизации оценена в промежутке от трёх до пяти story points, то рекомендуется разработка в текущем спринте.
Если задача больше восьми story points, рекомендуется перенести её на следующий спринт.
В оценке принимает участие не только QA, но и разработчики. Количество story points зависит как от контекста на конкретном этапе, так и от того, насколько сложными оказались аналогичные задачи в прошлом. То есть, с одной стороны, есть интуитивная оценка задачи в моменте, с другой — она подкрепляется бэкграундом команды.
Первый пункт, когда story points меньше трёх, включает в себя элементы TDD в части написания тестов до фактической выкатки в прод, то есть на этапе тестирования. Другие пункты по сути подразумевает перенос задачи на автоматизацию тест-кейса в техдолг.
Задачи на автоматизацию не ставятся в приоритет. Восемь story points с гораздо большей вероятностью получит задача, которая касается разработки, потому что важнее протестировать функционал руками и выкатить его на прод. Разработчик делает свою часть, я её тестирую, запускаю регресс, используя существующие настройки, а уже в следующем спринте беру в разработку автоматизацию.
Сравнение TDD и предложенного подхода
По сравнительной схеме заметно, что наше решение позволяет комбинировать подходы к написанию автотестов посредством временнóй оценки.
Полная схема работы, которую мы применяем в команде, отображена на рисунке ниже.
Флоу на основе оценки задачи по автоматизации тест-кейса
В зависимости от количества story points мы применяем разные лейблы в Jira. Это помогает оценивать время, потраченное на написание автотестов.
All in all
Современные кроссфункциональные команды требуют от QA не только опыта в мануальном тестировании, но и навыков покрытия тест-кейсов автотестами.
Может казаться, что достаточно ручного тестирования при разработке, однако тогда при расширении функционала сервиса QA уже не сможет достаточно быстро проводить полное, то есть регрессионное тестирование из-за отсутствия автоматизации, а это может повлечь за собой неожиданные баги. Предложенный в моей статье способ может помочь решиться на автоматизацию тестирования и ускорить регресс сервиса.
Буду рад ответить на вопросы в комментариях!
