Платформа автоматизации гибкого тестирования
Томас Гамильтон
⚡ Умное резюме
Автоматизация тестирования в рамках гибкой методологии предполагает использование автоматизированных проверок в коротких спринтах, где требования меняются еженедельно, и набор тестов, разработанный для стабильного выпуска по каскадной модели, быстро превращается из системы безопасности в бремя обслуживания.
Гибкое автоматизированное тестирование
Гибкое автоматизированное тестирование Это практика использования автоматизации тестирования в рамках гибкой методологии разработки программного обеспечения. Ее цель — сделать разработку программного обеспечения более эффективной и результативной, одновременно обеспечивая качество и контролируя время и ресурсы, затрачиваемые на выпуск релиза. Поскольку тесты пишутся параллельно с разработкой функционала, эта практика в значительной степени зависит от координации между разработчиками и тестировщиками.
С тех пор как методология Agile поставила перед собой цель избавиться от трудоемких реалий каскадной модели, ее влияние ощущается во многих областях. автоматизация тестирования Также. Эти две дисциплины необходимо сочетать целенаправленно:
.jpg)
Автоматизация в каскадной модели разработки против автоматизации в гибкой методологии разработки.
В традиционном цикле тестирования программного обеспечения автоматизированное тестирование становится возможным после того, как приложение готово. стабильная и требования выполнены. Предполагается, что значительное количество времениЭто требует высококвалифицированных специалистов по автоматизации и значительных затрат на настройку. Основная цель — снижение затрат в долгосрочной перспективе и подтверждение отсутствия новых дефектов в существующих тестовых сценариях.
Автоматизированное тестирование по своей природе не является исследовательским.Потому что его главная роль — экономия времени и снижение затрат. Он не предназначен для выявления новых и инновационных дефектов. Автоматизированное тестирование в основном подтверждает уже существующее поведение.
Таким образом, эти два варианта предъявляют совершенно разные требования к набору тестов:
| фактор | Автоматизация в каскадной модели | Автоматизация в Agile |
|---|---|---|
| Состояние приложения | Стабильная и утвержденная версия перед началом написания скрипта. | Изменения происходят на каждом спринте, часто в процессе написания скриптов. |
| Время доступно | Специальный этап автоматизации | Всё, что поместится в рамках спринта продолжительностью от одной до четырёх недель. |
| Кто пишет сценарии | Отдельная группа специалистов по автоматизации | Команда разработчиков, тестировщики и разработчики вместе |
| Главная цель | Снижение затрат в долгосрочной перспективе по результатам большого набора регрессионных моделей. | Быстрая обратная связь по только что созданному приращению |
| Риск технического обслуживания | Низкий уровень, потому что требования меняются медленно. | Высокий, потому что требования постоянно меняются. |
Как автоматизировать процессы в гибкой методологии
По своему определению, методология Agile избавляет от утомительной документации, позволяя быстро внедрять новые идеи и обеспечивая свободное взаимодействие между людьми. Она отдает предпочтение исследовательской работе, а не бумажной волоките.
Между фундаментальными принципами методологии Agile и автоматизированного тестирования существует реальное противоречие. Agile-команды решают его, сужая область автоматизации, а не уменьшая её: проверки пишутся в том же спринте, что и функция, переносятся на уровень модульного тестирования и API, где их поддержка обходится дешевле всего, и запускаются при каждой сборке.
Фундаментальные моменты автоматизации гибкого тестирования
Прежде чем выделять ресурсы спринта на автоматизацию, взвесьте факторы, определяющие возможность завершения работы над скриптом:
- Время на проектирование и написание кода: Каждый скрипт должен быть разработан, закодирован и проверен так же тщательно, как и рабочий код.
- Проверка на основе тестовых данных: Готовый скрипт необходимо проверить с помощью существующих тестовых данных, прежде чем ему можно будет доверять.
- Цель теста: Функциональные и регрессионные тесты требуют разных затрат на обслуживание и имеют разный срок годности.
- Sprint длина: Спринт длится от одной до четырех недель, чаще всего две, что редко оставляет место для масштабной работы над сценарием.
Второй фактор — изменение требований. Agile, по определению, — это метод реагирования на изменения, инициированные заказчиком, поэтому он допускает частые корректировки на протяжении всего процесса разработки.
Автоматизированное тестирование, напротив, наиболее полезно для стабильных требований. Оно плохо подходит для постоянных изменений, характерных для гибкой методологии разработки, поэтому выбор того, что автоматизировать, имеет большее значение, чем количество автоматизируемых операций.
Гибкие инструменты автоматизации
Выбор соответствующего инструмент автоматизации Еще одним важным фактором при внедрении автоматизированного тестирования в рамках гибкой методологии является наличие лицензированных инструментов автоматизации. Например, лицензированные инструменты автоматизации устанавливают строгие критерии доступа к ресурсам для различных типов и уровней пользователей, что ограничивает круг лиц, имеющих доступ к ресурсам, используемым в рамках данной системы автоматизированного тестирования.
В отличие от этого, гибкая методология делает акцент на открытом сотрудничестве и свободном взаимодействии между членами команды. Ограничительные политики доступа препятствуют такой сплоченности и могут привести к результатам, которые не способствуют успеху проекта.
Приоритетной задачей является создание качественных скриптов автоматизации в рамках времени, отведенного на Agile-процесс. Необходимо тщательно отбирать тестовые примеры, чтобы полученные скрипты можно было использовать повторно в дальнейшем и при этом завершить разработку в отведенное время.
Даже в гибкой методологии разработки некоторые тесты все равно необходимо проводить — в частности, регрессионные тесты. В следующем разделе рассматриваются ситуации, в которых подходит автоматизированное тестирование, и то, как каждая из них соотносится с гибким тестированием.
Автоматизация тестирования Concepts Применение в Agile
В таблице ниже представлены семь классических условий, оправдывающих автоматизацию тестирования, и дается ответ для каждого из них в рамках Agile-методологии. Только три из них легко вписываются в Agile-спринт, и все три имеют форму регрессии:
| # | Концепция автоматизированного тестирования | Ответ на вопрос о методологии Agile |
|---|---|---|
| 1 | Тест необходимо часто повторять. | Именно здесь вступает в игру концепция регрессионного тестирования. |
| 2 | Процесс тестирования и его валидация постепенно развиваются и меняются с течением времени. | Не подходит для гибкого тестирования, поскольку гибкое тестирование подразумевает частые изменения требований. |
| 3 | Тест проверяет работоспособность бизнес-процесса или рабочего процесса, а не внешний вид, цвет или расположение элементов в таблице. | Данный сценарий можно отнести к задачам ручного тестирования. |
| 4 | Результаты теста предоставляются регулирующему органу, который требует электронной регистрации и архивирования этих результатов в качестве официального подтверждения соответствия требованиям. | Не подходит для методологии Agile, поскольку исчерпывающий уровень документации не является её частью. |
| 5 | Тестирование очень монотонно или включает в себя множество этапов, которые необходимо выполнять каждый раз совершенно одинаково, поэтому необходимо избегать утомления оператора при выполнении ручного тестирования. | Не подходит для методологии Agile. |
| 6 | Результат теста (пройден или не пройден) достаточно легко определить и зафиксировать с помощью выбранного инструмента автоматизации. | Подходит для регрессионного тестирования в рамках гибкой методологии разработки, требующего повторяющихся и трудоемких действий. |
| 7 | Для проведения теста необходимо ввести в приложение значительный объем данных. | Может быть использовано в качестве регрессионного анализа. |
