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

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

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

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

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

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

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

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

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

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

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

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

Вобщем-то оба высказывания верны, просто применимы к разным случаям жизни.

Dmitry_NJ, спасибо за ответ. Было очень познавательно. :)

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

Ну сайтец слабают. Считаете, что на этом задачи для программистов закончились?

И вообще они клинические идиоты - знают про бинарные деревья, но как только n>2, то они впадают в ступор, потому что могут только повторять прочитанное в книжке и самостоятельно мыслить не могут. Очень реалистично.

Это реальный случай, а не анекдот. Знакомый собеседовал и рассказывал... Там еще много подобного было.

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

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

Странно, вы не пробовали переубедить - вы критиковали статью :) Я вполне готов переудебится - только в чём? Что система ВО есть какая-то неземная сущность, которая не подчиняется законам физики этого мира? :)

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

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

Фуф! Высказалась

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

Я лично не понимаю, чем помогут дополнительные лекции человеку, который УЖЕ ПОСЧИТАЛ, что он может прожить на 100 каких-нибудь тугриков, ЗАБЫВ про то, что завтра ему нужно купить новые кроссовки, из-за чего он не уложился в бюджет. Это в лучшем случае, т.е. если он вобще задумался "как жить", а не понесся сломя голову и распихивая локтями остальных, потому как "у друга уже есть!" (при этом большие глаза).
Что ему вобще можно сказать на лекции по этому поводу?

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

А можете привести конкретный пример? :)

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

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



К сожалению долго искать пост от Case, в котором он возмущается(?) 8 часами ОПП, чтобы аккуратно его тут воспроизвести.
Но есть вопрос: а что там вобще АЖ целых 8 часов можно рассказывать? Чего потом не хватало? И лекции читали в последний семестр обучения?

Утрируете. Предположим вы берёте в кредит автомобиль. Вы отличаете "стоимость владения" от "суммы выплаты по кредиту"?

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

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

Так это проблема в диком рынке аренды. И никакое образование тут не поможет: либо повезло встретиться с нормальным арендодателем, либо нет.

Читали на 4-ом курсе. Первый семестр. Я, наверное, тупой,но в меня теория не влезла. Читал потом сам - наверное оттого и хромаю на эту ногу.

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

вставлю свое имхо: никогда не понимала ВУЗы.

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

Для того, чтобы въехать в программирование, не обязательно заниматься чистой математикой. А мозг можно тренировать и играя в карты, например.

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

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

Я не думаю, я знаю, что так не везде и не всюду.
Поэтому правильнее написать "в МОЕМ вузе преподавали только теоретики, поэтому я считаю, что в ДАННЫЙ вуз на лекции ходить не надо".
А обобщать на примере одного вуза - слишком громкое заявление. У нас и java читали работники Sun. И теорию компиляторов те люди, который делали эти компиляторы. И визуальное моделирование тоже читал тот, кто в тот момент двигал это направление.

PS: Кстати, а у книги Вы как спрашиваете?

1. в моей жизни было 2 вуза. Один из них очень известный и престижный в нашем крае. Так же у меня хватает друзей и знакомых, которые учатся (учились) в разных ВУЗах нашей страны. Практикующих преподавателей мало!
2. Из 1 => Не во всех вузах преподают "работники Sun". Мне почему-то кажется, что таких заведений немного

Ну вот видите, Ваш начальный топик уже можно исправить на "не стоит идти в ВУЗы с плохими предподавателями". Звучать будет совсем иначе.

3. Книга лишь источник теории. спрашиваю я у коллег, у знакомых, которые на интересующем меня вопросе "собаку съели". прежде всего я сталкиваюсь с реальными проблемами на работе, которые вызывают кучу вопросов. и ответы на эти вопросы будут мне полезны. и эти ответы я запомню надолго, потому все они связаны с моей работой, я знаю, что они РЕАЛЬНО мне пригодятся. (интересно какой вуз тестировщиков (специалистов по тестированию\качеству) готовит-то?)

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

насчет компиляторов интересно. и кто ж это за люди, которые "делали компиляторы" и преподавали этот предмет в вузе?

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

а что понимается под "в тот момент двигал это направление" (визуальное моделирование)?

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

а, кстати, где у меня обощение идет? я написала "в основном"

Вы еще в своем первом посте обобщили.
Сами написали: "не понима... была... не понравилось".

1. а как вы узнаете плохие там преподаватели или нет? не забывайте Вам 15-16 лет, вы сейчас уже решаете куда пойдете после школы, вы думаете над специальностью, сомневаетесь... Как вы проверите ВУЗ на проф. пригодность за все 5 лет? вы попросите полный план учебных занятий? и список всех преподавателей, которые будут преподавать все ваши 5 лет? или вы опросите всех выпускников? Я повторяю: люди очень разные. я отвечаю в данном форуме лишь за себя. это мое мнение. кому-то за 5 лет ничего вообще не "вбили" в голову в том вузе, а кто-то и без него справляется (примеров мне хватает), изучает сам, стремится, и не считает, что он что-то в жизни упустил (в нашем случае вуз).

Можно прямо в приемной комиссии спросить... Так же на сайтах самих ВУЗов. Они пишут ежели им есть, чем похвастаться.

а сколько часов у вас было того java? вы сейчас его используете?

Да. Использовала в двух проектах... Если C# тоже учитываем, то в 5. А есть еще вакансии в фирме Sun по всему миру.

а моделирование вам пригодилось?

Да. Два проекта. В том числе текущий.

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

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

2. "Я слышала" - это не значит, что так оно и есть.

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

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

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

3. Фамилий мы , конечно, не прочитаем.. Но поверим, что это были великие люди

Ну, например, Терехов. И что это Вам дало? :)

4." МНЕ не понравилось. Я не понимаю. Я была. " - Везде есть местоимение. Не забывайте. Так где обобщение?

Я про ВУЗы.

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

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

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

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

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

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

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

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

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

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

Коллеги, возник вопрос из этой же серии. Видео записано, теперь стоит задача его воспроизвести. При этом необходимо видеть хронометраж в миллисекундах. Это нужно для измерения длительности процессов. Что можете порекоомендовать?

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

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

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

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

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

Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?

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

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

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

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

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

Привет всем
Интересует вот какой вопрос:
Использует ли кто-то для анализа, а может и для каких других полезных нужд, некие модели систем, например структурированные деревья объектов со свойствами и связями. А может модель в виде диаграмм с теми же свойствами и связями объектов.
Вобщем интересует все по этому поводу: используемое ПО, методы, насколько полезно и удобно.
Заранее спасибо :)

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

Все зависит от того, как используется у вас UML. Некоторые команды вобще все хранят в UML.

Если ближе к тестированию, то можно проводить тестирование на уровне модели некоторых фич системы, которые не зависят от кода. Например, мы разрабатывали решение: по MSC диаграммам + еще кое-что, генерились тесты для "прозвона" всех абонентов для UML модели АТС, проверяя что все соединяются друг с другом правильно. Решение получилось более удобным, чем тестирование через готовый код.
Самим фактом наличия каких-то элементов и атрибутов можно проверять, что разработчики ничего не забыли, что объекты побывали в нужных состояниях и т.п. - может оказаться проще, чем проверять это через запуск системы.
И т.д. и т.п.

Что касается тулов, использующих визуальное моделирование: их много, и они могут различаться по идеологии и с вариантами на тему использования UML. ИМХО, тут так же как и с тулами для тестирования.

Поэтому сразу вопрос - что в первую очередь хочет услышать работодатель от кандидата-тестировщика на собеседовании?

Помимо адекватности в размере зарплаты, работодатель смотрит на знания и уровень, требуемые от кандидата. Как правило, все это указано в описании вакансии + из описания того, чем занимается фирма. Если Вы хоть как-то представляете, чем занимается контора и с чем предстоит столкнуться, то велик шанс, что все будет хорошо. :)

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

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

А на чем написано клиент-серверное приложение? :)

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

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

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