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

[Олешка]

ИМХО, если фраза требует дополнительных комментариев, надо ее делать короче, разбивать на две, или менять. Я бы убрала процессы разработки ПО даже из фона, но это только мое мнение, что вовсе даже и не претендует на истину в последней инстанции. Жаль, если сложилось такое впечатление, впредь постараюсь выражаться аккуратнее. ;)

[Case]

Олешка, ещё раз повторюсь -- спасибо за критику!
К мнению прислушаюсь.

[Dmitry_NJ]

Господа, интересует Ваше мнение на простую статью по определению критериев анализа средств автоматизации, с которой можно ознакомиться в лаборатории Тестера: Разработка критериев анализа систем автоматизации тестирования
Принимается критика, уточнения.

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

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

Эта фраза более, чем странная. Если уж степень зрелости вендоров принималась во внимание (что вполне разумно), то вышедшие в итоге в "финал" Mercury Interactive и AutomatedQA, выражаясь спортивным языком, это команды из разных лиг. Mercury Interactive существует с 1989 года, а с 1993 года их стоки торгуются на биржах. Информации о годе основания AutomatedQA я не смог найти даже на их сайте.

Согласно, аналитическому отчету IDC "Worldwide Distributed Automated Software Quality Tools Forecast and Analysis, 2003-2007", рыночная доля Mercury Interactive составляла 55%, и компания была единственной из всех вендоров, чья доля увеличилась, т.е. Mercury Interactive отбирает клиентов у своих конкурентов. AutomatedQA не была даже упомянута (!) в отчете, заняв "почетное" место в графе "Others".

По поводу технической поддержки. Mercury Interactive 3-й год подряд получает WebStar Service Award от Service & Support Professionals Association (SSPA). Есть возможность обратиться в службу технической поддержки по телефону/email или через web site. У AutomatedQA, судя по их страничке Support, доступно обращение только по email. Ни телефона, ни web интерфейса. А ссылки на различные newsgroups это, конечно, хорошо, но это НЕ саппорт, в истинном смысле этого слова. Таких форумов в интернете по любому продукту, в том числе и по продуктам Mercury Interactive, масса, там обсуждаются различные пути решения проблем, но это НЕ официальный ответ саппорта. Это всего лишь мнение человека, который хуже или лучше разбирается в теме, пусть даже этот человек работает в AutomatedQA. И за последствия своего совета на бесплатном форуме никто ответственности не несет.

Вообще-то, прочитав статью, сложилось впечатление, что главным критерием в итоге оказалась голая цена продукта. Судя по всему, никакого сравнения продуктов по таким важным параметрам, как TCO (Total Cost of Ownership) и ROI (Return on Investments) не производилось совсем.

Подсчитывалось ли сколько денег будет стоить каждый час простоя, если невозможно будет продвинуться дальше без помощи тех. поддержки? Возможно, автору статьи известно об AutomatedQA больше, чем мне, но я не нашел информации о существовании европейского саппорта у AutomatedQA. А разница во времени с Невадой - 11 часов (для Москвы). Большие сомнения, что саппорт будет работать 24х7. А если будет, то такая поддержка стоит дополнительных и, как правило, немаленьких денег.

Собственно, это мои .02с по данной теме. А в целом, статья, конечно, написано грамотно.

[Case]

Dmitry_NJ, спасибо за критику.
Теперь более предметно.
Как Вы верно заметили ROI и TCO не брались в рассчёт как таковые. Их оценка и учёт как по мне отдельный бизнес, то есть если учитывать чисто экономические факторы (а их бехусловно нужно учитывать) исследование получится несколько иного характера. Задача была дать базу, от которой можно отталкиваться при выборе.

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

[Mike]

Дима, имей в виду, речь шла о нашей, российской специфике. У нас Mercury имеет примерно те же позиции, что и Segue (и если ситуация начинает менятся, то за счёт нелегального использования). Так что реально в России и СНГ ситуация такая (на легальном рынке): серьёзные, давно существующие компании уже давно используют Rational, более мелкие и молодые присматриваются к TestComplete - из-за дешевизны, главным образом. Что до его качества - ну, не самое плохое качество. Лучше того же RobotJ, например - а Rational, надо думать находится в той же лиге что и Mercury ;). А вот саппорт у Mercury действительно вне конкуренции - и это не плохо бы упомянуть.

[Case]

Господа, статья направлена в первую очередь на людей, которые пытаются выбрать тул.
То есть оговариваются моменты, на которые стоит обращать внимание, приводятся примеры компаний, но при этом нет рекламы того или иного инструмента. В качестве реального применения приведён пример из моей практики, и тут всё как и говорил Mike, молодая компания, которой нужно удобное и недорогое решение - как закономерный результат: TestComplete. Но я не ставил задачу за счёт "упускания" возможностей того или иного тула, вывести ТестКомплит, нет и сравнительных характеристик, по той же причине.

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

[Dmitry_NJ]

Дима, имей в виду, речь шла о нашей, российской специфике. У нас Mercury имеет примерно те же позиции, что и Segue (и если ситуация начинает менятся, то за счёт нелегального использования). Так что реально в России и СНГ ситуация такая (на легальном рынке): серьёзные, давно существующие компании уже давно используют Rational, более мелкие и молодые присматриваются к TestComplete - из-за дешевизны, главным образом. Что до его качества - ну, не самое плохое качество. Лучше того же RobotJ, например - а Rational, надо думать находится в той же лиге что и Mercury ;). А вот саппорт у Mercury действительно вне конкуренции - и это не плохо бы упомянуть.

Миша, как ты понимаешь, я в курсе нашей российской специфики и прекрасно знаю что именно принимается в первую очередь во внимание российскими менеджерами. Из всей моей консультантской практики в России был только один CIO, который спросил у нас не про цену, а про то сколько будет стоить владение продуктом в течение 5 лет. И я не удивился, когда у него в кабинете заметил приз, полученный как лучший CIO года в России.

Да, я согласен, Rational, Compuware находятся в той же "лиге", что и Mercury. Но про тех, кто пока не выбрался из категории "Others", я такого сказать не могу.

Насчет того, что серьезные, давно существующие компании используют Rational не совсем так. Если быть точным, то они давно КУПИЛИ инструменты Rational, но вот как они их ИСПОЛЬЗУЮТ это отдельная песня. Сам прекрасно знаешь один ну очень большой и известный банк, в котором тебе довелось делать пилотные проекты и по WR и по TD. Да и по LR, кажется, тоже, но это уже без меня было. Они давно купили Rational. Ты видел хоть какие-то более или менее внятные результаты реального ИСПОЛЬЗОВАНИЯ этих инструментов? То-то и оно...

Кстати, стоит заметить, что такое преобладание продуктов Rational (я говорю только о продуктах для тестирования) на российском рынке вызвано вовсе не каким-то отменным их качеством, а полным отсутствием альтернативы еще несколько лет назад. Выбирать и сравнивать было просто не с чем. Mercury, Segue были полнейшей экзотикой, поскольку в России продвижением этих продуктов никто не занимался. Ну а в тех странах, где альтернатива была давно, как ты знаешь, ситуация соверешенно иная. И у нас она изменится со временем, так же как со временем все больше людей пересаживается с Жигулей на нормальные машины.

[Mike]

2Dmitry_NJ: Знаешь, ещё год назад я бы с тобой польностью согласился (о перспективах) . Сейчас же то что я вижу на этом рынке (я имею в виду только автоматизацию функционального тестирования) - очень грустно. Да, WinRunner по сравнению c Роботом как Мерседес (20-летней давности) по сранению с Жигулями такой-же давности. Только вот если сравнивать QTP c WinRunnerом это (извини, за смену контекста) cравнение фотоаппарата "Зенит" с новейшей цифровой, но мыльницей (баксов за 300) от Epson или Canon. Красиво, удобно, всё одной кнопкой, только вот гибкости маловато, и результат использования до профессионального не дотягивает... Программировать на QTP тольком нельзя. Как и писать большие тесты (больше сточек 70). Record/Replay - шикарный. Удобство IDE - выше всяких похвал - только ActiveScreen чего стоит. Но вот писать на нём серьёзный набор тестов я бы не рискнул. Про RobotJ от Rational я даже и не говорю - одни междометия <_< . Продуктов в нише WinRunnerа не остаётся вообще. И это чрезвычайно грусно.

[Dmitry_NJ]

2Dmitry_NJ: Знаешь, ещё год назад я бы с тобой польностью согласился (о перспективах) . Сейчас же то что я вижу на этом рынке (я имею в виду только автоматизацию функционального тестирования) - очень грустно. Да, WinRunner по сравнению c Роботом как Мерседес (20-летней давности) по сранению с Жигулями такой-же давности. Только вот если сравнивать QTP c WinRunnerом это (извини, за смену контекста) cравнение фотоаппарата "Зенит" с новейшей цифровой, но мыльницей (баксов за 300) от Epson или Canon. Красиво, удобно, всё одной кнопкой, только вот гибкости маловато, и результат использования до профессионального не дотягивает... Программировать на QTP тольком нельзя. Как и писать большие тесты (больше сточек 70). Record/Replay - шикарный. Удобство IDE - выше всяких похвал - только ActiveScreen чего стоит. Но вот писать на нём серьёзный набор тестов я бы не рискнул. Про RobotJ от Rational я даже и не говорю - одни междометия <_< . Продуктов в нише WinRunnerа не остаётся вообще. И это чрезвычайно грусно.

Mike,

WinRunner был и остается замечательным тулом, но время не стоит на месте. Время и клиенты требуют тулов, которые позволят выполнять работу быстрее и будут менее критичными к уровню квалификации пользователей. Согласись, что человеку без программистского background'а гораздо приятнее работать с QTP, чем с WR. И такой человек гораздо быстрее начнет приносить отдачу, работая с QTP, чем с WR. Отсюда icon-based tree view, ActiveScreen и прочие примочки.

Какой подход лучше это вопрос философский. Классический пример - 2 самые популярные СУБД - Oracle и MS SQL. В Oracle всегда добавят в конфигурационный файл какой-нибудь 1001 параметер, о котором должна болеть голова. Зато гибкость обеспечена. MS SQL - прост, как 3 копейки, потому что Microsoft исповедует принцип "расслабься, за тебя думает машина".

Реальность такова, что QTP приходит на смену WR. В WR уже давно не появлялось ничего принципиально нового - баги почти все отловили, слегка улучшают GUI и добавляют интеграцию с QTP. У Mercury очень хороший нюх на рыночную конъюнктуру, ставка сделана на QTP в качестве флагмана для функционального тестирования. Oн постепенно берет все лучшее от WR. В QTP 5.х, например, не было ничего похожего на GUI Map в WR. В 6-ой версии появился object repository. Ну и так далее.

К сожалению, не довелось серьезно поработать с QTP, поэтому не могу с тобой поспорить на предмет недостаточной гибкости продукта. Хотя, на первый взгляд, VBScript представляется ничуть не хуже, чем TSL.

[Case]

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

[Dmitry_NJ]

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

Case,

оценка эффективности вложений в средства автоматизированного тестирования относится к трудноформализуемым областям знаний. До определенной степени это своего рода искусство, которым, например, могут владеть sales, CIO и пр. Будучи чисто техническим специалистом, никогда не занимался ни чем подобным. Полагаю, что вы можете поискать интересующую вас информацию в интернете. Со своей стороны, могу поделиться с вами информацией, которую вы нигде не найдете - методика оценки ROI для инструментов функционального и нагрузочного тестирования, которую используют в Sales Department Мercury Interactive. Это уже готовые калькуляторы (Excel spreadsheets) с объяснением того, как они работают (для функционального тестирования есть еще и объяснение методики расчета). Если вам это интересно, то оставьте свой email, и я вам перешлю эту информацию. Само собой, что она на английском языке.

[Case]

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

Интересно и нужно. Адрес у меня простой: case@tester.com.ua

Собственно у меня диплом практически так называется:
"Исследование эффективности внедрения в процесс проектирования программных комплексов средств автоматизированного тестирования". Не рассчёт конечно, но исследование. Посмотреть рабочую версию можно здесь: http://pankratov.org.ua/diplom/

[ip47]

Со своей стороны, могу поделиться с вами информацией, которую вы нигде не найдете - методика оценки ROI для инструментов функционального и нагрузочного тестирования, которую используют в Sales Department Мercury Interactive. Это уже готовые калькуляторы (Excel spreadsheets) с объяснением того, как они работают (для функционального тестирования есть еще и объяснение методики расчета). Если вам это интересно, то оставьте свой email, и я вам перешлю эту информацию. Само собой, что она на английском языке.

Нельзяли и мне замэйлить калькуляторы на serguei@usa.com. Правда, наша компания уже практически купила QTP, но было бы замечательно поиметь какое-нибудь подтверждение того, что выбор был правильный :).

P.S.: Если кому интересно, оценивались абсолютно различные тулы применимо к совершенно конкретным задачам. Финалистами были QTP от Mercury, Silk от Segue и TestComplete от AutomatedQA. Апликации: MFC-based, Web, Java, .NET.

AutomatedQA отсеился первым. Собственно в финал он попал из-за своей дешивизны. Но к сожалению он не оправдал надежд в случае работы с customized controls ни в одном из случаев. В-общем, это отличная кликалка по батонам, если кому нужен Load/Volume тест. Но для функционального тестирования он не очень пригоден.

Выбор между QTP и Silk был довольно трудным. Мы работали с sales и инженерами и обеих компаний. Silk сильно прибавил в последнее время, если кто помнит что за тул это был раньше. Результаты: Silk - дешевле раза в 3 (тем более у нас уже была купленная версия), очень flexible в смысле написания тестовых скриптов, менее стабильный чем QTP, есть трудности в работе с некоторыми контролами, но впрочем для всего нашелся workaround. QTP - ощутимо более дорогой, простой в использовании если надо что-то просто записать и проиграть, очень стабильный (крашался всего пару раз за все время испытаний :), очень хорош с большиством контролов (сравним пожалуй только с загубленным, но сильно любимым VisualTest), менее удобен при написании скриптов вручную. Как узкий специалист и любитель пописать всякий код, я бы выбрал Silk ;). Но с позиции менеджеров QTP выглядел привлекательнее т.к. позволяет сократить требования к подготовке специалистов. Ну а так, оба тула примерно равны, если сложить все достоинства и недостатки. Все вышесказанное - мое личное мнение.

[Dmitry_NJ]

Нельзяли и мне замэйлить калькуляторы на serguei@usa.com.

Oтправил.

Думаю, что саппорт Mercury вам понравится больше, чем саппорт Segue. Это будет еще одним плюсом за выбор QTP.

[Case]

AutomatedQA отсеился первым. Собственно в финал он попал из-за своей дешивизны. Но к сожалению он не оправдал надежд в случае работы с customized controls ни в одном из случаев. В-общем, это отличная кликалка по батонам, если кому нужен Load/Volume тест. Но для функционального тестирования он не очень пригоден.

Дабы Ваше высказывание не выглядело голословным, приведите пожалуйста примеры, когда TC от AutomatedQA не потянул конкретный контрол. И если можно боле подробно описать, почему он не тянет на инструмент функционального тестирования, здаётся мне просто уткнулись в какую-то конкретную проблему и не решив откинули, да ещё и с таким диагнозом. Мы к примеру им проводим именно функциональное тестирование и уткнулись пока в проблемы с которыми тот же Робот точно также не справлялся - значение взять из грида к примеру.

[ip47]

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

Наша компания производит несколько различных продуктов, значительную часть функциональности которых составляет генерация всевозможных репортов. Для эвалуации мы взяли 3 аппликации: JSP-based, MFC-based и Java-based. В двух словах, каждый тест заключался в запуске приложения/логине, открывании определенного объекта/файла, создании списка параметров выполнения (input parameters), генерации репорта и проверки результата. Большинство тулов справлялись с разной степенью успеха со всеми шагами вплоть до проверки результатов. Проблемма заключалась в том, что если вы проверяете правильность генерации репорта, то здесь все имеет значение: положение контролов, цвет текста, тип шрифта и т.д. К сожалению мы не смогли заставить TestComplete различить между собой десяток различных контролов, поскольку они различались только по параметрам, невидимым для тула. То есть ситуация была такова: в репорте есть несколько лейблов с различным текстом разного цвета, но нет возможности задать по ним проверку поскольку свойств их различающих в туле не видно. С JSPs была отдельная проблема: тул видел только основной фрейм и не различал объекты на странице вообще.

Я хочу подчеркнуть, что не считаю TestComplete плохим тулом. С помощью него можно (и нужно;) решать определенные задачи. Он нас вполне устроил бы если бы мы удовлетворились частичным покрытием. Просто у нас была основная цель: найти тул который бы позволил нам тестировать ВСЕ наши продукты. Так что компании пришлось раскошелиться.

[Case]

ip47, спасибо за пояснения.
Просто вдруг стало за державу обидно! :)
Кстати, а в документации к томуже ТестКомплиту разве не указано что именно он "умеет видеть"? Просто у различных тулов разная заточка, у нас вот к примеру приложение на .NET и с видимостью свойств контролов как проблем нет.