Здравствуйте, хабровчане!
Я решил написать статью о процессе взаимодействия наших тестировщиков и аналитиков и о бонусах, которые получает от этого процесса SuperJob.
Работа тестировщиков с требованиями состоит из трёх этапов: FT Review, FT Coverage, Case Review.
Обзор ФТ
Требования поддерживаются аналитиками в Enterprise Architect, а оттуда копируются в Confluence. После написания требований они отправляются на проверку тестировщикам.
Пока это взаимодействие осуществляется через Google Sheets, где есть:
- Имя ФТ
- Ссылка на ФТ
- Ответственный за аналитика ФТ
- Статусы от аналитиков
- Ответственный тестировщик
- Статусы от тестеров
На этом этапе в рамках Confluence задаются вопросы по определенным пунктам требований; к счастью, функционал позволяет добавлять комментарии к произвольным частям текста.
В комментариях проходят обсуждения, в результате которых ФТ обновляется.
После того как требования выполнены и обновлены, они передаются в разработку и тестирование.
покрытие FT
Тестовые случаи написаны на TestRail; архитектура хранения тестовых примеров полностью повторяет архитектуру хранения требований.Это нужно для удобства поиска, а чтобы не изобретать велосипед — проще одолжить его у соседа-аналитика.
Тестирование охватывает требования — рассматривается каждый пункт требований, каждое предложение.
Каждый элемент требования пронумерован, и для элементов требований имеется трассировка тестовых примеров.
Отдельно хотелось бы отметить, что в каждом случае указывается версия ФТ, для которой писалось данное дело - требования могут меняться и пункты в них тоже, если не учитывать версию ФТ, то вы ничего не сможете найти.
Таким образом:
- Качество покрытия требований легко проверить на кейсах.
Перед вашими глазами не лист из 50 дел и такой же лист ФТ рядом, а вы выбираете один пункт требований и сразу видите, какие дела охватывают именно этот пункт;
- Если требования изменятся, вы сразу увидите, какие случаи необходимо исправить.
- Заголовок дел (таких большинство).
Когда кейс имеет только заголовок, из которого понятно, что нужно сделать.
Их писать быстрее, чем подробные тестовые примеры, и покрытие прозрачно:
- Тестовые случаи.
Подробный тест-кейс с шагами, когда кейс имеет много нюансов и все их невозможно уместить в заголовке;
- Кейсы-чек-листы.
Когда кейс состоит из чек-листа для проверки какой-то области функционала.
Чтобы выделить такие случаи, используйте в заголовке (кейсах) следующее:
В разделах ФТ, где есть макеты, создается тестовый пример «Сверка с макетом М.
».
Он просто служит напоминанием о том, что есть макет и необходимо сверить с ним реализацию.
Внутреннего описания у этого случая нет — чек-лист сверки с макетом описан в нашем регламенте.
Обзор дела
После написания кейсов в общую таблицу заносится статус «Просмотр кейсов», это признак того, что другой тестировщик может взять это ФТ и просмотреть кейсы.Это нужно для того, чтобы кейсы были одинаково понятны всем тестировщикам и чтобы посмотреть на требования свежим взглядом.
В случае неудачного завершения проверки, например, в ФТ появились новые вопросы или недостаточное освещение – требование переводится в статус «Пересмотреть».
В TestRail очень мало комментариев для описания всех ваших пожеланий — пока это происходит в письменной форме в Slack, что не очень удобно для отслеживания.
Если проверка прошла успешно, FT переходит в статус «Готов».
В редких случаях, когда требования были обновлены после написания по ним тест-кейсов, ФТ переводится в статус «Обновлено».
Кроме того, тестер, занимающийся TF, подписывается на обновления страницы Confluence. Если требования существенно изменились, для тестировщика создается задача на обновление кейсов.
Заключение
Что нам дает такой подход?- Во-первых, в разработку включаются проверенные требования.
Это экономит время разработчиков, которые просто не доходят до нестыковок, недостатков и ошибок FT;
- Во-вторых, тестировщики готовятся к тестированию параллельно с разработкой, таким образом мы сокращаем время выпуска фичи.
Тестировщики же могут спокойно и ответственно подойти к процессу написания кейсов, а не в формате «Аааа, упала огромная фича, ее надо сегодня вечером выложить.
Давайте проверим это быстрее!»
- В-третьих, это повышает качество тестирования посредством рассмотрения случаев.
Скажем «Нет!» затуманенный взгляд.
Что не нравится?
- Между написанием кейсов и запуском их на фиче проходит достаточно большой временной разрыв — хотя кейсы уже готовы и остаётся только их проверить, тестировщик всё равно вне контекста;
- Как я писал ранее, в TestRail отсутствуют комментарии, как и в Confluence — нельзя просто отметить проблемную область и оставить к ней комментарий.
-
Науру
19 Oct, 24 -
Как Выбрать Расширение Домена?
19 Oct, 24
