Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Посоветуйте систему для ведения тестовой документации

Посоветуйте инструмент для ведения тестовой документации: тест-плана, тест-кейсов, чек-листов, матриц трассировки, пользовательских историй с возможностью импорта/экспорта, отчётами по мануальному и автоматическому тестированию.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Подскажу только по пару моментов которые надо учесть, т.к. сам не знаю ни одной тест-менеджмент системы, которую можно было бы полностью рекомендовать.

1. Самое главное — это простота интеграции системы с таск-трэкерами, CI и багтрэкером (если т
акой атавизм вы вдруг используете), которые используются на проекте для разработки.

2. Уточните насчет доступности API тест-менеджмент системы и ее интегрируемости с тест-ранером для того, чтобы получить результаты автотестов и мануал-тестов в одном месте с одной и той же конфигурацией.

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

Первых два комментария поняла, а вот на счёт 3го матрица трассировки позволила бы наглядно отслеживать покрытие юзер стори тестами. У вас есть какой-то довод почему это не нужно?

Если в компании не делают полноценную аналитику ДО разработки, то трассировка тестов на требования — это прикольно выглядит, но и только. Достаточно линковать под стори соответствующие ей тесты и go-go-go, прод ждëт.

Сильно удивлюсь, если у вас делают аналитику по канонам старой школы разработки ПО, бо иначе вы бы уже юзали что-то большое вроде hp quality center, а не redmine.

Разумеется. Важно понять, что User Story — это не требование к системе, а изменение к текущему состоянию требований. Что это значит? Вот к примеру:

1. User Story 1 говорит: «я, как юзер, хочу, чтобы кнопка закрытия окна была красная и в левом-верхнем углу экрана». Сделано, написаны тесты. ТС1 проверяет позицию и спрайт. Есть четкая и понятная трейсэбилити US1 — TC1 и так далее по цепочке (тест-результаты, баги и т.д.)

но проходит полгода, оказывается, что реальные юзеры не оценили такого нововведения (хотя это не важно, причина может быть другой и ПО пишет новую стори:

2. User Story 2: «я, как юзер, хочу, чтобы кнопка закрытия окна была серой и в правом верхнем углу». (Это совершенно правильная с точки зрения XP & SCRUM практика). Дальше есть несколько вариантов развития событий, каждый из которых по-своему убог.

— Вы можете написать новый тест (TC2) и удалить/задизейблить старый. В итоге ваша трейсэбилити матрица выглядит так:
US2 — TC2
US1 — ?
трейсабилити сломана

— Вы можете переписать старый тест и перелинковать на новую стори. Ничего принципиально не меняется:
US2 — TC2
US1 — ?
трейсабилити снова сломана

— Можно переписать старый тест и залинковать на обе стори. В итоге матрица выглядит:
US1 — TC1
US2 /
Ваша трейсэбилити вроде как на месте, но зато теряет всякий смысл. Вы видите, что тест-кейс якобы покрывает функционал стори, но на самом деле вообще нет. Он ссылается на два противоположных требования и понять какое правильное можно разве что по дате закрытия, что очень неудобно. С отчетами о том какой функционал работает также проблемы т.к. вместо 1-1 трейсабилити у вас 1 to many.

— Можно (если можно) удалить US1, т.к. она более не актуальна либо же вместо открытия новой стори переоткрыть старую с изменениями (если ПО на это пойдет). Хоть это и создает некоторые процессные проблемы, выглядит как лучший вариант. Тем не менее, он не решает проблему мерджа (особенно частичного мерджа юзер сторей).
К примеру:
У вас было окно аудиоплэера. Была US1 — на импелементацию общего окна и кнопок перемотки, US2 — на имплементацию кнопки Play, US3 — на имплементацию прогресс-бара. На все были тест-кейсы с трейсэбилити (соответственно, TC1, TC2, TC3). Все было ок. А потом заходит US4 на то, чтобы перекрасить все эти объекты в другой цвет, растянуть по горизонтали и поменять местами на экране. Как вы пропишите трейсэбилити? Удалить US1, US2, US3 вы не можете, т.к. US4 отменяет не все их требования, а только некоторые. Каждый из тест-кейсов дополнительно залинкуете на 2 стори? TC1->US1, TC1->US4; TC2->US2, TC2->US4 и т.д. После нескольких каскадных изменений подобных этому получится кастрюля макарон в которой мало кто будет что-либо понимать.

Как-то так оно и работает.

але він досить дорогий, є подібний опенсорсний TestLink, інтерфейс щоправда з 90-х, але багато функцій, потрібних автору, підтримує

тестлінк буде з часом тормозити коли в системі буе овер дофіга Тест кейсів і проектів + репорти не дуже..
якщо у вас використовується Джира то глянте на x-ray чи zephyr

Не використовуємо Jira, в тому і справа. Такі варіанти як Test link, Test Rail розглядали, але нам вони не підходять. Серед варіантів з’явились такі тули як TestLodge та Test Collab, може хтось з ними працював?

А где вы задачи и баги трекаете?

От этого вам и придется отталкиваться, бо основной трекер будет довлеть и определять всë.

Основные темы для редминки — www.easyredmine.com/...​edmine-test-cases-plugin або вся эта спискота www.redmine.org/...​ools#Test-Case-Management

Но суть в том, что однозначности нет и не должно быть. Сделайте себе план эмуляции вашего workflow на пару часов и триальте всë, что под руку попадется, выполняя повсюду один и тот же ваш план. Результаты непредсказуемые, но опыта точно наберетесь.

Вполне вероятно, что придете к дорогому, но умному тестрэйлу или даже уйдете с редмайн на ту же jira, бо там confluence и xray в одном флаконе, а связка сервисов имеет очень большой смысл.

zephyr

тормозне гiвно, краще вже знайти грошi на TestRail

4 года плотно работал с Тестрейлом. Для достаточно крупного, структурированного проекта (т.е. V-model, например) не рекомендую.
1. Репортинг, в том числе трейсэбилити матрикс это боль. Чтобы получалось что-то более-менее адекватное, нужно наворачивать наборы скриптов, которые вытягивают информацию из API.
2. Фильтрация тест-кейсов и тестовых результатов страдает
3. Плохое управление правами доступа.
4. Высокая цена и отсутствие гибкости в этом вопросе (лицензия только на год, поодному пользователи не добавляются и т.д.)
5. Плохая интеграция с другими системами — Jira, Jenkins, Git repo, etc.

Подписаться на комментарии