Цена/Качество

Все-таки редактор и скриптовый язык это вторично. Первично - умение работать с контролами среды и иметь возможность кастомизации для неподдерживаемых out-of-the-box контролов.

это как раз то, про что ранее сказано "нивелируется". Даже если будет самая расчудесная поддержка контролов, но код будет неудобно/долго писать и при этом он будет неправильно работать - то извините.

как говорится, +1

с ужасом вспоминаю попытку сделать проект на QTP 6.5 (может, сейчас что-то лучше).
тестирование web-приложения. все распознается и нажимается ;) но...

- VBScript - ужас. exception handling непередаваемо неудобен. впрочем, как и многое остальное. Да, я знаю - зажрался, избаловался и т.п. ;) Что мешало сделать выбор между этим уродцем и, например, человеческим JavaScript - не ясно.

- reusability кода там никого не волновало, явно. т.е. подобие есть, но использовать это может только мазохист.

-- Actions имеют свои проблемы с удобством передачи параметров, тем что происходит при удалении Action.

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

-- ладно, подключили все это. но - дебаггер не позволяет отлаживать код в библиотеках. WTF? в Mercury's KB описано как известное issue.

-- при ошибке в коде, вынесенном в библиотеку тест просто прекращает свое выполнение. При этом не помечается как failed. Опять-таки известное issue. В итоге пишется своя подсистема логгинга, которая ето дело просекает.

И еще какие-то грабли кои уже, к счастью, подзабылись.

Могу сказать одно - аналогичный пилотный проект на Selenium + JavaScript был сделан намного быстрее и с меньшим количеством граблей. Стал не пилотным.

Я понимаю, что в случае специфичных сред QTP при всех этих граблях может не иметь конкурентов. Или иметь очень мало конкурентов. Но меня интересовал веб.

Опять таки понимаю, что может быть проще нанять 50 человек, которым все эти библиотеки по барабану. Наплодить кода методом record/playback и раз в 3 билда его на 80% менять/перезаписывать.

P.S. все вышесказанное - мое личное мнение, не есть мнение компании, в которой я работаю и т.п.

Что же касается твоих уколов в сторону TestComplete... Подожди ещё года 2-3. Вендоры ещё будут соревнаваться кто больше предложит бесплатных сервисов и ниже опустит цены. Не могут же они вечно расти. Уже сейчас бесплатные решения иногда выигрывают по качеству у вендоров. Осталось только дождаться когда это распробуют корпорации.

Миша, ну какие уколы? Нам нечего делить с TC, у каждого свой кусок хлеба, своя целевая группа кастомеров. По поводу того, что в бизнесе хорошо и бесплатно долго не бывает, так это же очевидно совершенно. Чудес на свете не бывает. Ты будешь за бесплатно работать? Нет. И я не буду. И люди, которые работают в саппорте, тоже не за бесплатно трудятся. Кто-то ведь все это оплачивает. Если компания предлагает что-то бесплатно, то значит она отбивает эти деньги на чем-то другом. На чем еще бизнес может отбивать деньги, кроме как на своих клиентах? Растет клиентская база - растет нагрузка на саппорт, появляются новые сотрудники - нужны новые деньги. Откуда? Все оттуда же. Клиент не платит за саппорт? Значит эту стоимость включают в стоимость продукта или, например, обновления делают не бесплатные, а за деньги. Еще раз говорю чудес в бизнесе не бывает. Это из разряда бесплатной медицины и образования в совке.

А по поводу бесплатных сервисов не знаю. Не берусь гадать что будет через 2-3 года. На данный момент у нас те же самые сервисы ну очень небесплатные. И я пока не вижу никаких подвижек в сторону того, что кто-то может предложить что-то аналогичное бесплатно.

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

All,

Вы как-то очень вольно трактуете понятие "вторично". "Вторично" != "не важно, малозначимо". Я употребил понятие "вторично" по отношению к тому, что "первично". Когда вы выбираете тул для функционального тестирования каким первым вопросом вы задаетесь? Поддерживает ли тул ту среду, в которой создано мое приложение, или какой язык разработки скриптов у этого тула? Сдается мне, джентельмены, что начинается все именно с первого вопроса. Если тул не в состоянии распознавать объекты моего приложения и не имеет возможности сделать это с помощью какого-нибудь своего extensibility package, то какая разница какой у него язык разработки скриптов? Мне все равно придется опуститься на уровень кода приложения и превратиться в еще одного программиста.

Вы как-то очень вольно трактуете понятие "вторично". "Вторично" != "не важно, малозначимо". Я употребил понятие "вторично" по отношению к тому, что "первично". Когда вы выбираете тул для функционального тестирования каким первым вопросом вы задаетесь? Поддерживает ли тул ту среду, в которой создано мое приложение, или какой язык разработки скриптов у этого тула? Сдается мне, джентельмены, что начинается все именно с первого вопроса.

первично - "можно ли при помощи XXX решить проблемы YYY, с минимальными затратами создав расширяемую, поддерживаемую систему".

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

Ну, QTP довольно далеко ушел от 6.5. Почти все перечисленные недостатки (кроме VBScript, который всё-же имеет и плюсы и глюков, случающихся ещё иногда при отладке) устранены. А программировать можно было и в версии 6.5, и мы вполне не безуспешно этим занимались. Хотя сейчас отладка библиотек в версиях до 9-ки вспоминается как кошмар. Но во времена 6.5 opensource инструменты были в зачаточном состоянии. И впадали в ступор на банальных IFRames + https + диалоги IE... Плюс, всё-таки, большое количество вкусностей у вендорских инструментов, типа Object Repository, DataTable, чекпойнты и прочее. Да, программируется на ура за... 2-3 месяца (считая отладку). Но... В общем сейчас мы подумываем о переходе на opensource инструменты. Но боюсь, Learning Curve + время на разработку собственного фреймворка не позволят сделать это за приемлемое для менеджмента и заказчика время.

"Поддерживает ли тул ту среду" - всего лишь один из вопросов на начальном этапе пути. Один из пунктов начального фильтра - поддерживаемые среды, тех. поддержка, коммъюнити, цена

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

Но боюсь, Learning Curve + время на разработку собственного фреймворка не позволят сделать это за приемлемое для менеджмента и заказчика время.

Вот именно Вместо того, чтобы работать на внешний проект, за который заказчик платит деньги, часть людей должна будет заниматься внутренним проектом по разработке такого framework, который денег не приносит. Потом ведь все это хозяйство надо документировать, поддерживать, развивать, обучать как им пользоваться. А это все требует времени, которое деньги. А если придется тестировать что-нибудь экзотическое (не web-based)?

А можно ссылочку ?
я поискал здесь:
http://www.mercury.c...t-professional/
и related pages
но ни слова об этом не нашел.

Далеко искали Можно было найти прямо на нашем форуме: http://forums.softwa...?showtopic=7981

Кстати и не нашел и список новых фишек в 9.2 по сравнению с 9.1 например. Такое ощущение что эта информация специально спрятана (также как и информация о ценах) от потребителей - чтобы о ней никто не дай бог не узнал

На корпоративном сайте обновляют информацию о продуктах только тогда, когда выходит новый major release. Информация обо всех minor release'ах, включая what's new, публикуется на сайте тех. саппорта в разделе Product Alerts.

Правильно ли я понимаю что эта секция (на сайте тех. саппорта в разделе Product Alerts) недоступна для тех кто еще не является пользователем продукта ? А сделано это специально для того чтобы потенциальные пользователи не дай бог не узнали об добавленой функциональности в новых минорных версиях ? И что если бы на форуме не было бы такого консультанта от Меркури как Дмитрий, то мы бы никогда не смогли узнать что Mercury заявила поддержку .NET v.3 в своем продукте ?

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

Это, кстати, интересная мысль. Как я понимаю, это уже произошло с Mercury когда ее купила HP. А как вы думаете Дмитрий, событие покупки отражается на бизнесе (или лучше сказать клиентах компании) положительно или отрицательно?

Например, QTP на сайте HP находятся в разделе ***legacy*** Mercury products. Если бы я сейчас выбирал средство тестирование - слово legacy меня бы очень насторожило, и бы подумал над тем фактом что теперь, для HP производство средств автоматизированного тестирования не является primary bussines и возможно (возможно!) что этот бизнес не будет активно развиваться или даже будет постепенно свернут. Никто конечно не будет резать курицу несующую золотые яйца - но бизнес есть бизнес и мне, например, известен случай когда успешная компания была куплена из за коллектива разработчиков, которых перебросили на другие проекты, а довольно успешные (и развивавшиеся на момент покупки) проекты компании были полностью приостановлены. Поэтому мне было бы интересно узнать ваше мнение на этот счет, как человека пережившего процесс покупки внутри компании.

"Поддерживает ли тул ту среду" - всего лишь один из вопросов на начальном этапе пути. Один из пунктов начального фильтра - поддерживаемые среды, тех. поддержка, коммъюнити, цена

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

Не часто, но бывают случаи, когда вообще нет тулов, которые поддерживают некоторую среду. Поэтому это очень хороший "задел на будущее" - заранее выбрать более гибкий и надежный ;)
Во вторых - цена, это такой же намаловажный фактор как и поддержка среды. Будь это даже единственный инструмент в своем роде, но с ценой "от самолета", обсуждать его тоже будут "не все"

Но боюсь, Learning Curve + время на разработку собственного фреймворка не позволят сделать это за приемлемое для менеджмента и заказчика время.

Вот именно Вместо того, чтобы работать на внешний проект, за который заказчик платит деньги, часть людей должна будет заниматься внутренним проектом по разработке такого framework, который денег не приносит. Потом ведь все это хозяйство надо документировать, поддерживать, развивать, обучать как им пользоваться. А это все требует времени, которое деньги. А если придется тестировать что-нибудь экзотическое (не web-based)?

Для QTP мне также пришлось тратить время на разработку своего фреймворка. Использование QTP в качестве record-replay инструмента - пустая трата времени и денег. Просто для QTP он у меня уже есть, а для opensource тулов - пока нет. Что же до обучения, то оно в любом случае требуется. Вопрос сейчас только в том, что у меня нет времени переезжать на новый инструмент (любой) и мигрировать существующие тесты.

Правильно ли я понимаю что эта секция (на сайте тех. саппорта в разделе Product Alerts) недоступна для тех кто еще не является пользователем продукта ?

Да, понимаете правильно.

А сделано это специально для того чтобы потенциальные пользователи не дай бог не узнали об добавленой функциональности в новых минорных версиях ?

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

И что если бы на форуме не было бы такого консультанта от Меркури как Дмитрий, то мы бы никогда не смогли узнать что Mercury заявила поддержку .NET v.3 в своем продукте ?

К этой информации имеет доступ любой, кто имеет легальную лицензию на QTP. Так что выложить ее мог кто угодно.

Не часто, но бывают случаи, когда вообще нет тулов, которые поддерживают некоторую среду. Поэтому это очень хороший "задел на будущее" - заранее выбрать более гибкий и надежный ;)

Когда ни один из тулов не поддерживает это уже совсем другой случай. Я то говорил об ином.

Во вторых - цена, это такой же намаловажный фактор как и поддержка среды. Будь это даже единственный инструмент в своем роде, но с ценой "от самолета", обсуждать его тоже будут "не все" 

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

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

Дима,

Вы когда в магазине хотите купить чайник, то идете туда где можно купить чайник или сначала в отделе телевизоров и долго интересуетесь как быстро они кипятят воду?

Я иду к чайникам.

т.е. если мне нужен тул для веб тестирования - я смотрю тулы для веб тестирования. Как в отделе магазина.

Цена сама по себе важна. но есть еще нюансы. нафига мне чайник за 1 доллар, если питается он от 417 вольт? и соотв. трансформатор стоит 500.

Так и с тулами. Стоимость == стоимость лицензий + стоимость поддержки + стоимость внедрения + стоимость сопровождения.

Стоимость внедрения и сопровождения может стать сильно ниже за счет того, что можно использовать уже имеющиеся знания и frameworks.

Как я понимаю, это уже произошло с Mercury когда ее купила HP.

Это же произошло и с Rational, когда ее купила IBM и потом с Segue, которую купил Borland. Так что на форуме должно быть много людей, которые могут поделиться впечатлениями о том положительно или отрицательно это сказалось на клиентах.

А как вы думаете Дмитрий, событие покупки отражается на бизнесе (или лучше сказать клиентах компании) положительно или отрицательно?

Это только время покажет. Слишком мало еще прошло. Хотя сделка была окончательно закрыта в начале ноября, но реально мы влились в HP только с 1 февраля (Америка, Азия) и с 1 марта (большая часть Европы). А Франция и Испания так вообще только еще 1 мая.

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

Например, QTP на сайте HP находятся в разделе ***legacy*** Mercury products. Если бы я сейчас выбирал средство тестирование - слово legacy меня бы очень насторожило

Слово legacy вас не должно смущать. В данном контексте оно означает просто "наследие", то есть то, что получила HP в результате покупки Mercury. Слово legacy никаким образом не отражает перспективы развития того или иного продукта Mercury. Могу вам сказать, что только один наш продукт - Mercury Service Desk - в результате слияния с HP умер (что было очевидно с самого начала). Все остальные "живее всех живых" и наоборот "убивают" некоторые HP-шные продукты, например OpenView Internet Services и OpenView Transaction Analyzer.

для HP производство средств автоматизированного тестирования не является primary bussines...

Естественно не является. Где HP и где средства автоматизированного тестирования? Я вам открою секрет Полишинеля - для HP не то что производство средств автоматизированного тестирования, а производство софта вообще НЕ является primary business. За прошлый финансовый год "софтовая" доля в суммарных доходах HP составила чуть более 1%. HP это всемирно известная hardware компания. Сервера, различного рода печатающие устройства, компьютеры (карманные, настольные, ноутбуки) и пр. "железяки" - вот на данный момент primary business HP.

Однако, тот факт, что HP до сих пор в основном ассоциируется с "железом" крайне не устраивает руководство. Поэтому в развитие software направления вкладываются очень большие средства - $4.5 млрд., за которые была куплена Mercury, это очень серьезная сумма. Software бизнес HP после этой покупки сразу удвоился. Уже после нас совсем недавно была приобретена еще одна софтовая компания (Bristol Technology). Т.е. развитие именно software бизнеса в HP это, если можно так выразиться, генеральная линия партии, хотя в силу исторического развития компании до сих пор пока и не primary business.

...и возможно (возможно!) что этот бизнес не будет активно развиваться или даже будет постепенно свернут.

На данный момент я не вижу ни малейших признаков того, что "тестовый" бизнес хоть как-то пострадал в результате слияния с HP. Новые версии продолжают разрабатываться, продолжают развиваться связки между Quality Center/Performance Center и центрами из других направлений бизнеса - Project and Portfolio Management Center, Business Availability Center, т.е. все это продолжает развиваться и интегрироваться под единой стратегией BTO. И просто уже вырвать из всего этого что-то одно и перестать развивать не получится - пострадает сразу все.

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

Возможно при покупке маленьких/средних компаний такие мотивы и могут иметь место. Но когда речь идет о покупке за миллиарды долларов транснациональных корпораций это, на мой взгляд, слишком мелко. Какие бы блестящие ни были разработчики или кто-там еще ради этого затевать такой геморрой никто не стал бы. Если очень надо, то перекупили бы конкретных людей - на это ушло бы гораздо меньше времени, сил и денег.