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

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

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

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

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

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

2) И еще: как видят свое будущее специалисты пишущие на Visual Basic? Встроенный лотусовый язык похож на него.

Тогда уже скорее не Visual Basic, а .Net . Лично у меня, после изучения общей идеологии не возникло сложностей с использованием других возможных языков в Visual Studio. На рынке вроде как востребовано. Но на мой субъективный взгляд проекты с .Net и с java совсем не похожи друг на друга в массе... вобщем, тут стоит задуматься над тем, к каким проектам тяготеет душа и от этого уже плясать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И где Вы такое находите?

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

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

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

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

Type Element    a1 as string    a2 as string    a3 as string    a4 as string    a5 as string    a6 as string    a7 as stringEnd Type

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

В SQABasic, судя по документации, есть ReDim, позволяющий изменить длину массива.

И еще хочу затронуть некоторые моменты в Вашем ответе - может и получу в итоге познавательную для себя дискуссию, т.к. тема универсальности весьма интересна :)
Для тестирования GUI используется не так уж много наборов данных, и акцент идет на разную длину строк, на данные, которые открывают какие-то новые формы, и делается все для одного пользователя. Запуск на виртуальных машинах похож на нагрузочное тестирование, но честно говоря, никогда не получалось получить серьезную нагрузку, используя тесты для GUI.
При нагрузочном тестировании на практике у меня все сводилось к вычислениям: в памяти болтаются массивы с "индексами" важных объектов, позволяющие их однозначно определить, а все свойства/связи зависят от порядкового номера/счетчика/условий/"и т.п.". Из преимуществ могу обозначить, что не надо лепить километры данных при увеличении числа пользователей или объектов, можно исследовать различные ситуации, просто поменяв некоторые константы (больше одного, меньше другого).
Как-то так, если кратенько.
Честно говоря, с универсальностью особо и не сталкивалась, но интересно.

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

Если хотите могу продолжить список интерпертируемыми языками Python, Ruby, Perl, Lua.

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

По сравнению с нормальными языками программирования (C/C++, Java, C#, etc). Вообщем понятно, не более убог чем остальные уродцы :).

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

Вот хочу научиться как создавать dll в C++

http://ru.wikipedia.....BE.D1.82.D1.8B

можно еще погуглить и найти как создавать в VisualStudio

Всем доброго времени суток,

Нужен автотул, который имеет возможность приконектиться к Java API вызвать нужные функции, передать туда параметры, получить результат. также должна быть возможность коннекта к БД.
Что можете посоветовать, вроде и не большие требования но я пока только поотбрасывал разные тулы, уже думаем о том что бы самим написать такюю штучку.

Быстрее самому написать... Задачка простая :)

Кстати, а на этом сайте вроде как был где-то склад всяких мелких полезных программок для ленивых... Или я что-то путаю?

Какие есть средства попроще, чтобы ловить некритичные ошибки javascript на страницах? Selenium IDE их что-то игнорирует.

1. Настроить браузер, чтобы при ошибке выдавалось сообщение, тогда при прогоне тестов будут вылетать unexpected window.
2. В некоторых браузерах (например, firefox) есть консоль ошибок
Что-то в этом духе...

нашел нужный Task, в нем нужный connection и нужный запрос. (это из сгенеренных Recorder`oм)

а вот как поместить в этот запрос переменную?
или я не в том направлении рою?

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

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

также интересно было бы смоделировать попытки одновременного сохранения..

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

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

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

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

Некоторые термины знать безусловно полезно... Но это полезное запросто утонуть в море слишком специфичного...
Короче, лучшее - враг хорошего...

Лично мне попадалось "модульное построение" = программа состоит из модулей, т.е. частей с определенной замкнутой функциональностью (ядро там иметь не обязательно, но оно чаще встречается).
По поводу подтягивания "модульного построения" к "ООП"... ИМХО, это разные уровни.

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

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

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

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

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

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

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

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

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

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

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

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

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

Неужели никто не может мне помочь? Должны же быть стандарты по работе с эл. версиями проектной документацией и внутренней документацией с использованием VSS. Где искать??? Где порыться можно????

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

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.