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

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

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

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

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

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

Типичное заявление о миссии может быть таким:

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

Поддерживается:

• Никакой код не может быть написан для истории, пока мы сначала не определим критерии приемлемости / тесты.


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

В документ Agile Test Strategy я бы также включил напоминание всем об обеспечении качества.

• 
  

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

  
  
• 
  

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

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

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

ЗАЧЕМ: Чтобы убедиться, что код разработан правильно

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

КАКИЕ: Весь новый код + рефакторинг старого кода, а также модульное тестирование Javascript

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

ГДЕ: Локальный Dev + CI (часть сборки)

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

API / тестирование сервисов

ЗАЧЕМ: Для обеспечения работы связи между компонентами

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

КАКИЕ: Новые веб-сервисы, компоненты, контроллеры и т. Д.

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

ГДЕ: Локальный Dev + CI (часть сборки)

КАК: Автоматизированный, пользовательский интерфейс мыла, клиент отдыха

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

ЗАЧЕМ: Чтобы оправдать ожидания клиентов

КТО: Разработчик / SDET / Руководство по контролю качества

КАКИЕ: Проверка приемочных испытаний по историям, проверка функций

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

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

КАК: Автоматически (огурец)

Системное тестирование / регрессионное тестирование / UAT

ЗАЧЕМ: Для обеспечения работы всей системы при интеграции

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

КАКИЕ: Тестирование сценариев, пользовательские потоки и типичные пользовательские пути, тестирование производительности и безопасности

КОГДА: Когда приемочные испытания завершены

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

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

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

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

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

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

я независимый (среди всех остальных)

N договорная (не конкретный контракт на функции)

V aluable (или вертикальный )

ЯВЛЯЕТСЯ стимулирующий (в хорошем приближении)

S торговый центр (чтобы уместиться в итерации)

Т устойчивая (в принципе, даже если на нее еще нет теста)

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

As a [role] I want [feature] So that [benefit]

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

Критерии приемки

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

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

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

Scenario 1: Title Given [context] And [some more context]... When  [event] Then  [outcome] And [another outcome]...

Сюжетные семинары / планирование спринта

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

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

Предотвращение дефектов

В мастерских рассказов, Должны быть задействованы PO, BA, Dev и QA.

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

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

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

Точно так же на собраниях по планированию спринта оценки, данные для истории, также должны включать усилия по тестированию, а не только усилия по кодированию. Также должен присутствовать QA (ручной и автоматический) на собраниях по планированию спринта, чтобы дать оценку для проверки истории.

Разработка

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

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

Модульные тесты гарантируют, что система работает на техническом уровне и что нет ошибок в логике.

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

Как разработчик, ведите себя так, как будто у вас нет QA в команде или организации. Верно, что у тестировщиков другое мышление, но вы должны тестировать как можно лучше.

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

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

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

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

Автоматические приемочные тесты обычно пишутся на языке Gherkin и выполняются с использованием инструмента BDD, такого как огурец.

Помнить : Не все тесты нужно автоматизировать!

Поскольку для этих тестов обычно требуется связь через HTTP, их нужно выполнять в развернутом приложении, а не как часть сборки.

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

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

Тесты безопасности должны проверять основные уязвимости безопасности, возникающие из OWASP

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

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

Регрессионное тестирование

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

Пакет дыма - не более 15 мин.

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

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

• Поиск продукта,
• Обзор продукта
• Покупка товара
• Создание учетной записи / Вход в учетную запись

Полный регрессионный пакет - не более 1 часа

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

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

UAT и исследовательское тестирование

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

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

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

Готово Критерии

Как только все вышеуказанные действия будут завершены и проблем не будет найдено, история Сделанный!

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