Создание автоматизированных тестов даже без пользовательского интерфейса
Автоматизация обычно разрабатывается с отставанием как минимум в один спринт.
Код разработки, написанный для функции сейчас, может быть рассмотрен для автоматизации только в предстоящем спринте.
На разработку уйдет всего несколько недель, после чего сборка будет передана команде тестирования. Тестировщики начинают писать тестовые сценарии или код для выявления ошибок и других затронутых областей, сообщают о них команде разработчиков, исправляют их и снова возвращают для тестирования (регрессионное тестирование). Все это в одном цикле спринта, который должен произойти в течение недели или двух, как и планировалось.
Поскольку циклы выпуска становятся короче, а требования в Agile и DevOps постоянно меняются, становится необходимым автоматизировать регрессионное тестирование.
Кроме того, по мере того как команда разработчиков добавляет в программное обеспечение новые функции, тестер может по-прежнему работать над старой функцией и не сможет продвигаться вперед с той же скоростью, что и разработка. Эта задержка также может быть вызвана задержкой доступности приложений в некоторых случаях.
Выполнение регрессионных тестов после развертывания сборки — не лучший подход для соответствия методологиям Agile/CI/CD, и невыполненные работы по регрессионному тестированию не следует переносить на следующий спринт.
Но Agile не оставляет времени между завершением разработки и тестированием.
Тогда как нам идти в ногу с Agile, обеспечивая качество на скорости?
Представляем автоматизированное тестирование в спринте!
Что мы могли бы сделать, так это автоматизировать пользовательские истории в рамках спринта наряду с разработкой, автоматизировав модульные тесты, тесты API и часть тестов пользовательского интерфейса и оставить сопоставление пользовательского интерфейса. Короче говоря, выполняйте автоматизированное тестирование в спринте.
Когда пользовательский интерфейс будет близок к завершению, вы можете заполнить незаполненные поля. Это гарантирует, что тесты будут полностью автоматизированы вместе с разработкой и готовы к запуску через конвейер непрерывной интеграции без каких-либо задержек.
Самая большая проблема при внедрении автоматизации тестирования In-Sprint заключается в автоматизации модульного тестирования, тестирования API и тестов пользовательского интерфейса для различных типов приложений, таких как веб-мобильные и нативные приложения и службы API, в зависимости от потребностей вашего приложения.
Давайте рассмотрим несколько проблем регрессионного тестирования:
1. Выявление соответствующих тестовых случаев с изменение кода
2. Члены команды выполняют спринт как мини-водопады что не лучший подход, поскольку вы не можете делать что-то параллельно.
Особенно сложно выполнять Регрессионное тестирование в браузерах и на устройствах с разным разрешением и размером экрана. Управление наборами данных и переменными, специфичными для среды, которые могут изменяться в нескольких средах выполнения на каждом этапе, таком как разработка, тестирование, подготовка, производство, также имеет решающее значение, но было бы лучше, если бы они могли храниться в репозитории объектов, который можно было бы использовать в разных средах.
3. Регрессионные тесты необходимо запускать после каждой итерации разработки.
Конвейер доставки должен автоматически запускать регрессионные тесты всякий раз, когда выполняется успешная сборка, чтобы уменьшить разработка/тестирование завершено зазор.
4. Методология Agile позволяет изменять требования даже на поздних этапах разработки. Скрам-команды должны быть готовы к позднему изменению требований.
Когда требования меняютсяособенно к концу спринта, и конкретная функциональность не была протестирована должным образом, команда должна принять обоснованное решение о выпуске функции или переносе ее на следующий спринт, исходя из критичности этой функции/функции.
5. Отсутствие Единое решение также является большой проблемой при автоматизации нескольких приложений в рамках одного проекта. Работа над несколькими инструментами для автоматизации различных типов приложений требует много времени и усилий.
С In-sprint, с новой функцией, автоматизированной вместе с завершением кода, будет достаточно хорошее покрытие с первой сборки. Поскольку тесты почти готовы на ранних стадиях, регрессионные тесты можно запускать раньше и чаще.
Контрольный список для автоматизации тестирования в спринте и внедрения DevOps
1. Платформа автоматизации тестирования, поддерживающая сквозное тестирование, включая модульное тестирование, тестирование API и пользовательского интерфейса.
2. Команда с набором навыков, который соответствует структуре и выбранному инструменту
Настройка инфраструктуры DevOps с нужным набором инструментов (например, Jenkins, Docker и т. д.)
3. Внедрена автоматизация сборки, и конвейер непрерывной интеграции готов к непрерывной интеграции.
Вот практическое руководство, которое объясняет, как Автоматизация тестирования в спринте выполняется вне зависимости от доступности приложения.
Автоматизация тестирования в спринте для регрессионного тестирования со скоростью DevOps
Проблемы автоматизации тестирования в спринте для регрессионного тестирования
Преодоление проблем автоматического регрессионного тестирования в Agile
