Перейти к содержимому

Аудит и оптимизация QA-процессов
онлайн, начало 4 декабря
Практикум по тест-дизайну 2.0
онлайн, начало 4 декабря
Школа Тест-Аналитика
онлайн, начало 9 декабря
Школа тест-менеджеров v. 2.0
онлайн, начало 9 декабря
Фотография

Testdirector 8.0


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 57

#21 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 16 октября 2003 - 11:20

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

#22 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 16 октября 2003 - 11:27

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

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

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


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

#23 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 16 октября 2003 - 11:42

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


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

#24 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 16 октября 2003 - 12:07

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

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

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

#25 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 16 октября 2003 - 12:11

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

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

#26 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 16 октября 2003 - 12:54

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

#27 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 16 октября 2003 - 13:01

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

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

#28 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 16 октября 2003 - 13:13

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

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

#29 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 16 октября 2003 - 13:34

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

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

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

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


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

#30 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 16 октября 2003 - 14:43

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

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

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

#31 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 17 октября 2003 - 06:13

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

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

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

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

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

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

#32 Гость_Миша_*

Гость_Миша_*
  • Guests

Отправлено 17 октября 2003 - 12:41

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

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

1. Тест Директор, это тулз, удобный ТОЛЬКО если в процесс включена группа тестирования. Если есть группа разработчиков, аналитиков, архитекторов и пр., то одного ТД все равно не хватит. ТД не настраиваемый. Что я имею в виду? Допустим, я планирую релизы на год (2, 5, 100 - не важно). Я знаю, что релизы будут, но не знаю, что в них войдет. А войти в релиз может: Change Request (новая функциональность), исправления дефектов из предыдущих версий, и другое. В Qlear Quest я могу сделать объект, скажем Release, и набивать его, давать ресурсам на тестирование или весь релиз, или какие - то куски ... В ТД все железно. Ничего не сделаешь сам. Поэтому мы пользуемся Quest и TD.

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

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

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

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

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

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

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

Вообще в ТД (как и в Qlear Quest) прозрачная база, так что можно, при помощи SQL, генерить черти что.

Вот такие пироги ...

#33 Гость_Миша_*

Гость_Миша_*
  • Guests

Отправлено 17 октября 2003 - 12:43

Да, по поводу проектов, можно делать их много с разделением по людям и всемы вытекающими отсюда делами

#34 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 17 октября 2003 - 13:55

Майк, не обижайся ! Хочу добавить дегтя, т.к. мы используем решения 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.
  • 0
Best regards,
Майк.

#35 Гость_Миша_*

Гость_Миша_*
  • Guests

Отправлено 17 октября 2003 - 15:08

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

У меня в отделе есть группа, которая тестирует все время разные вещи. Не буду расшуфровывать - долго, примите как данность. Эти ребята делают по 3 - 7 test lab в неделю! Посчитайте, сколько их уже там ? Тихо умираю без иерархий. Было бы дерево - другое дело.

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


Речь идет о новых сущностях. Свой workflow мы используем уже давно.[/quote]Про степы подробнее.

Допустим, есть 3 тестировщика, которые пишут кейсы. Первый пишет тестирование окна 1, второй окна 2, третий окна 3.
Допустим, после этого должна быть оплата, еще какая - нибудь фигня, а потом опять кнопки. Любые действия, подразумевающие разнос по времени. Наши действия? Можно дать номеру 1 комп номер 1, второму 2 и т.д. первый получает для тестирования раб. среду 1, второй 2, и т.д. Первый давит на кнопки в своей среде, второй в своей, и т.д. Давит, платит, давит дальше. НЕ РАЦИОНАЛЬНО! К тому же нет проверки на тот факт, что надавливание в окне 1 не рушит окно 2 (господа, я специально преувеличиваю). Вместо этого я сажаю всех в одну среду, каждый на своем компе, они "хором" или не хором, давят на кнопки, каждый в своем окне, потом платят и т.д. ... Короче - нужна синхронизация по времени.


Смотрим, что в Test Directore.
Первый тестер пишет тесткейс 1:
step 1 : окно - 1, надавить на кнопку 1,
step 2: ждать 2 дня
step 3: заплатить кредиткой
step 4: ждать 2 дня
step 5: окно - 1, надавить на кнопку 1


Второй тестер пишет тесткейс 1:
step 1 : окно - 2, надавить на кнопку 1,
step 2: ждать 2 дня
step 3: заплатить кредиткой
step 4: ждать 2 дня
step 5: окно - 2, надавить на кнопку 1

и т.д.

Если бы можно было привязать каждый step к дате и сделать календарь по датам, цены бы не было ТД!

Фирма Амдокс долго просила Меркури написать такую приблуду, но не дождались, и написали сами. Это очень удобно.
Я работая на ТД с версии 6.что-то, а так эта фишка и не реализована. А жаль.

#36 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 20 октября 2003 - 06:51

2Миша:

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

#37 Гость_Миша_*

Гость_Миша_*
  • Guests

Отправлено 24 ноября 2003 - 10:42

Mike:

//**На счёт стэпов я понял. Но, сорри, "календарь" на тесты-то существует! Зачем растягивать тест на 3 дня когда проще разбить его на 2 теста по 10 минут**//
Похоже, насчет степов не поняли, иначе не было бы этого вопроса. Мне нужно объединение степа Номер 1 из кейса 2, который писал Пупкин со степом 264 из кейса 593746525, который писал Урюпкин.
Почему. Да потому, что это очень длинная операция. Она выполняется 5 дней! Конечно, можно сделать первый раз 'Номер 1 из кейса 2', потом 5 дней гнать след. по циклу фигню 5 дней, а потом 'степ 264 из кейса 593746525' , потом 5 дней гнать след. по циклу фигню 5 дней ... К 1 сентября закончу ... :-(

/** "Граф" (схема) выполнения существует для тестов, но для стэпов его нет и быть не может **//.
Я знаю фирму, которая отчаилась просить у MI написать это, и написала сама свою приблуду. Просили это сделать (только на моей памяти) с версии 6.5

#38 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 26 ноября 2003 - 07:39

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

#39 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 26 ноября 2003 - 09:07

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

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

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

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

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

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

:rolleyes:
  • 0
Гринкевич Сергей

#40 pioner

pioner

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • Город:Москва

Отправлено 02 декабря 2003 - 15:28

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


Программирование на С# для тестировщиков
онлайн
Автоматизатор мобильных приложений
онлайн
Selenium WebDriver: полное руководство
онлайн
Программирование на Python для тестировщиков
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале