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

[Олешка]

Я не знаю, просто предложила как пример, на котором можно более предметно разговаривать. Спасибо за расчет лицензий. ;)

[Mike]

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

В общем, да. Пока, по крайней мере.

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

Олешка, я не уверен, что правильно понял, что Вы имеете в виду. Если речь идёт о тестировании нескольких редакций одного продукта (например, Demo/Trial/Standard/Pro) проекта, то заминка будет в модуле Requirements с "покрытием" тестами , в смысле, Вы не сможете определить, успешно прошли тесты на отдельный "бренд" или нет, так как показываются всегда последние прогоны тестов. То же относится и к модулю TestLab - прийдется копировать TestCasы для каждого бренда. И со статусами тестов, опять-таки, будет неразбериха если используются одни и те же тесты.
Итого, в этом случае имеет смысл копировать и требования, и тесты и тесткейсы для каждого "бренда" отдельно.

[Mike]

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

Так как проект тестирования довольно сильно отделён от проектов разработки, мне кажется, никому не помешает если тулзы для версионного контроля разработки и тестирования будут разные. А Visual Source Safe входит в Visual Studio, поэтому, есть большая вероятность что он у Вас уже есть :rolleyes: .

[Andrei Kulabukhau]

[Cообщение было удалено модератором]

Просьба личные сообщения писать в виде PM, ICQ или e-mail. B)

C уважением,
Модератор форума Mercury Interacrive Tools,
Майк.

[Andrei Kulabukhau]

Даже если в Standard версии лицензий было-бы больше, я бы не советовал работать с Access-базой больше чем 5 людям одновременно .

Я тоже. :) Придется выделять отдельного человека чуть ли не на full-time для администрирования и лечения "ежели чего". :)

[Олешка]

Кстати об администрировании. При работе с другими базами сколько времени потребуется на эту работу? И еще - в какие сроки удалось ввести в эксплуатацию TD?

[Mike]

Кстати об администрировании. При работе с другими базами сколько времени потребуется на эту работу? И еще - в какие сроки удалось ввести в эксплуатацию TD?

Что Вы имеете в виду под администрированием баз? ИМХО, ничего кроме back-up средствами самой СУБД делать не прийдётся (если мы говорим об администрировании именно СУБД). В какие сроки? Это очень сильно зависит от проекта, точнее, от workflow проекта. Относительно простой workflow можно написать за день-два (Если есть опыт. Если совсем нет - неделя). Раздача привилегий, заведение пользователей - ещё пол-дня.

[Олешка]

To Mike: Я имела в виду администрирование всей системы - TD. А что понимается под относительно простым workflow?

To Andrei Kulabukhau: Насчет баз - чем вызваны такие сложности работы именно с Access?

[Mike]

Администрирование самого TestDirector - понятие очень ёмкое. Сюда входит:
- Создание проектов и доменов, подключение и отключение проектов (баз данных), копирование проектов, update проектов;
- Администрирование пользователей и групп
- Настройка workflow
- Управление почтовыми уведомлениями
Повторюсь, если говорить о более-менее простом проекте для запуска понадобиться около 2-х дней. Из них на всё кроме workflow - пол-дня.

Что касается простого workflow, очень сложно объяснить словами, чем простой workflow отличается от сложного - это очень завязано на специфику TestDirector. Скажу только, что сложность workflow прямо пропорционально количеству действий, которое testdirector должен делать автоматически при добавлении/изменении "сущности" (дефект/требование/test). То есть, если надо запретить некоторые действия пользователя в специфической ситуации, или, напротив, форсировать какие-то специфические действия - прийдётся писать workflow. Язык - VBScript.
Пример: при закрытии дефекта надо автоматически проставить дату закрытия и версию закрытия.
Пример2: при изменении статуса надо попросить пользователя добавить комментарий.
Оба примера пишутся довольно легко (5-10 строчек - каждый), но таких ситуаций может быть много.

Под простым Workflow я имел в виду workflow, в котором таких хитрых случаев примерно 5-20.

Насчет баз - чем вызваны такие сложности работы именно с Access

Извиняюсь, что отвечаю на вопрос, адресованный не мне :) , но сложность работы с Access связана исключительно с самим Access: эта СУБД в принципе (в силу своей специфики) не предназначена для одновременной работы большого количества людей.

[Олешка]

Mike, спасибо за подробные ответы.

Если будет возможность, расшифруйте, пожалуйста, что подразумевается под доменами.

И еще - как определяется проект в TD? Название, версия, группа людей, которые с ним работают? Что-то еще?

[Mike]

Mike, спасибо за подробные ответы.

Если будет возможность, расшифруйте, пожалуйста, что подразумевается под доменами.

И еще - как определяется проект в TD? Название, версия, группа людей, которые с ним работают? Что-то еще?

Домен - "папка" для хранения проектов, не более того ;). Все проекты в TD версий больше 7.2 (если не ошибаюсь) сгруппированы в домены. Обычно хватает одного домена - по умолчанию. Чисто физически - это действительно папка на диске, в которой находятся папки проектов (не секрет, что вложения TestDirector хранит в файловой системе, а не в виде BLOBов в БД - в Access, например, blobов (в смысле как в Оracle) нет.).

Как определяется проект в TD (мы говорим о проекте в смысле TD, то есть отдельной БД):

- название: да ;)
- версия: нет (в проекте может быть много тестируемых приложений, у каждого - своя версия. Если говорить о версионном контроле, то , опять-таки, у каждой сущности (теста, требования) - свой набор версий.
- группа людей: да, но ;). Да - у каждого проекта свой набор пользователей и свои группы пользователей. Но - можно импортировать пользователей из других проектов.
Ещё:
- свой Workflow
- свои преференсы у пользователей и общие преференсы (фильтры, настройки отчётов)
- свои настройки почтовых уведомлений
...

[Mike]

Майк, не обижайся ! Хочу добавить дегтя, т.к. мы используем решения Mercury уже давно, а именно: TestDirector, WinRunner, LoadRunner.

Итак, обещанный деготь:

:D

1. Тест Директор, это тулз, удобный ТОЛЬКО если в процесс включена группа тестирования. Если есть группа разработчиков, аналитиков,  архитекторов и пр., то одного ТД все равно не хватит.

Совершенно согласен. TestDirector - тул для группы тестирования, о чём тут уже говорилось. Для Request Management'a на стадии разработки Requisite Pro походит больше (но требует бОльших усилий по поддержке и обучению сотрудников). Для того и нужен Add-in для интеграции TD и Requisite pro.

В ТД все железно. Ничего не сделаешь сам.

Если речь идёт о создании новых "сущностей" (и соответственно, новых таблиц), то согласен. Но есть такой тип полей - иерархический список - он частично компенсирует невозможность создания собственных таблиц, которая обусловлена чисто идеалогическими причинами - для простоты администрирования и "стройности" всей конструкции в целом. Если речь идёт о workflow - не согласен. Теперь (в 8.0) можно создавать cвой workflow для чего угодно (тестов, test suites, шагов, требований...).

2. Test Lab - очень слаб. Невозможно организовать папки, и дерево. Только сплошной список. У нас этот список уже такой, что приходится писать хитроумные фильтры для того, чтобы найти своё.

Речь идёт о списке test suites? Вообще-то, он не должен быть таким уж большим - test suite это (идеологически) - цикл тестирования одного продукта. Под циклом я имею в виду приёмочное тестирование, тестирование базовой функциональности, нагрузочное тестирование и т.п. Таких процедур на каждый продукт - максимум десяток. Могу только посоветовать делать более обширные test suitы.

3. В Тест Кейсах невозможно писать разными шрифтами.

Но можно форматировать (Bold/Italic/Text Color). Да, есть такое дело. Но, мне кажется, проще всего в данном случае просто добавить вложение в формате Microsoft Word (или в любом другом формате). А потом, как Вы себе представляете хранение такого монстра (со шрифтами, форматированием и пр.) в базе данных? В виде BLOB?

4. Представьте ситуацию, есть много Тест Кейсов, в каждом из них куча steps. а - невозможно приписать степу время (т.е 1 - ый день тестированиия, 2 - ой и т.д.) И, соответственно, нельзя составить календарь проверок. В фирме Amdocs написали для этих целей свою приблуду. Это настолько удобно !!!

Пожалуйста, поподробнее... Не совсем понял.

5. Генератор отчетов несколько кривоватый. И возможности его не всегда удовлетворяют начальство и нас.

Ну, это на вкус ;). Кроме того, генератор очетов (Document Generator) - как ни странно, штука настраиваемая (так как написан он частично на VBA). Нам даже удалось перевести его полностью на русский язык.

6. Ужас! Когда в тест - плане меняем что - нибудь, то в тест - лабе не происходит refresh. Т.е. после изменения кейса надо чинить тест лаб. Но это, как мне кажется, баг.

Давайте попробуем обсудить это в отдельной теме - может, найдём какое-нибудь решение этой проблемы...

В ТД приходится создавать свои группы и администрить их - геморрой.

И это на вкус :rolleyes: . По мне так никакого геммороя. Особенно по сравнению с продуктами Rational.

[Mike]

2Миша:

На счёт стэпов я понял. Но, сорри, "календарь" на тесты-то существует! Зачем растягивать тест на 3 дня когда проще разбить его на 2 теста по 10 минут; опять-таки, это идеалогия. "Граф" (схема) выполнения существует для тестов, но для стэпов его нет и быть не может. Поэтому, какой смысл реализовать часть этой функциональности? Это только неоправданно усложнит систему. Есть схема выполнения тестов - с календарём, уведомлениями, дополнительными условиями, зачем нужно что-то ещё?
На счёт suites - IMHO, cитуация рещается просто - добавляете в test suits ещё одно поле - "Subject", типа список, или иерархический список, и фильтруете по нему. Конечно, это не так красиво как дерево, но проблему решает.

[Mike]

Миша, я конечно извиняюсь, но то о чём вы рассказываете - это какая-то полная экзотика ;). Во первых, почему нельзя сделать отдельный тест-кейс с отдельными тестами под этот "прерывистый" цикл тестирования? Ну выдерете вы ваш 'степ 264 из кейса 593746525' и 'степ 1 из теста 2' - и сохраните как отдельные тесты в новом тесткейсе. Если не хотите дублировать - используйте темплэйты и/или вызов одного теста из другого. ИМХО, надуманная какая-то проблема. А то что MI не захотела этого делать - прекрасно их понимаю. Архитектура TestDirector - нарочито простая и прозрачная. Незачем её запутывать.

[Green]

Да потому, что это очень длинная операция. Она выполняется 5 дней!

Один тест кейс на 5 дней - это мазахизм! :D

На заре своей трудовой деятельности я работал в конторе, которая занималась пректированием пресс-форм для отливки. Разработка программ велась на ХТ и 286 машинах (как вам древность! :P ), а просчет конечной формы осуществлялся на супер новых и дорогих (арендовалось машинное время) 486 компах.

Так вот просчет конечной формы занимал от двух до трех суток непреравной работы компьютера. Продолжительность выполнения тест кейса по такой операции действительно могла бы растянуться на несколько дней. Но даже в этом случае тест не должен состоять более чем из 10 - 20 шагов (я стараюсь не превышать 5 - 10 шагов, если это получается).

Такой подход в написании тест кейсов выстрадан годами практики. Уверяю вас, это как "небо и земля"!
Значительно легче обслуживать компактный тест кейс: писать и поддерживать в актуальном состоянии. Соответственно, им легче манипулировать при составлении модели тестирования (построения графа тестов).

Миша, попробуйте. Вам понравиться.

:rolleyes:

[pioner]

И все-таки, где можно скачать триал версию? или где в Москве можно взять эту - самую дискетку?? Очень хочется посмотреть программку. :) (если за дискеткой в Минск ехать не надо, приеду сам :))