Привет, хабровчане!
Решил написать статью о процессе взаимодействия наших тестировщиков с аналитиками и о бонусах, которые компания SuperJob получает от этого процесса.
Работа тестировщиков с требованиями состоит из трёх этапов: Ревью ФТ, Покрытие ФТ, Ревью кейсов.
![image](https://habrastorage.org/webt/uf/-c/9j/uf-c9jerl4psrkhji6snd6c173u.png)
Требования ведутся аналитиками в Enterprise Architect, оттуда они копируются в Confluence. После написания требований они отправляются на ревью тестировщикам.
![image](https://habrastorage.org/webt/ry/pq/hg/rypqhgwix2pg6suok5kgonzgt-g.png)
Пока это взаимодействие ведется через Google Sheets, где есть:
Аналитик соответствующему пункту таблицы проставляет статус “На ревью”:
![image](https://habrastorage.org/webt/j5/vb/t1/j5vbt1dbtixzdaybenthgc1sp5w.png)
На этом этапе, в рамках Confluence задаются вопросы по определённым пунктам требований, благо функционал позволяет добавлять комментарии к произвольным частям текста. В комментариях же ведутся обсуждения, по итогу которых ФТ обновляется.
После того, как требования были дописаны и актуализированы, они передаются в разработку и тестирование.
Тест кейсы пишутся в TestRail, архитектура хранения тест-кейсов полностью повторяет архитектуру хранения требований. Это нужно для простоты поиска, ну и для того, чтобы не изобретать свой велосипед — проще взять его у соседа-аналитика.
![image](https://habrastorage.org/webt/zr/sv/j3/zrsvj36zhgk-pjvyuamnvs_uyy4.png)
Тестирование покрывает требования — покрывается каждый пункт требований, каждое предложение.
Каждый пункт требований пронумерован, есть трассировка тест-кейсов на пункты требований. Отдельно хочется отметить, что в каждом кейсе проставляется версия ФТ, на которую этот кейс писался — требования могут изменяться и пункты в них тоже, если не учитывать версию ФТ, потом концов не сыскать.
![image](https://habrastorage.org/webt/m6/lq/4b/m6lq4bekl5dv6mbzp6bpnaoi0bi.png)
Таким образом:
Кейсы пишутся в трёх вариантах:
![image](https://habrastorage.org/webt/1q/ax/we/1qaxwekdogmkzoin45yrsfbijya.png)
![image](https://habrastorage.org/webt/n7/y2/pe/n7y2pecndrcwpx5fu3hvaatx1be.png)
В разделах ФТ, где есть макеты создается тест-кейс “Сверка с макетом М...”. Он служит просто напоминалкой, что есть макет и реализацию нужно с ним сверить. Данный кейс без внутреннего описания — чек-лист для сверки с макетом у нас описан в регламентах.
После написания кейсов в общей таблице проставляется статус “Ревью кейсов”, это знак того, что другой тестировщик может взять это ФТ и провести ревью кейсов. Это нужно для того, чтобы кейсы были одинаково понятны всем тестировщикам и для того, чтобы свежим взглядом пройтись по требованиям.
![image](https://habrastorage.org/webt/g9/c-/wx/g9c-wxmpqy2-ftlqkdocmisryqw.png)
В случае неуспешного прохождения ревью, например в ФТ появились новые вопросы или покрытие недостаточное — требование переводится в статус “Доработать”. Очень не хватает комментариев в TestRail, чтобы описать все свои пожелания — пока это происходит в письменной форме в Slack, что не очень удобно для отслеживания.
Если ревью прошло успешно — ФТ попадает в статус “Готово”.
В редких случаях, когда требования были обновлены после написания на них тест-кейсов — ФТ переводится в статус “Обновлено”. Дополнительно тестировщик, покрывающий ФТ подписывается на обновления страницы Confluence. Если требования сильно изменились — создается задача для тестировщика на актуализацию кейсов.
Что даёт нам такой подход?
На этом пока всё. Спасибо за внимание!
А как устроен процесс работы с требованиями у Вас?
Решил написать статью о процессе взаимодействия наших тестировщиков с аналитиками и о бонусах, которые компания SuperJob получает от этого процесса.
Работа тестировщиков с требованиями состоит из трёх этапов: Ревью ФТ, Покрытие ФТ, Ревью кейсов.
![image](https://habrastorage.org/webt/uf/-c/9j/uf-c9jerl4psrkhji6snd6c173u.png)
Ревью ФТ
Требования ведутся аналитиками в Enterprise Architect, оттуда они копируются в Confluence. После написания требований они отправляются на ревью тестировщикам.
![image](https://habrastorage.org/webt/ry/pq/hg/rypqhgwix2pg6suok5kgonzgt-g.png)
Пока это взаимодействие ведется через Google Sheets, где есть:
- Название ФТ
- Ссылка на ФТ
- Ответственный за ФТ аналитик
- Статусы от аналитиков
- Ответственный тестировщик
- Статусы от тестировщиков
Аналитик соответствующему пункту таблицы проставляет статус “На ревью”:
![image](https://habrastorage.org/webt/j5/vb/t1/j5vbt1dbtixzdaybenthgc1sp5w.png)
На этом этапе, в рамках Confluence задаются вопросы по определённым пунктам требований, благо функционал позволяет добавлять комментарии к произвольным частям текста. В комментариях же ведутся обсуждения, по итогу которых ФТ обновляется.
После того, как требования были дописаны и актуализированы, они передаются в разработку и тестирование.
Покрытие ФТ
Тест кейсы пишутся в TestRail, архитектура хранения тест-кейсов полностью повторяет архитектуру хранения требований. Это нужно для простоты поиска, ну и для того, чтобы не изобретать свой велосипед — проще взять его у соседа-аналитика.
![image](https://habrastorage.org/webt/zr/sv/j3/zrsvj36zhgk-pjvyuamnvs_uyy4.png)
Тестирование покрывает требования — покрывается каждый пункт требований, каждое предложение.
Каждый пункт требований пронумерован, есть трассировка тест-кейсов на пункты требований. Отдельно хочется отметить, что в каждом кейсе проставляется версия ФТ, на которую этот кейс писался — требования могут изменяться и пункты в них тоже, если не учитывать версию ФТ, потом концов не сыскать.
![image](https://habrastorage.org/webt/m6/lq/4b/m6lq4bekl5dv6mbzp6bpnaoi0bi.png)
Таким образом:
- Легко проверять качество покрытия требований кейсами. Перед глазами не простыня из 50 кейсов и такая же простыня ФТ рядом, а выбираешь один пункт требований и тут же видишь, какие кейсы именно этот пункт покрывают;
- В случае изменения требований сразу видно, какие кейсы нужно подправить.
Кейсы пишутся в трёх вариантах:
- Кейсы-заголовки(таких большинство). Когда у кейса есть только заголовок, по которому понятно, что нужно сделать. Их быстрее писать, чем подробные тест-кейсы и при этом прозрачно покрытие:
![image](https://habrastorage.org/webt/1q/ax/we/1qaxwekdogmkzoin45yrsfbijya.png)
- Тест-кейсы. Подробный тест-кейс с шагами, когда в кейсе много нюансов и все их в заголовок не уместить;
- Кейсы-чек-листы. Когда кейс состоит из чек-листа на проверку какого-то направления функционала. Для выделения таких кейсов используем в заголовке (кейсы):
![image](https://habrastorage.org/webt/n7/y2/pe/n7y2pecndrcwpx5fu3hvaatx1be.png)
В разделах ФТ, где есть макеты создается тест-кейс “Сверка с макетом М...”. Он служит просто напоминалкой, что есть макет и реализацию нужно с ним сверить. Данный кейс без внутреннего описания — чек-лист для сверки с макетом у нас описан в регламентах.
Ревью кейсов
После написания кейсов в общей таблице проставляется статус “Ревью кейсов”, это знак того, что другой тестировщик может взять это ФТ и провести ревью кейсов. Это нужно для того, чтобы кейсы были одинаково понятны всем тестировщикам и для того, чтобы свежим взглядом пройтись по требованиям.
![image](https://habrastorage.org/webt/g9/c-/wx/g9c-wxmpqy2-ftlqkdocmisryqw.png)
В случае неуспешного прохождения ревью, например в ФТ появились новые вопросы или покрытие недостаточное — требование переводится в статус “Доработать”. Очень не хватает комментариев в TestRail, чтобы описать все свои пожелания — пока это происходит в письменной форме в Slack, что не очень удобно для отслеживания.
Если ревью прошло успешно — ФТ попадает в статус “Готово”.
В редких случаях, когда требования были обновлены после написания на них тест-кейсов — ФТ переводится в статус “Обновлено”. Дополнительно тестировщик, покрывающий ФТ подписывается на обновления страницы Confluence. Если требования сильно изменились — создается задача для тестировщика на актуализацию кейсов.
Заключение
Что даёт нам такой подход?
- Во-первых, в разработку попадают проверенные требования. Это экономит время разработчиков, до которых нелогичности, недочеты и косяки ФТ просто не доходят;
- Во-вторых, тестировщики готовятся к тестированию параллельно с разработкой, таким образом мы сокращаем время выпуска фичи. Тестировщики же могут спокойно и ответственно подойти к процессу написания кейсов, а не в формате “Аааа, упала огромная фича, лить нужно сегодня вечером. Давайте быстрее тестить!”
- В-третьих, это повышение качества тестирования за счет ревью кейсов. Скажем “Нет!” замыленному взгляду.
Что не нравится?
- Между написанием кейсов и их прогоном на фиче довольно большой временной разрыв — хоть кейсы и готовы и их остаётся только проверить, но тестировщик всё же выпадает из контекста;
- Как я уже писал ранее — в TestRail не хватает комментариев, как в Confluence — нельзя просто взять и отметить проблемное место, оставив к нему коммент.
На этом пока всё. Спасибо за внимание!
А как устроен процесс работы с требованиями у Вас?