Какую выбрать test managment систему?

Question

[Дмитрий]

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

Что собственно хочется от системы по учету тест-сценариев?
1) WEB-ориентированность
2) Каждый тест-план имеет версию или что-то позволяющее быстро сослаться на основании какого-тест плана было проведено тестирование продукта версии X.Y.Z
3) Возможность создать текущий чеклист на основе имеющегося эталонного тестового набора из тестовых сценариев. Чтобы проверяя сценарий за сценарием я мог бы отмечать "пройден" или "ошибка" и видеть прогресс проверки.
4) Возможность задать среднее, максимальное время на выполнение тест.сценария
5) Каждый тест-сценарий как можно в более наглядном виде, чтобы даже не особо подготовленный человек смог бы более менее понять что именно проверяет сценарий?
6) Возможность создать сборку-солянку из имеющихся тестовых сценариев для специфичной версии продукта.

UPD: Деньги под критерий не попадают. Рассматриваются как бесплатные, так и платные альтернативы.

Прошу поделиться любыми знаниями по наведению порядка в своем болоте инженеГра по качеству. Я вроде как все понимаю, но пока в виду неопытности многое творю "на коленке" и это приводит к тому что иногда пропускаю достаточно важные баги, что меня не может не удручать!

Answer 1

[Юлия]

Для JIRA есть плагин Zephyr for JIRA: ваши тесты будут просто задачами со спец типом test, благодаря чему вы можете туда и время логировать, чтобы смотреть сколько вы изначально планировали и сколько ушло + при прогоне тестов можно ставить pass/fail не открывая сам тест, то есть по сути использовать как чеклист.
Еще вариант для JIRA - Structure, только надо будет добавить какое-нибудь поле со списком пасс-фейл, чтобы результаты хранить. А так можно быстро создать чеклист, делать клоны, копировать между "структурами".
Учтите, что если JIRA On Demand - плагинов практически нет) ну вот перечисленных выше - точно пока нет
Просто для чеклистов вне джиры есть например OnTestPad. У прогона можно задавать любые поля, можете поставить себе опять же original estimate и потом вписать сколько вышло. В прогоне можно давать ссылки на баги, репорты можно расшаривать всем просто ссылочкой.

Answer 2

[Максим Михайлов]

Наряду с "хотелками" на выбор системы сильное влияние оказывают $ возможности. Или бесплатность такой системы Вы подразумевали по умолчанию? =) Еще один момент, о котором стоит помнить - TMS он не только для тестеров. Время от времени туда будут смотреть и менеджеры и разработчики. Важно в их лицах видеть поддержку в вопросе внедряемого инструмента, а не кислую мину или равнодушие. И, самый главный мой вопрос - почему Вы уверены что внедрение TMS приведет к тому, что Вы перестанете пропускать важные баги? Опишите-ка свой процесс подробнее.. что-то мне подсказывает ("работая тестировщиком и обеспечивая контроль качества программного продукта") что Вы единственный тестер на проекте.

Comments

[Дмитрий]

Спасибо! Обновил про деньги! ;)

[Дмитрий]

Забыл подтвердить, что да, я единственный тестер на проекте. Не скажу что виртуоз и профессионал, но очень хочу чтобы моя работа приносила еще больше пользы чем сейчас

[Максим Михайлов]

Про виртуоза то понятно, никто из нас тут не Паганини =) А вот из профессионалов Вы себя зря вычеркиваете, тем более с таким настроем как "хочу чтобы моя работа приносила еще больше пользы". Еще несколько вопросов для лучшего видения вашего процесса:
- чем куют программисты? Visual Studio?
- какие management системы уже используются в проекте? Task Management, scrum management, bugtracker.
- в каком агрегатном состоянии пребывают требования? твердом, жидком или газообразном?
- кто кроме Вас смотрит тестовую документацию? Программисты, менеджеры, директора, заказчики?
- как быстро меняется код/требования/продукт(ы)?

PS: на данный момент мое впечатление такое:
1. Вам НЕ нужен TMS
2. Вам нужно заменить тест кейсы на чеклисты, при этом в тест кейсы переводить только часть неизменных идей (для внешней отчетности)
3. Для уменьшения bugrate'а Вам нужно улучшать процесс, желательно без привлечения дополнительных программных средств (типа TMS). Для этого сначала проанализируйте и запишите источники дефектов и проблем в проекте.

[Дмитрий]

- IDE по умолчанию. Язык С++. Система Windows
- Jira, Agile-Подобный процесс девелопмента
- Требования или хэлп, или обсуждение с маркетолом, редкий раз с более старшими девелоперами
- Тест документацию смотрю сам, оооочень редко, почти никогда другие члены команды

Ваше "PS":
1. Вполне возможно, еще в процессе осмысления что вообще хочется-то?
2. Про чеклисты да, эта идея уже давно витает в умах команды. Однако как хранить, модифицировать, пользоваться и др вопросы связанные с чеклистом тоже не исчезают.

[Максим Михайлов]

Про чеклисты - используйте excel или поищите плагин для Jira. Управлять и поддерживать актуальность чеклистов на порядок проще чем выполнять всё то же для тест кейсов. Поскольку кроме Вас никто не читает тест план, то и забудьте про TMS, тем более в agile. Если желание понаступать на грабли не исчезло - устанавливайте MS Test Manager.

Answer 3

[Максим Михайлов]

А по существу вопросов:
1) Почти все TMS такие (и это печально)
2) Все умеют это
3) Метить прогоны как passed/failed и составлять на основе этой информации сводку о прогрессе умеют все. Чеклисты в явном виде в TMS очень редко встречаются, это Вам не task tracker'ы.
4) Задать для чего? Все TMS способны отслеживать время выполнения тестов. Как интерпретировать эти данные - уже Ваше личное дело.
5) Это на 99% задача писателя тестов, а не TMS. Кулебячный тест, даже будучи раскрашенным акварелью, всё равно будет кулебякой.
6) Все умеют это

Comments

[Дмитрий]

4) - Для того чтобы хоть как-то можно было отвечать на вопрос подобный этому: "Сколько займет времени на тестирование новой версии?"
5) Это то конечно так, но мне хотелось бы удобные интерфейсы. Представляю себе это так: тест сценарий состоит из цели, набора шагов и ожидаемого результата. Я бы спроектировал след. UI-интерфейс. один едит для ввода цели, один для ожидаемого результата и еще один для ввода текста шага и кнопку '+' чтобы появился еще один едит для ввода очередного шага и одна глобальная save чтобы сохранить тест-сценарий

[Максим Михайлов]

4) Эта задача решается без TMS. Поясню. TMS неспособно посчитать эффективное время выполнения теста. Время на чай для неё ничем не отличается от времени работы с тестируемым приложением. Всё что она сможет - это зафиксировать время старта и окончания прогона теста (либо метка времени на каждый шаг теста). По моим наблюдениям на практике эта информации бесполезна, т. к. если даже Вы не пьете чай, то отвлекаться на баги или просто уходить в сторону от сценария приходится почти всегда в ручных тестах. Таким образом один и тот же тест может гоняться час, два или целый день. Мой совет - классифицируйте тесты по времени выполнения на этапе их создания. Причем разбивайте грубо, точность до минут никому не нужна при таких погрешностях: 1 час, полдня, день, долгие тесты. Тогда не составит труда вычислить временную сложность тест плана или отдельной секции. Дальше - больше. Приоритезируйте тесты хотя бы на: критичные и необязательные, тогда получите и минимальное время на прогон плана. Это действительно полезная информация.. А на вопрос "сколько займет времени тестирование новой версии" лично я всегда отвечаю "от пары минут до бесконечности" =) Каков вопрос, таков и ответ. Итого: не нужно Вам с помощью TMS отслеживать среднее время прогона тестов, вместо этого клеймите тесты метками временной сложности еще на этапе создания.
5) Ну если так, то подходящий ответ - "Все умеют это". В смысле все TMS имеют поля для заголовков/целей/ID/авторов/статусов и пр., а также плюсики для добавления шагов. Вероятнее всего в любом из существующих UI Вы найдете плюсы и минусы, тут просто дело привычки. Итого: забейте на данный критерий. Он условно выполним для всех TMS.

[Дмитрий]

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

[Максим Михайлов]

Две рекомендации: раз часто ошибаешься со временем, логично будет в будущем называть оценку + ошибку; при выполнении важных задач как только понимаешь что в срок не уложиться, сообщай об этом начальству с объяснением причин (перечисляй факты, которые не были учтены).

Answer 4

[Дмитрий]

Спасибо за Ваш ответ!
п.1 По поводу OnTestPad , я его смотрел в свое время, но увидев в примерах что нету Pass/Fail и отмел сразу же ) К примеру testpad-outline-editor. Имею ввиду зеленый/красный прямо в списке, чтобы можно было сразу же понять какой не пройден без просмотра детализации кейса
п.2 Про Zephyr. У меня нету четкого понимания как им пользоваться! Действительно ли там можно отметить Pass/Fail? Я не увидел важной для меня строчки: Версия плана и возможности ссылки на него.

А чем пользуетесь Вы?

Comments

[Юлия]

как тут печально все с нотификациями, больше года прошло, только счас отвечаю:( Есть пасс-фейл про прогоне в онтестпад:) вот так выглядит все внутри: screencast.com/t/vNOZbrMczJc
В Зефире тоже такое есть. А еще есть например тут: https://marketplace.atlassian.com/plugins/com.almw...