16. Контроль и обеспечение качества

Интеграция контроля и обеспечения качества в Scrum

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

  • Регрессионное тестирование функционала с предыдущих спринтов;
  • Приемочное тестирование спринтов и релизов.

В рамках спринта у тестировщиков есть пять основных активностей:

  1. Планирование итерации
  2. Автоматизация приемочного тестирования
  3. Тестирование историй пользователей
  4. Регрессионное тестирование
  5. Демонстрация

Количество тестировщиков определяется многими факторами:

  • количеством разработчиков;
  • наличием автоматических приемочных тестов;
  • наличием практики написания модульных тестов разработчиками;
  • общим качеством продукта;

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

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

Тест кейс

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

Тестировщик выполняет тест-кейс последовательно, шаг за шагом. Если фактический результат соответствует ожидаемому — всё хорошо. Если нет, тестировщик анализирует, что произошло. Это может быть ошибка в программе, в тест-кейсе из-за его неактуальности или в тестовом стенде. Если дело в программе, инженер составляет отчёт об ошибке и отправляет его разработчикам. Если в тест-кейсе — исправляет сам. Если в стенде — обращается к техническим специалистам.

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

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

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

Тест план

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

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

Тестовый набор

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

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

Тестовые наборы можно объединять в тест планы.

Тестовый сценарий

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

  • функционального тестирования;
  • приемочного тестирования;
  • нагрузочного или стресстестирования;
  • исследовательского тестирования;
  • smokeтестирования
  • и др.

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

Тестовые сценарии удобно объединять в тестпланы по назначению:

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

Зачастую ручное тестирование превращается в рутину и занимает значительное время, что отрицательно сказывается на скорости выпуска релизов.
Автоматизация тестирования позволяет:

  • высвободить ресурсы для проведения более сложных видов тестирования;
  • снизить количество дефектов, доходящих до стадии контроля качества;
  • ускорить выпуск релизов.

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