Посоветуйте инструмент для ведения тестовой документации: тест-плана, тест-кейсов, чек-листов, матриц трассировки, пользовательских историй с возможностью импорта/экспорта, отчётами по мануальному и автоматическому тестированию.
Подскажу только по пару моментов которые надо учесть, т.к. сам не знаю ни одной тест-менеджмент системы, которую можно было бы полностью рекомендовать.
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 /
Ваша трейсэбилити вроде как на месте, но зато теряет всякий смысл. Вы видите, что тест-кейс якобы покрывает функционал стори, но на самом деле вообще нет. Он ссылается на два противоположных требования и понять какое правильное можно разве что по дате закрытия, что очень неудобно. С отчетами о том какой функционал работает также проблемы т.к. вместо
— Можно (если можно) удалить US1, т.к. она более не актуальна либо же вместо открытия новой стори переоткрыть старую с изменениями (если ПО на это пойдет). Хоть это и создает некоторые процессные проблемы, выглядит как лучший вариант. Тем не менее, он не решает проблему мерджа (особенно частичного мерджа юзер сторей).
К примеру:
У вас было окно аудиоплэера. Была US1 — на импелементацию общего окна и кнопок перемотки, US2 — на имплементацию кнопки Play, US3 — на имплементацию прогресс-бара. На все были тест-кейсы с трейсэбилити (соответственно, TC1, TC2, TC3). Все было ок. А потом заходит US4 на то, чтобы перекрасить все эти объекты в другой цвет, растянуть по горизонтали и поменять местами на экране. Как вы пропишите трейсэбилити? Удалить US1, US2, US3 вы не можете, т.к. US4 отменяет не все их требования, а только некоторые. Каждый из тест-кейсов дополнительно залинкуете на 2 стори? TC1->US1, TC1->US4; TC2->US2, TC2->US4 и т.д. После нескольких каскадных изменений подобных этому получится кастрюля макарон в которой мало кто будет что-либо понимать.
Как-то так оно и работает.
але він досить дорогий, є подібний опенсорсний TestLink, інтерфейс щоправда з
тестлінк буде з часом тормозити коли в системі буе овер дофіга Тест кейсів і проектів + репорти не дуже..
якщо у вас використовується Джира то глянте на
Не використовуємо 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 года плотно работал с Тестрейлом. Для достаточно крупного, структурированного проекта (т.е.
1. Репортинг, в том числе трейсэбилити матрикс это боль. Чтобы получалось что-то более-менее адекватное, нужно наворачивать наборы скриптов, которые вытягивают информацию из API.
2. Фильтрация тест-кейсов и тестовых результатов страдает
3. Плохое управление правами доступа.
4. Высокая цена и отсутствие гибкости в этом вопросе (лицензия только на год, поодному пользователи не добавляются и т.д.)
5. Плохая интеграция с другими системами — Jira, Jenkins, Git repo, etc.
Luci
Молдавский Узбек
Luci
Молдавский Узбек
Сергій Ласкавий
Vladimir Pouzanov
Volodymyr Rudyi
wife of an acrobat
NoNameNoSecondName
Andrey
Vasily Karpets
17 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів