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

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

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

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

Ревью ФТ

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



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

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

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



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

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

Покрытие ФТ

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



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

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



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

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

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

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

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

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

Ревью кейсов

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



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

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

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

Заключение

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

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

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

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

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

А как устроен процесс работы с требованиями у Вас?