Что такое гибкое тестирование?
AGILE TESTING - это практика тестирования, которая следует правилам и принципам гибкой разработки программного обеспечения. В отличие от метода водопада, Agile-тестирование может начинаться в самом начале проекта с непрерывной интеграцией между разработкой и тестированием. Методология Agile Testing не является последовательной (в том смысле, что она выполняется только после фазы кодирования), а непрерывна.
В этой статье мы обсудим
- План тестирования Agile.
- Стратегии гибкого тестирования.
- Квадрант гибкого тестирования.
- Проблемы контроля качества при гибкой разработке программного обеспечения.
- Риск автоматизации в гибком процессе.
План тестирования Agile
План тестирования Agile включает типы тестирования, выполняемые в этой итерации, такие как требования к тестовым данным, инфраструктура, тестовые среды и результаты тестирования. В отличие от каскадной модели, в гибкой модели план тестирования составляется и обновляется для каждого выпуска. Типичные планы тестирования в Agile включают:
- Объем тестирования
- Новые функции, которые проходят тестирование
- Уровень или типы тестирования в зависимости от сложности функций
- Нагрузочное тестирование и тестирование производительности
- Рассмотрение инфраструктуры
- План смягчения последствий или рисков
- Ресурсы
- Результаты и вехи
Стратегии гибкого тестирования
Жизненный цикл гибкого тестирования состоит из четырех этапов
(а) Итерация 0
На первом этапе или итерации 0 вы выполняете задачи начальной настройки. Он включает в себя определение людей для тестирования, установку инструментов тестирования, планирование ресурсов (лаборатория тестирования удобства использования) и т. Д. Следующие шаги должны быть выполнены в итерации 0.
а) Создание бизнес-обоснования проекта
б) Установите граничные условия и объем проекта.
c) Обозначьте ключевые требования и варианты использования, которые приведут к компромиссам при проектировании.
г) Обозначьте одну или несколько архитектур-кандидатов.
д) Определение риска
е) Оценка стоимости и подготовка предварительного проекта
(б) Строительные итерации
Второй этап методологии гибкого тестирования - это итерации построения, большая часть тестирования происходит на этом этапе. Этот этап рассматривается как набор итераций для построения приращения решения. Для этого на каждой итерации команда реализует гибрид практик из XP, Scrum, Agile-моделирования, гибких данных и т. Д.
При построении итерации гибкая команда следует практике приоритетных требований: на каждой итерации они берут наиболее важные требования, оставшиеся из стека рабочих элементов, и реализуют их.
Итерация построения подразделяется на две: подтверждающее тестирование и следственное тестирование. Подтверждающее тестирование концентрируется на проверке того, что система выполняет намерения заинтересованных сторон, как описано команде на сегодняшний день, и выполняется командой. В то время как следственное тестирование обнаруживает проблему, которую подтверждающая команда пропустила или проигнорировала. При следственном тестировании тестировщик определяет потенциальные проблемы в виде историй о дефектах. Следственное тестирование касается общих проблем, таких как интеграционное тестирование, нагрузочное / стресс-тестирование и тестирование безопасности.
Опять же, для подтверждающего тестирования есть два аспекта: тестирование разработчика и гибкое приемочное тестирование . Оба они автоматизированы, чтобы обеспечить непрерывное регрессионное тестирование на протяжении всего жизненного цикла. Подтверждающее тестирование - это гибкий эквивалент тестирования спецификации.
Гибкое приемочное тестирование - это сочетание традиционного функционального тестирования и традиционного приемочного тестирования, которое команда разработчиков и заинтересованные стороны проводят вместе. В то время как тестирование для разработчиков представляет собой сочетание традиционного модульного тестирования и традиционного тестирования интеграции сервисов. Тестирование разработчика проверяет как код приложения, так и схему базы данных.
(c) Выпуск Конец игры или переходная фаза
Цель «Выпустить, конец игры» - успешно развернуть вашу систему в производственной среде. Действия, включенные в этот этап, включают обучение конечных пользователей, вспомогательного персонала и оперативных сотрудников. Также сюда входит маркетинг выпуска продукта, резервное копирование и восстановление, доработка системной и пользовательской документации.
Заключительный этап тестирования гибкой методологии включает в себя полное тестирование системы и приемочное тестирование. Чтобы завершить финальный этап тестирования без каких-либо препятствий, вам следует более тщательно протестировать продукт, пока он находится на итерациях строительства. В конце игры тестировщики будут работать над историями о дефектах.
(d) Производство
После стадии выпуска продукт перейдет в стадию производства.
Квадранты гибкого тестирования
Квадранты гибкого тестирования разделяют весь процесс на четыре квадранта и помогают понять, как выполняется гибкое тестирование.
а) Квадрант I Agile - качество внутреннего кода является основным направлением в этом квадранте, и он состоит из тестовых примеров, которые основаны на технологиях и реализованы для поддержки команды, включая
1. Модульные тесты
2. тесты компонентов
б) Agile Quadrant II - он содержит тестовые примеры, ориентированные на бизнес и реализованные для поддержки команды. В этом квадранте основное внимание уделяется требованиям. Тип теста, выполняемого на этом этапе, следующий:
1. Тестирование примеров возможных сценариев и рабочих процессов.
2. Тестирование пользовательского опыта, например прототипов.
3. Парное тестирование
c) Agile Quadrant III - этот квадрант обеспечивает обратную связь с первым и вторым квадрантами. Тестовые примеры можно использовать в качестве основы для выполнения автоматизированного тестирования. В этом квадранте проводится множество раундов повторных обзоров, которые укрепляют доверие к продукту. Тип тестирования, проводимого в этом квадранте, следующий:
1. Юзабилити-тестирование
2. Исследовательское тестирование
3. Парное тестирование с клиентами.
4. Совместное тестирование
5. Пользовательское приемочное тестирование
г) Agile Quadrant IV - Этот квадрант концентрируется на нефункциональных требованиях, таких как производительность, безопасность, стабильность и т. д. С помощью этого квадранта приложение создается для обеспечения нефункциональных качеств и ожидаемой ценности.
1. Нефункциональные тесты, такие как стресс-тестирование и тестирование производительности.
2. Тестирование безопасности в отношении аутентификации и взлома.
3. Тестирование инфраструктуры
4. Тестирование миграции данных.
5. Тестирование масштабируемости
6. Нагрузочное тестирование
Проблемы контроля качества при гибкой разработке программного обеспечения
а) Вероятность ошибки больше в Agile, поскольку документации уделяется меньше внимания, что в конечном итоге оказывает большее давление на команду QA
б) Новые функции вводятся быстро, что сокращает доступное время для групп тестирования, чтобы определить, соответствуют ли последние функции требованиям и действительно ли они соответствуют деловым требованиям.
в) От тестировщиков часто требуется играть роль полуразработчика.
г) Циклы выполнения тестов сильно сжаты
д) Очень мало времени на подготовку плана тестирования
е) Для регрессионного тестирования у них будет минимальное время
ж) Изменение своей роли от наблюдателя за качеством до партнера по качеству.
h) Изменения и обновления требований являются неотъемлемой частью гибкого метода, что становится самой большой проблемой для QA.
Риск автоматизации в гибком процессе
- Автоматизированный пользовательский интерфейс обеспечивает высокий уровень уверенности, но он медленный в исполнении, хрупкий в обслуживании и дорогостоящий в создании. Автоматизация не может существенно повысить продуктивность тестирования, если тестировщики не знают, как тестировать.
- Ненадежные тесты являются серьезной проблемой при автоматическом тестировании. Исправление неудачных тестов и решение проблем, связанных с хрупкими тестами, должны быть высшим приоритетом, чтобы избежать ложных срабатываний.
- Если автоматические тесты запускаются вручную, а не через CI (непрерывная интеграция), существует риск того, что они не будут выполняться регулярно и, следовательно, могут привести к сбою тестов.
- Автоматические тесты не заменяют исследовательское ручное тестирование. Для получения ожидаемого качества продукта требуется сочетание типов и уровней тестирования.
- Многие коммерчески доступные инструменты автоматизации предоставляют простые функции, такие как автоматизация записи и воспроизведения ручных тестовых случаев. Такой инструмент поощряет тестирование через пользовательский интерфейс и приводит к изначально хрупким и сложным в поддержке тестам. Кроме того, хранение тестовых примеров вне системы контроля версий создает ненужную сложность.
- Чтобы сэкономить время, во многих случаях план тестирования автоматизации плохо спланирован или незапланирован, что приводит к провалу теста.
- Процедуры настройки и разрыва тестирования обычно пропускаются во время автоматизации тестирования, в то время как при ручном тестировании процедуры настройки и разрыва теста кажутся безупречными.
- Метрики производительности, такие как количество тестовых примеров, созданных или выполняемых за день, могут вводить в заблуждение и могут привести к большим инвестициям в запуск бесполезных тестов.
- Члены группы гибкой автоматизации должны быть эффективными консультантами: доступными, готовыми к сотрудничеству и находчивыми, иначе эта система быстро выйдет из строя.
- Автоматизация может предлагать и предоставлять решения для тестирования, которые требуют слишком длительного текущего обслуживания по сравнению с предоставленной стоимостью.
- Автоматизированному тестированию может не хватать опыта для разработки и предоставления эффективных решений.
- Автоматическое тестирование может быть настолько успешным, что у него заканчиваются важные проблемы, которые нужно решить, и, таким образом, превращаются в неважные проблемы.
Вывод
Гибкая методология тестирования программного обеспечения предполагает тестирование как можно раньше в жизненном цикле разработки программного обеспечения. Это требует активного участия клиентов и тестирования кода, как только он становится доступным. Код должен быть достаточно стабильным, чтобы можно было проводить системное тестирование. Чтобы убедиться, что ошибки исправлены и протестированы, можно провести обширное регрессионное тестирование. В основном, общение между командами способствует успеху тестирования гибких моделей !!!