"Как-то так" у Вас вообще никакого алгоритма не получится ;)
Нельзя объять необъятное (с) Козьма Прутков

Моделирование только потому и имеет право на существование, что модель проще моделируемой сущности. Иначе модель просто не нужна.

Вы спросили откуда берется постановка задачи :)

Если модель слишком далека от жизни, то результаты в итоге получаются далекими от реальности. Т.о. пункт "Получаем постановку задачи" лучше оставить.

Для работы тестировщика, надо приобретать знания: по программированию, как работают и из чего состоят различные приложения, что и как устроено в операционных системах и т.п. Вобщем начинать с азбуки.
То, что вам легко давались какие-то пакеты - это хорошо. Но учтите, что разработчики ОЧЕНЬ старались, чтобы с ними было легко работать.

Могу дать пару советов от себя лично:
1. присмотреться к деятельности Quality Assurance - налаживать и улучшать процессы в больших компаниях.
2. Некоторые проекты (их довольно много.. и еще могут возникнуть) нуждаются в грамотной прослойке между программистами и заказчиками, чтобы облегчить всем жизнь. И по этому поводу существуют разные позиции: начиная от простого саппорта (если хочется относительно спокойной жизни, или наоборот любите командировки), заканчивая придумыванием новых фич и постановкой задач для развития проекта и подавления конкурентов (если есть амбиции и хочется работать головой). Если у вас есть идеи собственного проекта и его развития, то никто не запрещает предложить свои услуги "фирме-издателю".

Ответы на вопросы вполне доступны, и если будет время, в будущем постараюсь что-то из них перевести.

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

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

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

А если требуется посмотреть как составляется этот отчет в системе? Т.е. ситуация такая - данные в БД верны, а выборка не верна. Причем проблема не в алгоритме выборке, а просто кто-то поправил реализацию некоего метода, который используется в отчете?

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

Я согласен, это кажется вполне очевидным. Это как я понимаю и есть unit-тестирование. Однако беда в том, что по всей видимости просто выдрать такую процедуру нельзя, хотя бы из-за возможности обращения к методам других классов. А также по той причине, что в нашей системе такие методы компилируются налету в виде байт-кода с помощью java. Но мысль в общем-то понятна.

Нет, это не unit-тестирование. Unit-тесты рассматривают объекты в изолированной среде. Для этих целей используются всякие заглушки... например, вместо реального объекта, который подключается к базе данных, берется moc-объект, который просто возвращает "все ок" и к базе не обращается. Их прохождение еще не гарантирует, что все будет работать и в комплексе и с реальными объектами. То, что я описывала - это функциональное тестирование. Чаще всего это применяется к библиотекам. Все необходимое подключается к отдельному приложению (можно и собственного изготовления) и вызываем методы с разнообразными параметрами, смотрим, что возвращает или какой объект изменяет. Даже если Вам придется подключить все, что есть, кроме пользовательского интерфейса - ничего страшного. Эффективность от этой деятельности в некоторых случаях может быть гораздо выше, чем реализовывать это через gui. Все это зависит только от архитектуры и весьма индивидуально. Но если это возможно, то процесс настройки и создания много времени не отнимает.
Сорри, что применила слово "выдирать".. не расчитала.

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

А что именно повысит качество и устойчивость? Работоспособность какого-то отдельного модуля? Если Вы автоматизируете биллинг (что-то там было из нескольких шагов), и что это даст? Только сэкономит время? А сколько? Полчаса работы тестировщика? Или целый день? А там вобще были ошибки за последние полгода или его еще будут существенно изменять? Насколько это критично для системы в целом? На каком уровне там появляются ошибки (только в интерфейсе или в логике работы)?
И еще пачка подобных вопросов.
Иначе можете полгода автоматизировать справочники, хотя никто уже и не помнит, в каком году там нашли последнюю ошибку, да и пользователи их уже не открывают. А все проблемы остались. Ну или бесконечно проверять, что если у пользователя фамилия из 15 букв, начинается с согласной, он работает в отделе1, и вот когда шеф в отпуске, то у нас не создается отчет, потому что программист Вася когда-то сделал в коде опечатку.
Может гораздо интереснее проверить, что на таких-то наборах данных проходит правильная выборка хотя бы для всех старых отчетов, т.к. именно там много ошибок - это более критичный фронт работ. Ну или не мучать TestComplete, если ошибки можно найти быстрее в обход интерфейса. Если правильно определить фронт работ и подобрать нужные методы, то деятельность вскоре будет приносить ощутимые результаты.
Как-то так. :)

Понятно, думаю, заказчик тут непричем. Скорее ПМ мне не позволяет лезть в эту сторону. Логика по его мнению такова - я буду слишком много времени тратить на разработку подобных тестов, поскольку сначала мне придется узнать структуру данных, понять как там все работает, составить и отладить соответствующие запросы...

На самом деле он не прав, т.к. в реальности все сводится к подзадачам, реализацию которых программист может объяснить за полчаса. (Например, чтобы отчет был виден в базе надо заполнить три-десять таблиц такими-то данными - и тестер уже готов к тому, чтобы их заполнять, если знает SQL). Какие-то процедуры и сценарии можно вобще выдрать из кода и запускать отдельно с разными параметрами - это тоже не отнимет много времени. Вобщем, тут надо донести до ПМ, что при подобном тестировании совсем не обязательно изучать код каждой функции со всеми заморочками, главное - уметь их использовать.
Но с другой стороны, если в базе данных и библиотеках происходят довольно примитивные вещи, то вобщем-то и заморачиваться с этим наверно и не стоит. И определять, есть ли смысл вобще влезать в эти места, нужно с участием программистов.

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

А критерием может быть только достижение целей, ради которых вобще затевается автоматизация и каждая ее часть, если тестирующих проектов несколько. "Занять чем-то компы и развлечь тестеров" - это просто повод потратить время на изучение вопроса.
Если Вы можете сказать, как именно Ваш нынешний набор тестов резко улучшит жизнь (окупит затраты) в ближайшем будущем, когда они будут реализованы - отлично! Если нет, то надо думать, как бы этого достичь.

Добрый день!

TestComplete 6, Deplphi-script, web application. Редактирую на странице таблицу (допустим), применяю изменения. Вежливое приложение уведомляет меня (в идеале), что изменения были применены. Делает оно это с помощью какого-то стандартного MessageBox'a со с единственным пиремлемым свойством full name : Sys.Process('iexplore').Window('#32770', 'Windows Internet Explorer', 1). Ну и кнопка ОК.

Что нужно: быть уверенным, что вежливое приложение меня уведомило именно в том, что изменения были сохранены, а не "Какая-то ошибка, обратитесь к разработчикам" или "Ошибка с кодом -666" (ПО в первой стадии разработки).

Решение, котороя я нашла: Сравнивать картинку. Т.е сохраняю это окно с кнопкой ОК, ловлю что мне показывают и сравниваю.

Проблема: всегда говорит, что The regions are not identical, потому что посередине картинки у меня есть 1 (!) новый пиксел. иногда 2-3 пиксела.

Вопрос: как это обойти? Может быть есть еще способы узнать, что мне сказало приложение на сохранение изменений?

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

Ну и может стоит посмотреть свойства окна с сообщением и выяснить в каком свойстве содержится надпись? Т.к., ИМХО, в данном случае проще сравнить текст, как уже предложили коллеги. Предыдущий вариант написала скорее на будущее, чтобы было.

Я прикрепил пару файлов - один эталон, другой вновь созданный. Расхождения есть, вероятно убрать их можно. Вопрос каким образом? просто заменив на некие константы как предлагают greesha и rlabs?

Да, просто заменив константы.
Можно еще попробовать все сохранить в XML в том же ворде... смысл тот же, но там просто тэги на более человеческом языке обозваны + ненужное можно грохать один махом вместе с потомками, ежели появится желание... :)

Я, может, сейчас глупость скажу, но почему именно MS Word? А не Open Office или AbiWord или WordPad?

Могу точно сказать, что OpenOffice у меня когда-то криво переводил в XML, вернее постоянно добавлялись новые стили и шрифты типа : Tahoma1, Tahoma11 и т.д. по нарастающей. Вобщем, заработал мою антипатию... хотя и хорошая вещь :)
А в WordPad можно писать макросы/скрипты? Давненько его не видела... :)

Бесплатному коню в зубы не смотрят :)
Конечно нет, а тут разве нужна поддержка макросов?

Да я так, расширяю кругозор всех и вся, в том числе и свой :)

PS я к чему веду: ворд при сохранении документа записывает в него ещё много всяких одному ему ведомых метаданных. Может, альтернативные продукты позволят избежать описанных проблем с rsid и insid.

Поэксперементировала 30 секунд с WordPad - insid не встретила, а rsid присутствуют. Думаю, если формат позволяет, то будут пихать все, на что лени не хватит.
У меня такое ощущение, что пора открывать базу с "полезными тулами" и самим накапливать всякие программки/макросы под разные языки и нужды - жизнь на форуме должна упроститься.

Я сторонник исключительно простых решений. Я не совсем понимаю фразы "просто заменив их константами".
Просто пример. Открываю rtf в фаре и пытаюсь заменить все rsid на пусто к примеру - не тут то было. К тому же кроме rsid там есть много еще других проблем. В общем вижу что путь по ртф неочень перспективный.

А что именно было, когда "не тут-то было"? Желательно с примерами.
Какие именно проблемы?

У меня вопрос к знатокам word
1/ можно ли как-то управлять word из командной строки, например задать в каком формате сохранять файлы
2. если нет, а как работать с word как опен-аппликейшен, а то просто жуть, закрытее нашего тестируемого приложения. Несмотря на то, что я научился работать в word без использования мыши, TC не хочет разделять со мной мою радость

1. Создаете макрос, который вам все сохраняет.
2. Запускаете командную строку: <путь до ворда> /mname <путь к файлу>
(выделенное жирным name заменить на имя вашего макроса)

Еще можно попробовать подключить библиотеку Word и сравнить все интересующие места через API.

Вот тут что-то есть по этому поводу :)
http://www.sql.ru/fo...aspx?tid=388412
В хелпе должно быть все подробно описано :)

Но цель хаотического тестирования (то, что я видела во многих небольших компаниях) - это "потестриуйте что-нибудь, у всех наших конкурентов есть тестеры" :) А каким в данном случае может быть критерий успешности тестов? Только количество багов, так как оценить покрытие невозможно и предугадать масштабы пропуска дефектов до выхода продукта в свет - тоже. Цели контроля качества не стоит, оценки статуса продукта не стоит. Только искать баги. А это цель, при которой подойдут любые способы и любые скиллы, и процесс достижения именно этой цели я называю ad hoc или хаотическим тестированием.

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

Я знаю, что вы не знаете, что собой представляют наши продукты.
А в задачи тех-райтера входит написать документацию, как это не странно. Части документации присылаются ему разработчиками, и он, как нативный спикер, переводит с английского на английский :) Но это конечно не все, что делают наши док-райтеры. Но они не технические специалисты, а писатели - они пишут книгу, под названием User's Guide. За правильность технических деталей описанных там, отвечают разработчики и соотвественно мы тестеры, которые убеждаются, что эти детали описаны правильно.
=======
В документации к нашему продукту содержится изрядное количество технической информации совершенно новой для пользователей, т.к. мы работаем над новыми технологиями, которые только через год-два появляются, например, в сотовых телефонах. Зачастую, для использования наших продуктов требуется сложный процесс конфигурирования, причем не только самого продукта, но и environment-а (например создание IPv6 сети). Иногда, пользователям необходимо самим реализовать необходимые компоненты, которые мы просто не можем сделать за них. А как их сделать тоже описывается в доке.
В общем все не просто. Сделать скриншот, описать последовательность действий по какой-нибудь схеме и тому подобное, док-райтеры спокойно могут сделать сами. Но описать процесс создания каких-нибудь нативных библиотек в зависимости от операционки или описать организацию пользовательского канала связи они очевидно не могут.

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

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

Тут надо внести ясность с целями, содержанием документа, целевой аудиторией и т.п и распространить эти постулаты на всю команду. Они и служат критериями для выбора. Например(!!!), если с этими технологиями будут работать спецы уровня заслуженный senior developer какого-нить Intel, то боюсь ему будет очень неудобно вытаскивать из 10 страниц три действительно полезных предложения, т.к. IPv6 сеть он может развернуть с закрытыми глазами без подсказок => оставляем только особенности настроек и ссылку на документацию.
Документация должна писаться для пользователя, а не для Васи Пупкина, который вчера узнал что такое С. Как-то так. :)

Вынужден вас огорчить. Все до единого ваши предположения неправильны. Да я и не о том спрашиваю в данной теме.

Хм... простите, а откуда мне знать подробности? Я вам озвучила часто встречающиеся ошибки.

ЗЫ2: "не своего поля" у нас не бывает, т.к. каждый наш продукт общий. Например описаный мною случай, к которому вы почему-то придрались, может быть такой. Есть непростой момент, который изначально хотели как-то объяснить пользователям, описав в документации. На взгляд разработчика (у которого в голове куча еще потаенных знаний) получилось понятно, на мой взгляд (человека глубоко не зарывавшегося в спецификации) - получилась ерунда. На взгляд техлида, который больше меня в теме, но меньше разработчика погружен в детали - тоже непонятно получилось. В результате я прошу, например, исправить на более понятное описание (2 абзца, вместо 2-х предложений, которые я сам, разобравшись, могу и написать), а тех лид просит вообще убрать все это нафиг и дать ссылку на спецификацию или сторонню техничекую документацию - типа мы все-равно лучше чем там не напишем. Т.к. ревью проходит независимо у док-райтера два мнения - одно от тех-лида, одно от qa-лида (есть еще старое, девелоперское) - кого ему слушать? Понятно, что потом мы сами уже договариваемся и во второй раз он получает окончательный вариант.

С Ваших же слов:
1. Разработчик - ему все понятно и комментариев нет.
2. Вы не в теме. Вы только попросили объяснить.
3. Техлид в теме и попросил вставить ссылку на стороннюю документацию в качестве объяснений.

Актуальны только пункты 2 и 3.

Теперь приведу два утверждения:
1. Пользователю не интересно читать двухдневные размышления непрофессионала, т.к. на изучение своей предметной области пользователь потратил несколько лет своей жизни.
2. Сторонняя документация никак не может объяснить поведение, узкие моменты и идеологию вашей системы.

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

ЗЫ: К счастью, программные продукты бывают разные, не всегда это окошечко с кнопочками, картинками и табличками. У нас линейка технически сложных продуктов, для ограниченного круга кустомеров. В задачи наших техрайтеров не входит доскональное изучение всех технических тонкостей - это задача девелоперов.

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

Вы вот лучше раскажите какой у вас процесс тестирования документации.

Уже описывала. Высказываюсь по озвученным проблемам.
Кстати, Вы уже признались, что предложение о налаживании процессов Вам не по вкусу. Что Вы ожидаете от аудитории? :)

И, не могу не удержаться, док-райтеры - они не лишние. Очень даже не лишние. ...

Я это писала по отношению только к отдельному этапу, а не в принципе :)

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

Правда, но к сожалению не всегда угадывают, что именно писать.
Я бы одним из критериев взяла бы гугл: если на запрос есть куча ссылок, то можно и не особо разливаться мыслью по древу - программеры сами все найдут и прочтут во всех подробностях :)
Если брать API, то часто забывают описывать переменные связанные именно с простыми типами, типами а-ля Object или List. Например:
GetObjectWithType(string ObjType), где ObjType - тип объекта или его свойство.
Вроде и ежу понятно, но потом в коде приходится долго и упорно подбирать эту несчастную строку, перебирая малые и заглавные буквы и прочие фантазии.
Как-то так :)

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

Это не совсем нормальная ситуация, если все в порядке с процессами и т.п. Поясняю:
Спор по описанию фич самого продукта быть не может, т.к. фичи должны быть четко определены к этому моменту.
Все споры об общей идеологии продукта и фич среди команды должны быть разрешены ДО этапа составления документации - иначе не понятно что эта команда производит. Все улучшения и изменения, как правило, имеют свои планы реализации и т.п.
В спорах о стилистике и т.п. должен выигрывать ответственный за документацию, как более компетентный член команды. В спорах об идеологии продукта между техрайтером и девелопером/тестером должен выигрывать ответственный за идеологию продукта.
Можете привести свой пример спора. :)

- как тестируются случаи, когда продукт содержит одно и тоже руководство пользователя в разных ипостасях; у нас например обычное дело когда их три - PDF, HTML и online-help(неконтекстный) - зачитаться можно!
- как трэкаются и трэкаются ли изменения в продукте, сделаные в последнюю минуту.

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

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

В вашем примере я могу предположить:
- первый влез не в свое поле, раз не смог исправить.
- второй - молодец, т.к. следит именно за своими вещами, если он действительно внес нечто новое.
- техрайтер не знает кого слушать, т.к. ВСЕ ГЛАВНЫЕ ВО ВСЕМ. На самом деле техрайтер должен четко понимать от кого и какие содержательные комментарии он должен принимать: размышлизмы обычного девелопера о позиционировании продукта на рынке не нужно немедленно вносить в документацию, а надо передать на рассмотрение PR и т.п. ответственным членам команды... а еще лучше вобще не давать девелоперу этот кусок на рассмотрение, т.к. он все равно не сможет сказать ничего ценного - не та квалификация.
Вобщем, если каждый будет оценивать то, в чем он разбирается, то все в одном абзаце смогут увидеть свои коррективы.

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

Возникает вопрос, а какие же языки будут наиболее полезны тестировщику на практике? Вот список языков, которые мне встречались в вакансиях (сортирую по убыванию частоты упоминаний): С++, Java, C, C#, Perl, VBA, PHP, VB, JScript, VBScript, Python, Lua и др. Меня несколько удивило, что так часто встречался C++, а вот Python, наоборот, достаточно редко.

Учить надо те языки и технологии, которые используются в той области, в которой хотите работать. Глубокое знание web-технологий мало чем поможет в области системного программирования.
Так же я не рекомендую долго медитировать над практикой использования темплейтов в языке высоко уровня и т.п. вещи. А вот какие есть средства для работы с ресурсами, как можно доковыряться до элементов системы, какие есть библиотеки, архитектура и приемы программирования приложений (например, стандартные способы передачи параметров в web, или где могут храниться настройки), как передавать параметры между процессами и еще куча всего - это полезно...

Уважаемые знатоки, за какой язык вы бы посоветовали взяться? Знание какого из языков будет наиболее полезно на практике? Добавлю, что в текущей моей тестерской деятельности знание программирования не требуется, поэтому собираюсь учиться "на будущее".

Многие работодатели хотят, чтобы тестер имел какое-то представление о том языке, на котором ведется разработка + умел писать какие-то вспомогательные скрипты (средства автоматизации я оставляю за скобками). Мягко говоря, пофиг на чем (perl или python) написан вспомогательный скрипт из 50 строк, который лезет на сервер, читает что-то там в логе, создает и убивает процессы и т.п, если в обоих языках есть эти возможности... гораздо страшнее, если вобще нет представления, что такое в принципе возможно.
Для начала можно осваивать то, что больше всего требуется, потом смотреть на остальное.

1) В 99% случаев в моей практике данные языки и технологии редко применимы и без практики, тот же уровень программирования остается на уровне прочтения пары книжек. А попрошествии 6-12 месяцев стыдно писать в резюме, что есть знание данного языка(см. проблему 2)
2) Если же продолжать далее обучение в другой области, предыдущая забывается. На мой взгляд это очевидно, я же не программист и не программировал ежедневно на протяжении 10 лет. Исходя из требований работодателей(по части автоматизации по крайней мере) лучший тестировщик - бородатый программист, который решил сменить род деятельности под старость лет.
В итоге имеем 2 похожие, тесно связанные проблемы. Без практики не будит уровня и памяти. Уже слышал советы, вроде "Выдумай задачу сам" и т.д. Но имхо этот подход из разряда ананизма. В работе же применить очень проблематично.

Вы слишком сильно пытаетесь закопаться в программирование и выставляете слишком сильные требования.
Во-первых, тестовые системы в первую очередь должны быть простыми (что бы не пришлось потом тестировать тестирующую систему) и гибкими (это и переход на новые правила игры, и переиспользование частей для разных задач, и быстрое внесение изменений). Для этого нужно знать приемы и уметь их использовать, но лично мне никогда не приходилось сильно медитировать над этими вопросами.
Во-вторых, мы должны понимать как действуют те или иные алгоритмы, их слабые места, взаимодействие компонентов в ПО, протоколы и т.п. , чтобы понимать, как мы можем до них добраться, как с ними работать, и чтобы выбирать правильные тесты, которые тестируют код коллег, а не чужие библиотеки.
Но вот уделять много внимания особо хитрым способам реализации - это скорее лишнее. ИМХО, тестировщикам при обучении лучше копать в ширь. Покопать в глубь можно будет, когда с этим начнете плотно работать.
Прочитали, осознали сильные и слабые стороны, применили на простых примерах, подумали, где можно применить... пошли дальше.

По поводу памяти... Если с чем-то разобраться, то знания о том, что это есть, остаются надолго. Работа - это не учебное заведение... книгами и шпаргалками можно пользоваться в любое время.

А вот если юзер прочитает пару книг по тестированию сложно его будит отличить от профессионала.

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

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

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

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

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

У объекта Cell родительский обеъект - вся таблица (Table). Однако разработчики говорят? что они оперируют в некоторых случаях строками. ТестКомплит же не видит эти строки как отдельные объекты.
На счет VisibleOnScreen - это понятно, я нискалкой смотрю, а не только в Object Browser.

А у вас не может быть заморочек с событиями в коде приложения?
Например, есть обработчики для клика и на ячейку, и на всю таблицу (пример, может быть неудачный, но для иллюстрации пойдет). При запуске вручную могут отсылаться оба сообщения и оба события создают правильную реакцию, а ТС, например, отсылает сообщение только ячейке и вторая функция просто не отрабатывает...
Второй вариант: в каком-нибудь событии есть какое-нибудь условие, типа, если строка таблицы не выделена, то все обнуляем и ничего не делаем. При автоматическом запуске мы ее не выделили, приложение все честно обнулило.
Если разработчики иногда оперируют чем-то, что может не видеть тул, то можно подозревать любую пакость...
Посмотреть можно в дебаге, или вставить в код для всех событий и сомнительных мест простые меседжбоксы и потом сравнить результаты.

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

"Как получился этот баг" - ежели хочешь успешно пройти стажировку и расти дальше, то ищи сам. :)

URL=http://192.168.125.78:8090/MMS_Competition/loader.aspx?competitionID=1&page=0&showVotes=0&12226826158340-xml
URL=http://192.168.125.78:8090/MMS_Competition/loader.aspx?competitionID=1&page=1&vote_id=1107&showVotes=0&12226826208961-xml

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

Ежели весь скрипт голосует только за одну картинку (к сожалению LoadRunner не знакома, так что есть малая вероятность, что я не так поняла его скрипт), то менять надо вот эту переменную "vote_id=1107" во второй ссылке, приведенной выше.
Запишите еще один скрипт, который голосует за другую картинку и сравните разницу в этом месте и в остальных.

Если в ссылках, подобных этим:
URL=http://192.168.125.78:8090/MMS_Competition/Components/MMSthumb.aspx?id=1107&cID=1
URL=http://192.168.125.78:8090/MMS_Competition/Components/MMSthumb.aspx?id=1108&cID=1
выделенное жирным меняется, то спросите у программиста, по каким правилам.

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

Как воткнуть random подскажут другие, но все должно быть описано в help.

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

Да.