Что такое гибкое тестирование? Процесс и жизненный цикл

Что такое гибкое тестирование?

Гибкое тестирование — это практика тестирования, которая следует правилам и принципам гибкой разработки программного обеспечения. В отличие от метода «Водопад», гибкое тестирование может начинаться в начале проекта с непрерывной интеграцией разработки и тестирования. Методология гибкого тестирования не является последовательной (в том смысле, что она выполняется только после этапа кодирования), а непрерывной.

Принципы гибкого тестирования

Вот основные принципы гибкого тестирования:

• В этой модели гибкого тестирования работающее программное обеспечение является основным показателем прогресса.
• Наилучшего результата могут добиться самоорганизующиеся команды.
• Своевременное и непрерывное предоставление ценного программного обеспечения является нашим высшим приоритетом.
• Разработчики программного обеспечения должны ежедневно собираться вместе на протяжении всего проекта.
• Повышение гибкости за счет постоянного технического совершенствования и хорошего дизайна.
• Agile Testing гарантирует, что конечный продукт соответствует ожиданиям бизнеса, обеспечивая постоянную обратную связь.
• В процессе Agile Test нам необходимо выполнить процесс тестирования во время реализации, что сокращает время разработки.
• Процесс тестирования в Agile должен работать с постоянным темпом разработки.
• Регулярно размышляйте о том, как стать более эффективным.
• Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
• Каждый раз, когда команда встречается, она пересматривает и корректирует свое поведение, чтобы стать более эффективной.
• Личное общение с командой разработчиков — наиболее эффективный и действенный метод передачи информации внутри команды.

Гибкое тестирование включает в себя различные принципы, которые помогают нам повысить производительность программного обеспечения.

Жизненный цикл гибкого тестирования

Жизненный цикл гибкого тестирования состоит из пяти различных этапов, как мы можем видеть на следующем изображении:

Вот этапы тестирования Agile-процесса:

Фаза 1: Оценка воздействия: На этом начальном этапе мы собираем информацию от заинтересованных сторон и пользователей. Этот этап также называют этапом обратной связи, поскольку он помогает инженерам-испытателям определить цели для следующего жизненного цикла.

Этап 2. Планирование гибкого тестирования: Это второй этап жизненного цикла гибкого тестирования, на котором все заинтересованные стороны собираются вместе, чтобы спланировать график процесса тестирования и его результаты.

Этап 3: Готовность к выпуску: На этом этапе мы проверяем, готовы ли к внедрению или нет функции, которые были разработаны/реализованы. На этом этапе также решается, кому нужно вернуться на предыдущий этап разработки.

Этап 4: Ежедневные скрамы: Этот этап включает в себя каждое утреннее совещание, на котором можно узнать статус тестирования и поставить цель на весь день.

Этап 5: Проверка гибкости Revвид: Последняя фаза жизненного цикла Agile — Agility. Revпросмотр встречи. Он включает в себя еженедельные встречи с заинтересованными сторонами для регулярной оценки прогресса в достижении целей.

Гибкий план тестирования

Гибкий план тестирования включает в себя типы тестирования, выполняемые в этой итерации, такие как требования к тестовым данным, инфраструктура, тестовые средыи результаты испытаний. В отличие от водопадной модели, в гибкой модели план тестирования пишется и обновляется для каждого выпуска. Типичные планы тестирования в Agile включают в себя

• Область тестирования
• Новые функции, которые проходят тестирование
• Уровень или типы тестирования в зависимости от сложности функций.
• Нагрузочное тестирование и тестирование производительности
• Рассмотрение инфраструктуры
• План смягчения последствий или рисков
• Ресурсное
• Результаты и основные этапы

Гибкие стратегии тестирования

Жизненный цикл гибкого тестирования состоит из четырех этапов.

Итерация 0

На первом этапе или итерации 0 вы выполняете задачи начальной настройки. Он включает в себя определение людей для тестирования, установку инструментов тестирования, планирование ресурсов (лаборатория тестирования юзабилити) и т. д. Следующие шаги запланированы на итерацию 0.

• Создание бизнес-кейса проекта.
• Установите граничные условия и объем проекта.
• Опишите ключевые требования и варианты использования, которые будут определять компромиссы при проектировании.
• Опишите одну или несколько возможных архитектур.
• Выявление риска
• Оценка стоимости и подготовка предварительного проекта

Строительные итерации

Второй этап методологии гибкого тестирования — это строительные итерации. На этом этапе происходит большая часть тестирования. Этот этап рассматривается как набор итераций для построения приращения решения. Для этого на каждой итерации команда реализует гибрид практик XP, Scrum, гибкого моделирования, гибких данных и так далее.

При итерации построения agile-команда следует практике расстановки приоритетов требований: на каждой итерации они берут наиболее важные требования, оставшиеся из стека рабочих элементов, и реализуют их.

Итерация построения подразделяется на две: подтверждающее тестирование и исследовательское тестирование. Концентраты подтверждающего тестирования при проверке того, что система соответствует намерениям заинтересованных сторон, как описано команде на сегодняшний день, и выполняется командой. В то время как следственное тестирование выявляет проблему, которую группа подтверждения пропустила или проигнорировала. При исследовательском тестировании тестировщик определяет потенциальные проблемы в виде историй дефектов. Исследовательское тестирование занимается такими распространенными проблемами, как интеграционное тестирование, нагрузочное/стресс-тестирование и тестирование безопасности.

Опять же, подтверждающее тестирование имеет два аспекта. тестирование разработчика и гибкое приемочное тестирование. Оба из них автоматизированы, чтобы обеспечить непрерывное регрессионное тестирование на протяжении всего жизненного цикла. Подтверждающее тестирование — это гибкий эквивалент тестирования по спецификации.

Гибкое приемочное тестирование — это сочетание традиционного функционального тестирования и традиционного приемочного тестирования, когда команда разработчиков и заинтересованные стороны делают это вместе. В то время как тестирование разработчиков представляет собой смесь традиционного модульного тестирования и традиционного тестирования интеграции сервисов. Тестирование разработчиков проверяет как код приложения, так и схему базы данных.

Конец игры релиза или переходный этап

Целью «Выпуск, окончание игры» является успешное развертывание вашей системы в рабочей среде. Мероприятия, входящие в этот этап, включают обучение конечных пользователей, сотрудников службы поддержки и оперативного персонала. Также сюда входит маркетинг выпуска продукта, резервное копирование и восстановление, доработка системной и пользовательской документации.

Заключительный этап тестирования гибкой методологии включает в себя полное тестирование системы и приемочное тестирование. Чтобы завершить заключительный этап тестирования без каких-либо препятствий, вам необходимо более тщательно протестировать продукт, пока он находится на стадии разработки. В финальной версии тестеры будут работать над историями дефектов.

Постановка

После стадии выпуска продукт перейдет на стадию производства.

Квадранты гибкого тестирования

Квадранты гибкого тестирования разделяют весь процесс на четыре квадранта и помогают понять, как выполняется гибкое тестирование.

Гибкий квадрант I

Качество внутреннего кода находится в центре внимания в этом квадранте и состоит из тестовых примеров, которые основаны на технологиях и реализуются для поддержки команды.

• Модульные тесты
• Тесты компонентов

Agile-квадрант II

Он содержит тестовые примеры, ориентированные на бизнес и реализованные для поддержки команды. Этот квадрант фокусируется на требованиях. Вид теста, выполняемого на этом этапе:

• Тестирование примеров возможных сценариев и рабочих процессов
• Тестирование пользовательского опыта, например прототипов.
• Парное тестирование

Гибкий квадрант III

Этот квадрант обеспечивает обратную связь с первым и вторым квадрантами. Тестовые случаи могут использоваться в качестве основы для автоматического тестирования. В этом квадранте проводится множество раундов проверки итераций, что укрепляет доверие к продукту. Тип тестирования, проводимого в этом квадранте:

• Тестирование юзабилити
• Исследовательское тестирование
• Парное тестирование с клиентами
• Совместное тестирование
• Пользовательское тестирование

Гибкий квадрант IV

В этом квадранте основное внимание уделяется нефункциональным требованиям, таким как производительность, безопасность, стабильность и т. д. С помощью этого квадранта приложение создается для обеспечения нефункциональных качеств и ожидаемой ценности.

• Нефункциональные тесты, такие как стресс-тестирование и тестирование производительности.
• Тестирование безопасности в отношении идентификация и взлом
• Тестирование инфраструктуры
• Тестирование миграции данных
• Тестирование масштабируемости
• Тестирование нагрузки

Проблемы обеспечения качества при гибкой разработке программного обеспечения

• Вероятность ошибки выше в Agile, поскольку документации уделяется меньше внимания, что в конечном итоге оказывает большее давление на команду контроля качества.
• Новые функции внедряются быстро, что сокращает время, необходимое командам тестировщиков для определения того, соответствуют ли новейшие функции требованиям и действительно ли они соответствуют деловым требованиям.
• От тестировщиков часто требуется играть роль полуразработчика.
• Циклы выполнения тестов сильно сжаты
• Очень меньше времени на подготовку плана тестирования
• Для регрессионного тестирования у них будет минимальное время
• Изменение их роли с роли гаранта качества на партнера по качеству.
• Изменения и обновления требований присущи гибкому методу и становятся самой большой проблемой для контроля качества.

Риск автоматизации в гибких процессах

• Автоматизированный пользовательский интерфейс обеспечивает высокий уровень доверия, но он медленн в исполнении, ненадежен в обслуживании и дорог в создании. Автоматизация не может существенно улучшить производительность тестирования, если тестировщики не знают, как тестировать.
• Ненадежные тесты являются серьезной проблемой в автоматизированном тестировании. Исправление неудачных тестов и решение проблем, связанных с хрупкими тестами, должно быть главным приоритетом, чтобы избежать ложных срабатываний.
• Если автоматические тесты инициируются вручную, а не через CI (непрерывную интеграцию), существует риск того, что они не выполняются регулярно и, следовательно, могут привести к сбою тестов.
• Автоматизированные тесты не заменяют исследовательское ручное тестирование. Для получения ожидаемого качества продукта требуется сочетание типов и уровней тестирования.
• Многие коммерчески доступные инструменты автоматизации предоставляют простые функции, такие как автоматизация захвата и воспроизведения ручных тестовых примеров. Такой инструмент поощряет тестирование через пользовательский интерфейс и приводит к тому, что тесты становятся хрупкими и сложными в обслуживании. Кроме того, хранение тестовых примеров вне системы контроля версий создает ненужную сложность.
• Чтобы сэкономить время, во многих случаях план автоматизированного тестирования плохо спланирован или незапланирован, что приводит к провалу теста.
• Процедуры настройки и демонтажа теста обычно упускаются из виду при автоматизации тестирования, в то время как при выполнении ручного тестирования процедуры настройки и демонтажа теста кажутся незамысловатыми.
• Показатели производительности, такие как количество тестовых примеров, созданных или выполняемых в день, могут вводить в заблуждение и могут привести к большим инвестициям в проведение бесполезных тестов.
• Члены команды гибкой автоматизации должны быть эффективными консультантами: доступными, готовыми к сотрудничеству и находчивыми, иначе эта система быстро выйдет из строя.
• Автоматизация может предлагать и предоставлять решения по тестированию, которые требуют слишком длительного текущего обслуживания по сравнению с предоставляемой ценностью.
• Автоматизированному тестированию может не хватать опыта для разработки и предоставления эффективных решений.
• Автоматизированное тестирование может оказаться настолько успешным, что у него закончатся важные проблемы, требующие решения, и, таким образом, они перейдут к второстепенным проблемам.

Заключение

Гибкая методология тестирования программного обеспечения предполагает тестирование как можно раньше. жизненный цикл разработки программного обеспечения. Это требует активного участия клиентов и тестирования кода, как только он станет доступен. Код должен быть достаточно стабильным, чтобы его можно было использовать для системного тестирования. Можно провести обширное регрессионное тестирование, чтобы убедиться, что ошибки исправлены и проверены. В основном, общение между командами обеспечивает успех тестирования гибких моделей!!!