Пример-шаблон стратегии Agile-тестирования

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

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

Раньше мы пришли к выводу, что нам не нужно иметь обширный план тестирования в гибких проектах для каждого спринта из-за ограничений по времени, но нам нужна гибкая стратегия тестирования на высоком уровне в качестве руководства для гибких команд.

Цель гибкого стратегического документа по тестированию состоит в том, чтобы перечислить передовую практику и некоторую структуру, которой могут следовать команды. Помните, что гибкость не означает неструктурированность.

Здесь мы рассмотрим пример стратегии Agile-тестирования и то, что нужно включить в документ. Стратегия тестирования обычно имеет цель, которая может быть связана с более широкими бизнес-целями и задачами.

Типичным задачами могут быть:

«Постоянно доставлять рабочее ПО, отвечающее требованиям заказчика»
посредством
«Обеспечения быстрой обратной связи»
а также
«Предотвращения дефектов, а не обнаружение дефектов»

В документе стратегии Agile-тестирования я также хотел бы напомнить всем о гарантии качества.

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

Уровни тестирования

Модульное тестирование

ПОЧЕМУ: Чтобы код был правильно разработан

КТО: разработчики / технические архитекторы

ЧТО: весь новый код + рефакторинг старого кода, а также модульное тестирование Javascript

КОГДА: Как только будет написан новый код

ГДЕ: Local Dev + CI (часть сборки)

КАК: Автоматизированное Junit, TestNG, PHPUnit

Тестирование API / служб

ПОЧЕМУ: Для обеспечения связи между компонентами

КТО: разработчики / технические архитекторы

ЧТО: Новые веб-сервисы, компоненты, контроллеры и т. Д.

КОГДА: как только новый API разрабатывается и готов

ГДЕ: Local Dev + CI (часть сборки)

КАК: автоматизированное, Soap UI, Rest Client

Приемочное тестирование

ПОЧЕМУ: Чтобы удовлетворить ожидания клиентов

КТО: Разработчик / SDET / Manual QA

ЧТО: проверка приемочных испытаний историй, проверка функций

КОГДА: когда функция готова и тестируется

ГДЕ: CI / тестовая среда

КАК: Автоматизированное

Тестирование системы / Регрессионное тестирование / UAT

ПОЧЕМУ: Чтобы вся система работала при интеграции

КТО: SDET / Руководство QA / Бизнес-аналитик / Владелец продукта

ЧТО: Тестирование сценария, пользовательские потоки и типичные пользовательские маршруты, тестирование производительности и безопасности

КОГДА: когда приемка завершена

ГДЕ: промежуточная среда

КАК: Автоматизированное (Webdriver) исследовательское тестирование

История не может считаться полной до тех пор, пока не пройдут все ее приемочные испытания.

Резерв продукта

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

Истории пользователей должны быть простыми, краткими и недвусмысленными. В качестве хорошей рекомендации лучше следовать модели INVEST для написания пользовательских историй.

Хорошая история пользователя должна быть:

“I” ndependent -«Я» независима (от всех остальных)
“N” egotiable -«Э» эгоистичная
“V” aluable -«У» - универсальная
“E” stimable -«С» стимулируемая
“S” mall -”М”-маленькая (чтобы вписаться в итерацию)
“T” estable -”Т” тестируемая (даже если нет теста)

Следующий формат должен использоваться для написания пользовательских историй:

As a [role] - В качестве (должность)
I want [feature] - Я хочу (функция)
So that [benefit] - Так что я могу (поза)

Важно не забывать, пункт «польза» очень важен, так как каждый должен знать, какую ценность они добавляют, развивая историю.

Критерии приемлемости

Каждая история пользователя должна содержать критерии приемки. Это, возможно, самый важный элемент, который поощряет общение с различными членами команды.

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

Сценарий 1: название

Учитывая [контекст]

И [еще несколько контекстов] ...

Когда [событие]

Затем [результат]

И [другой результат] …

Планирование спринта

В каждом планировании спринта каждый в команде узнает подробности историй, чтобы разработчики и QA менеджеры знали объем работы. У всех должно быть одинаковое понимание того, о чем идет речь.

Разработчики должны хорошо понимать технические детали, связанные с доставкой истории, а служба обеспечения качества должна знать, как будет проверяться история, и если есть какие-либо препятствия для проверки историй.

Предотвращение багов

В сюжетных мастерских должны участвовать PO, BA, Dev и QA. Следует подумать о сценариях (допустимых, недействительных и крайних случаях) (QA может добавить огромное значение здесь, абстрактно размышляя об истории) и записанных в файлы функций.

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

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

Разработка

Когда начинается разработка, новый производственный код и / или модификация устаревшего кода, тестирование должно подкрепляться модульными тестами, написанными разработчиками и рецензированными другим разработчиком или опытным SDET.

Любая фиксация в репозитории кода должна инициировать выполнение модульных тестов с сервера CI. Это обеспечивает быстрый механизм обратной связи для команды разработчиков. Модульные тесты гарантируют, что система работает на техническом уровне и что в логике нет ошибок.

Тестирование разработчика

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

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

Любой новый код и / или повторный факторинг унаследованного кода должны иметь соответствующие модульные тесты, которые будут частью единичного регрессионного теста.

Автоматизированные приемочные испытания и нефункциональное тестирование

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

  • Автоматизированные приемочные испытания обычно пишутся на языке Gherkin и выполняются с помощью инструмента BDD.
  • Помните: не все тесты должны быть автоматизированы!
  • Тестирование функциональными тестами (Performance and Security) не менее важно, чем функциональными, поэтому их необходимо выполнять при каждом развертывании.
  • Тестирование производительности должно проверять показатели производительности для каждой сборки, чтобы гарантировать отсутствие снижения производительности.
  • Тесты безопасности должны проверять основные уязвимости безопасности, полученные от OWASP.

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

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

Нет никаких причин, по которым UAT и исследовательские испытания не могут выполняться параллельно с автоматизированными приемочными испытаниями. В конце концов, они - разные виды деятельности и стремятся найти разные проблемы. Цель UAT - обеспечить, чтобы разработанные функции были полезными для бизнеса и были полезными для бизнеса.

PO (Product Owner) должен запустить приемочные тестирования, чтобы подтвердить, что созданный продукт соответствует ожидаемому и соответствует ожиданиям пользователя.

Исследовательское тестирование должно быть ориентировано на пользовательские сценарии и должно выявлять ошибки, которые автоматизация пропускает.

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

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