Сообщений в теме: 57

[sunlex]

Привет всем!

Кому посчастливилось поюзать 8-ю версию TestDirectora?
А может у кого есть инсталл?

[Case]

Народ - буду отстреливать подобные посты.
Демку можно искать на сайте производителя - всё что касается взломов это не к этому форуму.

[meol]

Триал версию можно получить у ЛАНИТ
представитель Mercury Interactive в России
конкретно по TestDirector'у - TestDirector: комплексное управление процессом тестирования

[Mike]

Ставили TD 8.0. Лучше (красивше ;)), Workflow есть для всех модулей, а не только для Defects. Собственно, это и есть главное отличие от предыдущих версий. Триалку действительно можно достать у нас, Приедем, поставим, покажем... ;)

[Олешка]

To Mike - а можно поподробнее про него рассказать? На сайте Mercury понятное дело, только хорошее, но стоит он столько, что принимать решение о закупке такого тула только на основании их рекламы просто странно. А неделя на trial - мало для нормальной оценки.

[Guriy]

Ставили TD 8.0. Лучше (красивше ;)), Workflow есть для всех модулей, а не только для Defects. Собственно, это и есть главное отличие от предыдущих версий. Триалку действительно можно достать у нас, Приедем, поставим, покажем... ;)

Линк в студию пожалуйста, на страничку с линком Download Test Director eval version, если прямо на файл нельзя.
А то мне уже надоело по вашему сайту лазить...
Я хочу триалку пощупать. Только боюсь Вам будет далековато с дискеткой ехать :( могу не и дождаться вовсе

[Mike]

To Mike - а можно поподробнее про него рассказать? На сайте Mercury понятное дело, только хорошее, но стоит он столько, что принимать решение о закупке такого тула только на основании их рекламы просто странно. А неделя на trial - мало для нормальной оценки.

В обратном порядке: во первых не неделя а два месяца - более чем достаточно ;). По-поводу хорошего-плохого, в двух словах:
Тестдиректор - тул для QA отдела IT департамента средних размеров фирмы, не выпускающей коробочных продуктов. В таковом качестве - тул простой в освоении (особенно пользователями). Хорош (в сравнении с Rational) тем что клиент - только и полностью Web, все модули (баг-трэкинг/требования/хранилище тестов/тестовая лаборатория) "в одном флаконе", что исключает все проблемы с интеграцией (хотя я слышал что у Rational в последнее время с этим стало получше). Имеет открытый интерфейс (COM) что позволяет писать свои утилиты/модули, скажем, на C++ или VisualBasic. Документация вполне достаточная (особенно на сайте Mercury). Репортинг и анализ - хороши - генерит красивые лркументы как в html так и в Word. Workflow настраивается достаточно подробно. Язык workflow - VBScript. Структура базы - простая и достаточно прозрачная. Везде можно прилеплять вложения, что хорошо.

По модулям:
Defects - средненький. Как во всех defect tracking системах.
Requirements - то же. Тесно интегрируется с Defects и TestLab - красивые картинки покрытия тестами и текущего состояния (то есть, провалились тесты на это требование или нет). Для коробочного продукта (когда тестируется сразу несколько версий) годится не очень. Это же относится и к TestLab. Причина именно в интеграции модулей - по схеме: состояние последнего прогона теста = состояние теста = состояние требования (понятно, если хоть один тест провалился - требование тоже завалено)
TestPlan - место для хранение тестов и скриптов. Хранятся они по папочкам, называемым "Subject". Тесты - ручные и автоматические.
TestLab - здесь мы планируем и проводим наборы тестов (они же - циклы тестирования). Что хорошо - граф (не знабю как по другому назвать) выполнения тестов. То есть: Независимо проводить тесты 2,6,7, после теста2 в не зависимости от результата - тест 3, а после теста 3 (если пройдёт) - тест 4, в 5 часов вечера такого-то числа таким-то тестером на такой-то машине. Причем, после запуска цикла, тестер получит сообщение по почте о том, что он должен провести такой-то тест. Ручные тесты довольно удобны - можно в процессе править сценарии тестов, аттачить картинки (к шагам, скажем), заносить баги... WinRunner и QTP тесты (а так же LR сценарии и много чего еще) запускаются автоматически на любой машине с этими тулами.

В общем, описать в двух словах сложно ;). Но, повторюсь - тул хорош именно как комплекс, framework, 4 в одном. Администрируется он довольно просто. Живёт под MS SQL,Sybase, Oracle и Access. Интегрится со всеми решениями MI и Rational а так-же с Microsoft Office и Version Control тулами, такими как Visual Source Safe и ClearCase.

[Mike]

Линк в студию пожалуйста, на страничку с линком Download Test Director eval version, если прямо на файл нельзя.

Нет такой буквы в этом слове ;) :(. Есть адрес - mercury@lanit.ru, и все вопросы туды. На сайте Mercury так же есть ссылка (на адрес). Когда я работал тестером, WinRunner Evaluation нам прислали без вопросов прямо из Mercury.

Я хочу триалку пощупать. Только боюсь Вам будет далековато с дискеткой ехать  могу не и дождаться вовсе

А куда ехать-то? Если в Минск, то я там буду наверное, в ноябре, могу заскочить...

[Олешка]

To Mike:
большое спасибо за подробное описание. А нам почему-то предложили только на неделю. :(

Еще несколько вопросов:

По модулю Defects: можно ли получить отчеты в произвольном разрезе? Например, список всех открытых багов с сортировкой по приоритету на все версии конкретного продукта. Или список всех багов, найденных QA и найденных заказчиком на данной версии продукта.

Насчет работы с QTP - TestDirector позволяет вызывать скрипты QTP? Есть ли там модуль, который позволяет проанализировать результаты прогона скрипта QTP?

[Mike]

2 Олешка:
[/QUOTE]
По модулю Defects: можно ли получить отчеты в произвольном разрезе? Например, список всех открытых багов с сортировкой по приоритету на все версии конкретного продукта. Или список всех багов, найденных QA и найденных заказчиком на данной версии продукта.
[/QUOTE]
Конечно можно. Любые фильтры по любым полям.
[quote]Насчет работы с QTP - TestDirector позволяет вызывать скрипты QTP? Есть ли там модуль, который позволяет проанализировать результаты прогона скрипта QTP?[/quote]
Конечно. И запускать, и анализировать. Кроме того, с TD идёт некий странный встроенный тул VAPI-XP - по существу -возможность запускать VBScript в качестве автоматизированного теста. Хорошо для дёргания за COM или за другие подобные интерфейсы. Я правда, пока не пробовал - задач не было.

Более того, при большом желании можно запускать всё что угодно, например, Rational Robot (только запускалку и просмотровщик прийдётся писать самостоятельно (как я уже говорил, открытый интерфес - большое дело), но примеры есть (идут в документации)).

[Mike]

2Олешка:

В догонку: про неделю триалки - не верьте. Два месяца там trial. Много раз проверено ;). Насчёт цены - там есть ещё Standard Edition - подешевше. Правда, он только на Access работает и Version Control там не интегрируется.

[Олешка]

Съездила вчера на презентацию TD 8.0. Выглядит заманчиво, но все-таки мне показалось, что это решение на уровне компании, а не на уровне тестовой группы. Поясню, почему - в TD есть функциональность (Requirements), с которой, ИМХО, лучше бы работать не тестировщику, а ПМ или представителю заказчика. А это уже процесс уровня компании.

Попыталась посчитать, сколько одновременных лицензий надо на один проект. (Кстати, понятие проекта в TD осталось туманным - без интеграции со средствами контроля версий, ИМХО, оно таким и останется. Mike, просьба прокомментировать - может я то-то не поняла до конца.)

Я ниже упоминаю проект в смысле тестируемая программа.

Итак, подсчет лицензий на 1 проект - 1 ПМ, 5 программистов, 1 тестировщик, он же ведущий тестировщик, 1 технический писатель, 1 представитель заказчика.

1. Работа с требованиями.

Кто-то должен сидеть и эти требования вводить. ПМ, представитель заказчика или Техрайтер. 1-2 лицензии.

Далее, кто-то должен контролировать покрытие требований тестами. Ведущий тестировщик? 1 лицензия.

2. Работа с тестовыми планами. Ведущий тестировщик. 1 лицензия.

3. Работа с Defects. Записать дефект - тестировщик, просмотреть/отреагировать - программист, получить сводный отчет - ПМ и ведущий тестировщик. 4 лицензии.

4. Работа с Test lab. Cреда работы ведущего тестировщика. 1 лицензия.

Учитывая, что все эти люди могут работать одновременно, получается, что на проект надо иметь 8-9 лицензий. Это уже уровень Enterprise.

Просьба к Mike, а также к тем, кто пользуется TD, прокомментировать - возможно, я ошибаюсь, и лицензий надо меньше. И еще - оценивали ли Вы каким-то образом эффективность финансовых вложений в такой тул?

[Mike]

Олешка!

Лицензии конкурентные - ограничено только количество одновременно работающих клиентов. Поэтому, пользователей и при 5 лицензиях может быть сколько угодно - главное не больше 5 одновременно. Если сильно ужаться, 3 полных 2 defect manager (для тестировщиков и программистов) лицензии вам может хватить (хотя и прийдётся всё время выяснять, кто зажал лицензию ;)). На самом деле, Enterprise лицензия всего ~1.75 раз дороже Standard лицензии. Зато, у вас будет Version Control (если есть VSS или ClearCase) и нормальная SQL-сервер, Oracle или Sybase база. Даже если в Standard версии лицензий было-бы больше, я бы не советовал работать с Access-базой больше чем 5 людям одновременно ;) .
О понятии проекта: если Вы имеете в виду проект в смысле отдельной базы данных, то, конечно, в одном проекте можно работать с любым количеством приложений. Если говорить о концепции работы c TD, то одновременно Вы можете работать с одной "веткой проектирования-тестирования" - то есть, без специальных ухищрений тестировать и разрабатывать одновременно две версии программы у Вас получится вряд-ли (даже с версионным контролем). То есть, дефекты, конечно, вы имеете на разные версии приложения, но вот требования и статус "покрытия тестами" могут относиться только к одной версии одновременно. Поэтому, под проектом в TestDirector я бы понимал отдельный "линейный" процесс разработки и тестирования некоего набора связанных меджу собой приложений.
Что касается модуля Requirements, то, в группе тестирования я бы использовал его исключительно для проверки "покрытия" тестами функциональности программы. В этом случае требования будет писать QA Manager (или ответственный за проект (в смысле, приложение) тестировщик если тестируемых приложекий много ) в целях планирования разработки тестов. То есть требования использовать как описание той функциональности, которую надо покрыть тестами. Я понимаю, что к RUPу или любой другой стандартной методологии такой подход не имеет никакого отношения, но эато это практично ;)).

[Mike]

Ещё один момент о лицензировании - Defect Manager лицензии на Standard и Enterprise версии стоят одинаково, поэтому, если бы Standard Edition позволял иметь больше 5 лицензий, то стоимость 5 общих лицензий + 5 Defect Manager лицензий была бы всего в 1.6 раз дешевле ;), и, соответственно, чем больше лицензий тестировщиков (Defect Manager), тем меньше будет разница. Вот.

[Олешка]

Лицензии конкурентные - ограничено только количество одновременно работающих клиентов.

Поэтому, пользователей и при 5 лицензиях может быть сколько угодно - главное не больше 5 одновременно.

Для одного проекта этого, может быть, и хватит. Вопрос, что будет, когда с помощью TD надо будет организовать тестирование более чем одного проекта? При этом число работающих одновременно, скажем, с Defects модулем, удвоится. И как тогда поступать? При том, что заранее известно, что проектов на тестировании больше чем 1 и число разработчиков в каждом больше чем 5. ;)

Тут не стоит вопрос о выборе между Enterprise или Standard. Пока хотелось бы оценить реальные потребности.

[Олешка]

Зато, у вас будет Version Control (если есть VSS или ClearCase) и нормальная SQL-сервер, Oracle или Sybase база.

Version Control - это, конечно, замечательно. Но насколько я поняла, на интеграцию с CVS можно не рассчитывать. Так?

А сможет ли TD поддержать работу с несколькими версиями проекта? С несколькими брендами?

[Олешка]

Под проектом в TestDirector я бы понимал отдельный "линейный" процесс  разработки и тестирования некоего набора связанных меджу собой приложений. 

Проект MyApp версия 1.0.1.0
Есть список требований, есть соответствующий им набор тестов, есть набор багов.

На тестирование отправляется версия 1.0.1.1. Известно, что в ней были добавлена одна форма, а также изменены 5 других формочек. И исправлены дефекты ##125 - 135.

Действия в TD:

Зафиксировать изменения в требованиях, проассоциировав их с версией 1.0.1.1.
Добавить тесты на новые требования.
Изменить тесты на измененные требования.
Добавить тесты на проверку исправленных дефектов ##125-135.

Так?

[Олешка]

Что касается модуля Requirements, то, в группе тестирования я бы использовал его исключительно для проверки "покрытия" тестами функциональности программы. В этом случае требования будет писать QA Manager (или ответственный за проект (в смысле, приложение) тестировщик если тестируемых приложекий много ) в целях планирования разработки тестов.

То есть требования использовать как описание той функциональности, которую надо покрыть тестами. Я понимаю, что к RUPу или любой другой стандартной методологии такой подход не имеет никакого отношения, но эато это практично ;)).

Это действительно практично, тем более, что на таком уровне требования можно формализовать в виде use cases. Но к ним также должен иметь доступ как представитель заказчика, так и ПМ, хотя бы для контроля.

[Mike]

Я там несколько (мягко говоря) ошибся с прикидками количества лицензий :( . Сорри :unsure:

Насчёт потребностей, я бы считал количество лицензий примерно таким образом:

Полные лицензии:

Число QA Managerов + число Project Managerов + число текрайтеров /3 + 1 + число тестировщиков (в своих прежних рассуждениях я забыл, что тестировщики имеют обыкновение выполнять тесты :D - а для этого нужна полная лицензия).

Defect Manager лицензии:

Число программистов * 2/3


При желании уменьшить число тестерских лицензий, тестировщики могут выполнять тесты сначала по "бумажке" (распечатанным или сохраненным в виде документов тестам), и только потом ставить галочки в Test Lab Manual Test Runner.

[Mike]

Проект MyApp версия 1.0.1.0
Есть список требований, есть соответствующий им набор тестов, есть набор багов.

На тестирование отправляется версия 1.0.1.1. Известно, что в ней были добавлена одна форма, а также изменены 5 других формочек. И исправлены дефекты ##125 - 135.

Действия в TD:

Зафиксировать изменения в требованиях, проассоциировав их с версией 1.0.1.1.
Добавить тесты на новые требования.
Изменить тесты на измененные требования.
Добавить тесты на проверку исправленных дефектов ##125-135.

Конечно. А какие есть варианты? :)