Поддержка нужна
Как тестировщик программного обеспечения, вы являетесь контролером качества. Ваши тестовые наборы (свиты) — это ваше оружие, обеспечивающее надежность программного кода, создаваемого вашей dev-командой. Когда приложение растет и развивается, фичи добавляются, и свиты превращаются в запутанный комок из устаревших тест-кейсов, которые уже ничего не верифицируют, а наоборот еще добавляют сложности. Тогда должно помочь обслуживание (или «поддержка») и рефакторинг кода автотестов. Далее рассмотрим методы, которые помогут сохранить гибкость и эффективность тестовых наборов по мере развития приложения.
Поддержка важна
По мере усложнения приложения меняются его функциональные возможности, интерфейсы и код. Если ваши тест-кейсы не будут развиваться вместе с приложением, вы рискуете пропустить на прод критические проблемы, получить много ложных «красных» и потерять на этом время. Правильное обслуживание тестов гарантирует, что они останутся надежными и актуальными, обеспечивая хорошую обратную связь с разработчиками.
Важность рефакторинга
Рефакторинг применяется не только к коду тест-кейсов, но и на более высоком уровне, к тестовым наборам. При рефакторинге тестовых наборов улучшается (должна улучшаться) их структура, читаемость и удобство, без изменения их поведения. Таким образом, тест-кейсы в составе набора становятся более понятными, обновляемыми и расширяемыми.
Техники
Регулярные проверки и чистки
Выделите время для регулярного анализа свитов. Не ленитесь искать и удалять лишние, устаревшие и неэффективные тест-кейсы. Компактный набор тестов легче поддерживать, и так быстрее получать обратную связь.
Например, у вас тестовый набор для магазина, и вы заметили, что в нем есть несколько тест-кейсов, связанных с уже неподдерживаемой функцией Wishlist. Эти тест-кейсы уже неактуальны, их наличие в свите загромождает его и приводит к нерациональному использованию ресурсов. В ходе регулярного анализа вы находите и удаляете подобное, чтобы оптимизировать свит.
Модуляризация тест-кейсов
Разбивайте сложные тест-кейсы на более мелкие и реюзабельные. Это делает тест-кейсы контролируемыми и уменьшает дублирование их кода. При изменении функции обновится только один нужный модуль.
Например, функция «вход в систему», которая тестируется в нескольких сценариях. Вместо того чтобы дублировать шаги по входу в систему в каждом тест-кейсе, можно вынести тестирование логина в отдельный модульный тест-кейс «Login», который и будет обрабатывать процесс входа в систему и только этим. Затем вы ссылаетесь на этот модуль в других тестовых сценариях, таких как «Покупка залогиненного пользователя» или «Изменение пароля». При изменении процесса входа в систему будет достаточно обновить один этот модуль «Login», и все связанные тест-кейсы в свите без проблем «примут» обновление.
Параметризация
Изучите и применяйте параметризацию, чтобы сделать тест-кейсы гибкими. Вместо хардкодинга значений параметризируйте их, что позволит запускать один и тот же тест-кейс с различными входными данными.
Например, это может помочь в частом случае тест-кейса отправки формы регистрации пользователя. Вместо того чтобы хардкодить имя пользователя, адрес почты и пароль, просто параметризируем их. Создаете переменные для этих входов и определяете несколько наборов значений, например: {«user1», «user1@email.com», «password123»} и {«user2», «user2@email.com», «pass456»}. Затем тест-кейс задействует эти параметризованные значения, позволяя запускать один тест с различными комбинациями данных.
Контроль версий тестового кода
Как и код собственно приложения, тестовый код тоже, в идеале, должен находиться под version control. Что позволит лучше отслеживать его изменения и при необходимости откатиться к предыдущей версии.
Каждый раз, внося изменения в тестовый код, можно коммитить их в Git. Предположим, что реализация новой функции затронула несколько тест-кейсов, и после начала тестирования возникли проблемы. Изучив историю коммитов в Git, можно определить, какие изменения кода привели к проблеме, и при необходимости быстро вернуться к более стабильной версии тестового набора.
Документация
Ведите четкую и актуальную документацию по тест-кейсам. Эта документация должна включать цели тестирования, ожидаемые результаты и конфигурации.
Представим себе следующее: есть тест-кейс, проверяющий оформление заказа в магазине. Вместе с тест-кейсом вы ведете подробную документацию, описывающую ожидаемое поведение, предварительные условия (например, заполненная корзина) и все конфигурации (например, использование тестовой кредитной карты). Документация помогает всем, кто проверяет или выполняет тест-кейс, понять его цель и требования.
Стратегия регресса
Реализуйте стратегию подбора регрессионных тестов. Сосредоточьтесь на тестировании наиболее критичных областей, затронутых последними изменениями, чтобы сократить объем тестирования и сэкономить время.
Вместо того чтобы запускать весь свит с десятками кейсов и потом в них разбираться, вы реализуете стратегию выборочного регресса. Определяете критические области, претерпевшие обновление, и запускаете только тесты, которые имеют отношение к этим областям. Такой целенаправленный подход позволит сэкономить время без потери качества.
