Всё по плану. Как автоматизировать тестирование ПО с минимальными рисками

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

План как первооснова

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

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

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

Цель проекта: для чего мы это делаем

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

Итак, цель проекта должна быть четкой (не должно быть разных вариантов прочтения), измеримой (ее можно посчитать в каких-либо единицах – тест-кейсах, минутах и т. д.) и достижимой. То есть на начальном этапе цель не должна звучать как что-то нереальное или обобщенное. Например, "улучшить качество продукта" – неудачная цель, поскольку она не говорит нам о том, что конкретно и в какие сроки нужно сделать, в чем измерять это качество. Более точный и понятный вариант: "сократить время проведения 100 регрессионных тестов на каждом релизе на 48 часов".

На встрече с заказчиком мы знакомим его с подготовленным планом: что будем делать, где и как как будем согласовывать промежуточные цели, а главное – в чем заключается итоговая цель внедрения автоматизации тестирования. Фиксировать эти договоренности, промежуточные итоги и временные рамки можно по-разному: в системе управления проектами типа Jira или Confluence, в обычной почтовой переписке. Таким образом, после каждого этапа мы делаем синхронизацию плана с заказчиком и получаем подтверждение, что он удовлетворен результатами.

Изучение особенностей проекта

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

Во-первых, это сам продукт, который предстоит тестировать: клиент-серверное приложение, СУБД, мобильное приложение, сайт или что-то другое. Для разных видов ПО важны разные виды проверок. Например, в мобильном приложении мы, скорее всего, будем тестировать API и UI. Значит, нам нужны тесты, которые умеют посылать запросы и оперировать графическим интерфейсом.

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

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

Во-вторых, это команда, участвующая в проекте: ее структура, роли участников, а также действующая методология – SCRUM, Канбан, другие agile-методологии или классический Waterfall. Методология поможет понять, какой жизненный цикл стоит выбрать для автотестов.

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

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

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

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

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

В-пятых, это жизненный цикл продукта и CI/CD процессы. Автотестирование тесно связано с CI/CD, поэтому важно изучить, какие инструменты и DevOps-практики используются в проекте. Автотесты должны быть способными их поддерживать. Чем раньше в жизненном цикле мы будем запускать тесты, тем раньше мы будем находить ошибки, и тем проще будет их исправлять. Например, если мы тестируем бэкенд, то можем запускать автотесты на проверку его методов сразу при сборке продукта в виде юнит-тестов.

После изучения каждой группы особенностей нужно рассмотреть их в целом, чтобы принять окончательное решение на основании совокупности факторов. Например, зная специфику команды, тестовой стратегии и продукта, можно описать жизненный цикл автотеста, а зная технологии и СI/CD – подобрать инфраструктуру для него. И, конечно, абсолютно все особенности будут влиять на выбор технологий и фреймворка для автотестов.

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

Разработка пилотной версии фреймворка

На данном этапе команде нужно выбрать набор автотестов, реализовать минимальную функциональность фреймворка для запуска выбранного набора, организовать инфраструктуру и продумать формат предоставления результатов тестирования. В результате выявляются проверенные автотесты, которые гарантированно пройдут все этапы жизненного цикла и CI/CD процессы.

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

Оценка трудозатрат

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

Например, наша цель – автоматизировать 100 тестов за год (примерно 240 рабочих дней) при условии, что один тест автоматизируется за один день силами одного специалиста. На изучение особенностей проекта и разработку пилотной версии мы тратим примерно 20 рабочих дней, на встречи и согласования – 30. Закладываем риски: 30 дней на отпуск сотрудника, 10 на больничные, 20% (30 дней) на непредвиденные риски: отключили интернет, сломалось оборудование, произошел форс-мажор. В итоге у нас остается 120 рабочих дней на разработку. Мы понимаем, что один автоматизатор, тратя один день на один автотест, может даже увеличить итоговую цель внедрения – до 120 тестов за год. А если изначальная цель более высокая – например, не 100, а 200 тестов, нужно корректировать ее или увеличить количество автоматизаторов.

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

Подходим к финалу

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

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

Выводы

Когда-то наша команда разрабатывала ПО для базовых станций сотовой связи. Нам нужно было реализовать автотестирование отдельного модуля для прохождения государственной аттестации – набора четких критериев, под каждый из которых следовало написать отдельный тест. Таким образом, у нас был определен готовый набор тестов, и мы точно знали, что они должны делать. Команда была сработавшаяся и состояла из универсальных инженеров, знакомых с тестировкой и разработкой. Были налажены CI/CD процессы, выстроен жизненный цикл продукта. Мы сразу отсекали предложения, которые больше нравились отдельным членам команды, и руководствовались только общей оценкой продукта и итоговой целью. Это позволило нам создать стабильную систему автотестирования, разбить весь объем задач на отдельные подзадачи и последовательно идти к цели.

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

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