Покрытие требований кейсами. Реалии компании SuperJob

Привет, хабровчане!

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

Работа тестировщиков с требованиями состоит из трёх этапов: Ревью ФТ, Покрытие ФТ, Ревью кейсов.

image

Ревью ФТ


Требования ведутся аналитиками в Enterprise Architect, оттуда они копируются в Confluence. После написания требований они отправляются на ревью тестировщикам.

image

Пока это взаимодействие ведется через Google Sheets, где есть:

  • Название ФТ
  • Ссылка на ФТ
  • Ответственный за ФТ аналитик
  • Статусы от аналитиков
  • Ответственный тестировщик
  • Статусы от тестировщиков

Аналитик соответствующему пункту таблицы проставляет статус “На ревью”:

image

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

После того, как требования были дописаны и актуализированы, они передаются в разработку и тестирование.

Покрытие ФТ


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

image

Тестирование покрывает требования — покрывается каждый пункт требований, каждое предложение.

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

image

Таким образом:

  • Легко проверять качество покрытия требований кейсами. Перед глазами не простыня из 50 кейсов и такая же простыня ФТ рядом, а выбираешь один пункт требований и тут же видишь, какие кейсы именно этот пункт покрывают;
  • В случае изменения требований сразу видно, какие кейсы нужно подправить.

Кейсы пишутся в трёх вариантах:

  • Кейсы-заголовки(таких большинство). Когда у кейса есть только заголовок, по которому понятно, что нужно сделать. Их быстрее писать, чем подробные тест-кейсы и при этом прозрачно покрытие:

image

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

image

В разделах ФТ, где есть макеты создается тест-кейс “Сверка с макетом М...”. Он служит просто напоминалкой, что есть макет и реализацию нужно с ним сверить. Данный кейс без внутреннего описания — чек-лист для сверки с макетом у нас описан в регламентах.

Ревью кейсов


После написания кейсов в общей таблице проставляется статус “Ревью кейсов”, это знак того, что другой тестировщик может взять это ФТ и провести ревью кейсов. Это нужно для того, чтобы кейсы были одинаково понятны всем тестировщикам и для того, чтобы свежим взглядом пройтись по требованиям.

image

В случае неуспешного прохождения ревью, например в ФТ появились новые вопросы или покрытие недостаточное — требование переводится в статус “Доработать”. Очень не хватает комментариев в TestRail, чтобы описать все свои пожелания — пока это происходит в письменной форме в Slack, что не очень удобно для отслеживания.

Если ревью прошло успешно — ФТ попадает в статус “Готово”.

В редких случаях, когда требования были обновлены после написания на них тест-кейсов — ФТ переводится в статус “Обновлено”. Дополнительно тестировщик, покрывающий ФТ подписывается на обновления страницы Confluence. Если требования сильно изменились — создается задача для тестировщика на актуализацию кейсов.

Заключение


Что даёт нам такой подход?

  • Во-первых, в разработку попадают проверенные требования. Это экономит время разработчиков, до которых нелогичности, недочеты и косяки ФТ просто не доходят;
  • Во-вторых, тестировщики готовятся к тестированию параллельно с разработкой, таким образом мы сокращаем время выпуска фичи. Тестировщики же могут спокойно и ответственно подойти к процессу написания кейсов, а не в формате “Аааа, упала огромная фича, лить нужно сегодня вечером. Давайте быстрее тестить!”
  • В-третьих, это повышение качества тестирования за счет ревью кейсов. Скажем “Нет!” замыленному взгляду.

Что не нравится?


  • Между написанием кейсов и их прогоном на фиче довольно большой временной разрыв — хоть кейсы и готовы и их остаётся только проверить, но тестировщик всё же выпадает из контекста;
  • Как я уже писал ранее — в TestRail не хватает комментариев, как в Confluence — нельзя просто взять и отметить проблемное место, оставив к нему коммент.

На этом пока всё. Спасибо за внимание!

А как устроен процесс работы с требованиями у Вас?
SuperJob.ru
86,00
Интернет-сервис для поиска работы
Поделиться публикацией

Комментарии 2

    0
    У вас есть статистика по трудоемкости такого подхода? Если разработка заняла X дней, то сколько займет тестирование и сколько составление кейсов и такой матрицы покрытия вместе с ревью?
      0
      Статистики пока мало — тестирование убежало далеко вперёд и мы успеваем обрабатывать все появляющиеся ФТ, а разработка по этим ФТ следовательно движется гораздо медленнее. Поэтому данный процесс не накопил еще нормальное количество задач, прошедших от ФТ до деплоя.

      Да и мы отталкивались не столько от выгоды для тестирования, сколько от выгоды для разработки — у нас периодически бывали проблемы с разработкой по неполным требованиям, а у тестировщиков есть время на проверку ФТ до разработки — так почему бы не ускорить разработку?!

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

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

    Самое читаемое