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

[Green]

В действительности, здесь палка о двух концах.

При всей выгоде написания приложения своими силами под свои задачи, существует проблема "чемодана без ручки".

На фирме открывается не рентабельный проект на который выделяются ресурсы по остаточному принципу, т.е. что осталось от коммерческих проектов. Команда часто меняется, продукт делается урывками и т.п.

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

[Green]

Проблема ценообразования на ПО это еще та песня!

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

Если идти честным путем и покупать лицензионное ПО, то такое в странах СНГ могут позволить себе не многие. Соответственно, западные специалисты, которым это более доступно, будут иметь преимущество на рынке труда, а западные компании будут иметь более квалифицированных специалистов. Это называется политика протекционизма.

[Олешка]

Все так и есть. ИМХО, поэтому документ, содержащий функциональные требования к тестовому тулу, может и должен использоваться либо для принятия взвешенного и обоснованного решения о разработке, либо для выбора между предлагаемыми на рынке инструментами.

[Case]

Для выбора из предоставленных на рынке тулов есть несколько отличный вариант.
Я его анонсировал, но видимо скромно. Повторюсь.

Оценочная карта инструмента автоматизированного тестирования приложений с графическим интерфейсом.

Кстати взято из книги Автоматизированное тестирование программного обеспечения. Мне эта книга нравится всё больше и больше.

[Dmitry_NJ]

AQdevTeam тоже не все может :(
Сейчас как раз нахожусь в поиске тула для test managementa. Хочется много всего, а нету...

Вы же вроде QTP юзаете. Не пробовали реализовать свои требования к test management тулу в TestDirector'e? Oн довольно гибок в плане настройки под конкретные нужды. Да и об интеграции с QTP не будет голова болеть.

[Олешка]

Да дорогой он - Test Director.

[Dmitry_NJ]

Да дорогой он - Test Director.

Так и QTP не дешевый :D Раз купили, то, наверное, компания не самая бедная.

Если пользователей предполагается не очень много, то Standard Edition (где база только на MS Access) должно хватить, а Standard не такой дорогой, как Enterprise.

[Олешка]

Хмм... конечно можно и так подходить - есть лишние деньги, чего их не выбросить.
5 лицензий на Test Director стоит около 31 К$. И зачем мне выкладывать такие деньги за базу на MS Access, которая в ТСМ такая же, плюс открытый код, плюс freeware?

[Dmitry_NJ]

Хмм... конечно можно и так подходить - есть лишние деньги, чего их не выбросить.
5 лицензий на Test Director стоит около 31 К$. И зачем мне выкладывать такие деньги за базу на MS Access, которая в ТСМ такая же, плюс открытый код, плюс freeware?

Нет, деньги выбрасывать не надо. Лишних денег не бывает. А $31K стоит не база на MS Access, а TD. MS Access просто место хранения данных, в которое вообще-то лазить не стоит. И в общем случае пользователей не должно интересовать где лежат сами данные. Достаточно того, что TD знает как их представить и сохранить. Для 5 пользователей MS Access будет работать нормально, для этого не нужен Oracle или MS SQL.

Ну а freeware это и есть freeware. Американцы по этому поводу любят говорить "You have exactly what you pay for".

[Green]

To Dmitry_NJ

Дмитрий, позвольте с Вами не согласиться.

Я думаю, всем понятно, что речь идет не об MS Access. <_<

То что касается TD, это совсем другая песня. Если бы Вы почитали сообщения других обсуждений этого форума, то нашли бы много ответов, посвещенных TD. Среди них есть обсуждения недоставтков TD.

Могу сказать, что я активно использовал TD в своей работе и отказался от него именно по причине этих самых недостатков.

К сожалению, я не нашел пока такого тула, который бы позволял просто и удобно вести тест кейсы.

Может быть, Вам повезло больше?
:P

[Mike]

TD, конечно, не панацея - просто очень удобный продукт для строго определенного круга задач. И "недостатки" которые некоторые в нём находят - просто от попыток использовать инструмент не по назначению. TD - инструмент для ведения небольших проектов небольшой коммандой. Для разработки коробочных продуктов он не годится. Вообще, тот workflow, который можно создать в TD, соответстует CMM 2-го, максимум 3-го уровня. Это совсем не плохо, но годится не для всех. Чтож до его цены, то, ИМХО, стоит TD так много не из-за богатой функциональности, а из-за удобства его использования, простоты (как ни странно), и, как следствие, более быстрой окупаемости затрат. Господам QA Manageraм советую иметь это в виду.

2Дима:
AQDevTeam - не freeware - для России он стоит совсем не так уж мало. Я так понимаю, продукт это довольно мощный, но
- сырой
- требующий до кучи customization
- не слишком простой в использовании и освоении.

[Dmitry_NJ]

Могу сказать, что я активно использовал TD в своей работе и отказался от него именно по причине этих самых недостатков.

К сожалению, я не нашел пока такого тула, который бы позволял просто и удобно вести тест кейсы.

To Green:

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

Судя по всему та функциональность, которая нужна вам, мало кому нужна еще. За все компании говорить не буду, а в Mercury Interactive регулярно проходят review по запросам, приходящим от пользователей, sales инженеров, консультантов, работающих у клиентов, по анализу инструментов конкурентов. Product Marketing вместе с R&D очень внимательно относятся к этому, и если на какую-то отсутствующую функциональность спрос превышает критическую массу, она в итоге реализуется в продукте.

Конечно, если вы VIP клиент с корпоративным контрактом и premium уровнем саппорта :D , то вам сделают все персонально и вам не придется ждать выхода новой версии. Но в России таких клиентов абсолютно точно нет :D

[Dmitry_NJ]

TD - инструмент для ведения небольших проектов небольшой коммандой. Для разработки коробочных продуктов он не годится.


2Дима:
AQDevTeam - не freeware - для России он стоит совсем не так уж мало. Я так понимаю, продукт это довольно мощный, но
- сырой
- требующий до кучи customization
- не слишком простой в использовании и освоении.

Mike, если ты имел в виду TD Standard Edition, когда говорил о небольших проектах и небольшой команде, то согласен. Если же в качестве back-end у тебя нормальная СУБД, то какие проблемы? Я знаю компанию, которая является самым крупным клиентом на TD в Европе - лицензия на 500 пользователей с опцией увеличения до 1000. Ну и работают они нормально. Так что дело не в количестве пользователей, а в тех требованиях, которые предъявляются к продукту.

И для разработки коробочных продуктов TD еще как годится. Скажу по секрету :D , что внутри Mercury используется именно TD для управления тестированием своих же продуктов. Думаю, что ты не будешь спорить, что WR, QTP или LR являются именно коробочными продуктами ;)

Я не в курсе какой именно freeware имела в виду Олешка в своем постинге. Наверное, не про AQDevTeam речь шла. Ну а то, что AQDevTeam сырой и требует кучи customization это неудивительно. Маленькие компании просто не могут довести продукт до ума, "вылизать" его, чтобы пользователем было максимально удобно с ним работать, чтобы пользователи, даже далекие от программирования, все равно могли бы работать. На это требуется время и деньги. У Mercury ведь тоже далеко не сразу появился QTP и icon-based tree view в LR для наиболее популярных протоколов типа того же HTTP.

[Green]

Я согласен, что TD мощная и продвинутая программа. Она, наверное, самая удобная программа из всех, которые я видел.

Но...
Поправте меня, если я не прав. :-)

Она не поддерживает использование шаблонов тест кейсов.

Пример.
- Есть 100 разных категорий, содержащих наборы файлов.
- В каждой категории, как минимум, с одним файлом я должен провести 4 теста (создать, отредактировать и пр...)
- Каждый тест необходимо провести, как минимум, с 4 классами входных данных (корректные, корректные граничные, не корректные и некорректные граничные)
- По каждому тесту необходимо иметь отдельную статистику, т.е. необходимо знать, что тест для категории 13 по созданию файла с некорректными входными данным не прошел (при этом, этот же тест с другими входными данными был успешным).
ИТОГО: 100 х 4 х 4 = 1600

1600 - именно такое число тест кейсов необходимо внести в TD, что бы по кажому тесту иметь одельную статистику и прослеживать результат на протяжении проекта.

И их нужно внести туда ручками!

На самом деле, эта задача легко решается с помощью 4 шаблонов тест кейсов, таблицы категорий, таблицы входных данных и матрицы выполненных тест кейсов.
:ph34r:

[Mike]

Дима, насчёт ограничений TD для коробочных продуктов - cм. тему TestDirecor 8.0 на в форуме по Мercury Interactive -там мы очень подробно обсуждаем эту тему. Буду рад любым комментариям, может, я и правда ошибаюсь. Смысл же сводился к тому, что при работе над коробочным продуктом, имеется одновременно много "веток" тестирования - одновременно тестируется (используя, частично, одни и те же тесты) разные версии продуктов (например, Standard и Enterprise). А маппинг статуса последнего прогона тестов на требования - всего один. То же (,кажется,) касается и одновременного прогона нескольких Test Suites (не помню, как это называется в TD) использующих одни и те же тесты. В TD "ветка" разработки и тестирования должна быть одна на один проект. Иначе - заводи копию проекта. Если я не прав - давай продолжим дискуссию в теме про TD - там это более к месту, и, повторюсь, уже подробно обсуждалось.

Green, во первых, шаблоны в версии 8.0 есть. Во-вторых, есть другой вариант - вызывать тесты с разными параметрами (есть в TD такое свойство у тестов). А в качестве параметров брать тестовые данные. Из любого теста можно вызвать любой другой. Этот другой и использовать в качестве шаблона ;) .

[Dmitry_NJ]

Дима, насчёт ограничений TD для коробочных продуктов - cм. тему TestDirecor 8.0 на в форуме по Мercury Interactive -там мы очень подробно обсуждаем эту тему. Буду рад любым комментариям, может, я и правда ошибаюсь. Смысл же сводился к тому, что при работе над коробочным продуктом, имеется одновременно много "веток" тестирования - одновременно тестируется (используя, частично, одни и те же тесты) разные версии продуктов (например, Standard и Enterprise). А маппинг статуса последнего прогона тестов на требования - всего один. То же (,кажется,) касается и одновременного прогона нескольких Test Suites (не помню, как это называется в TD) использующих одни и те же тесты. В TD "ветка" разработки и тестирования должна быть одна на один проект. Иначе - заводи копию проекта. Если я не прав - давай продолжим дискуссию в теме про TD - там это более к месту, и, повторюсь, уже подробно обсуждалось.

Mike,

Да мне, собственно, нечего добавить, кроме того, что TD реально используется для тестирования коробочных продуктов. Я не в курсе организации внутренней кухни QA Department'a в Mercury - проекты они новые создают или работают с разными ветками в одном проекте, но факт вещь упрямая и с ним спорить сложно.

[AIN]

2Green:


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

Спасибо.

[Green]

to AIN

Шаблон тест кейса не содержит этих данных.

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

В зависимости от специфики приложения в таблицу "шаблон тест кейса - тестовые данные" могут быть добавлены другие идентификаторы. Например - роль пользователя, под которой тестировщик должен пройти данный тест, или тестовое окружение.

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

[AIN]

to Green.

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

Шаблон тест кейса:
TTC.001 Добавление товара

Тестовые данные:
TD.001 Товар1
TD.002 Товар2

Тестовые роли:
TR.001 Оператор
TR.002 Менеджер

Результирующая таблица тест кейсов:
TC.001 TTC.001 TD.001 TR.001
TC.002 TTC.001 TD.002 TR.002

Правильно я понял?

Куда вы помещаете такие данные, как ожидаемый результат, реальный результат, пост и пред условия, состояние TC, в результирующию таблицу?