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