Да, я об этом не подумал.
Тогда твой вариант более справедливый.
Вносим этот пункт!

Ссылочку бы...

Да поможет тебе google...

"Провести верификацию тестового окружения на соответствие системным требованиям."

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

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

Да вот не всегда так получается. Зачастую функциональность превышает заказанную (но бывает и наоборот).
Но это в любом случае проблема не тестировщика. Так что я полностью согласен.

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

Да, задача не из легких. А будем обязанности делить? Или все-таки на грустном варианте тестера-универсала остановимся?

Господа, Вас право кто-то ввёл в заблуждение - у тестера может быть только один сорт - первый, он же и последний.
(да простит меня Булгаков  )

А при чем здесь Булкаков? Объясни неразумному. :unsure:

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

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

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

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

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

Так что для начала нужно определиться, какой все-таки тестер нужен, или возможен вариант "универсала"?.

P.s. Про студентов я наверное не понятно выразился, я имел ввиду, как определить, сможет ли человек найти студентов и работать с ними, а не как определить, сможет ли студент быть тестером (поэтому и написал, что немножко не в тему).

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

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

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

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

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

Положение о тестировании

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

II. Обязанности:

Каждый сотрудник компании «А» в процессе выполнения проекта и по его завершении обязан тщательно протестировать свой продукт в соответствии с требованиями тестирования, изложенными ниже.
Каждый сотрудник компании «A», получивший задание оттестировать какой-либо программный продукт также обязан тщательно протестировать этот продукт в соответствии с требованиями тестирования, изложенными ниже.

III. Порядок тестирования:

В процессе тестирования тестер обязан выполнить следующие действия:
1. Ознакомиться с техническим заданием на тестируемый проект;
2. Оттестировать программный продукт, для этого:
2.1. Составить список функциональных возможностей программы, список поддерживаемых форматов, список системных требований, предъявляемых к программе;
2.2. На основании списков пункта 2.1. составить список тестов, которые планируется провести с данным программным продуктом. Этот список должен быть составлен с учетом следующих требований:
а) должны быть проверены все функции программы и все возможные комбинации этих функций;
б) должна быть проверена работа со всеми заявленными форматами;
в) должна быть проверена реакция программного продукта на попытки некорректного использования:
- неприемлемый формат данных;
- использование неправильных комбинаций функций продукта; 
- работа в критических условиях, к примеру, при одновременной работе нескольких экземпляров программного продукта или при одновременном доступе к файлу (файлам), используемым программным продуктом какой-то другой программы, либо другим экземпляром этого же программного продукта
- другие возможные ситуации, критичные для данного программного продукта.
Составить план тестирования, в котором указывается последовательность всех тестов из составленного списка тестов. 
2.3. Провести тестирование программного продукта. Тестирование производится по составленному в пункте 2.2. плану тестирования. Тестирование должно быть произведено для всех системных требований, описанных в техническом задании (пункты тестирования, абсолютно не зависящие от системных требований можно выполнять только единожды). При тестировании необходимо составлять отчет, в котором должны быть описаны результаты каждого теста. К результатам тестов необходимо добавлять свою оценку по удобству использования программы, либо ее отдельных функций. Для каждого теста необходимо указать время начала и завершения теста и время, затраченное на тест.
2.4. Проверить наличие сопроводительной документации, выявить недостатки документации и несоответствия внутренним стандартам качества. К сопроводительной документации также относятся исходные коды программных продуктов, поэтому они также должны быть проверены на соответствие внутренним стандартам качества. Если в техническом задании указаны дополнительные требования к документации, необходимо проверить соответствие этим требованиям.


IV. Результаты тестирования:
По окончании тестирования тестер должен предоставить письменный отчет руководителю проектов. Этот отчет должен содержать следующие сведения:
1.	Список оттестированных функций и возможностей;
2.	Список проведенных тестов;
3.	Результаты каждого теста, включая длительность теста;
4.	Резюме по удобству использования данного программного продукта, возможно с пожеланиями по улучшению этого продукта;
5.	Резюме по сопроводительной документации.

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

У нас набор программистов проходит с тремя! тестовыми заданиями, продолжительность до 1,5 месяцев бывает.
И мы об этом сразу говорим. У нас достаточно узкая специализация, практически никто раньше с этим не сталкивался и тестовые задачи позволяют оценить, насколько быстро человек осваивает новые инструменты/технологии.

Тестеров мы специально не нанимали, но я бы предложил такое тестовое задание, для оценки способностей человека:
"Составить положение о тестирование программных продуктов"
То есть алгоритм тестирования в виде скажем должностной инструкции (нужно делать то-то и так-то). Получается что человек сам опишет видение своей работы. Множество вопросов сразу отпадет.

P.s. Вопрос к Case: может открыть тему, целью которой будет выработка "Положения о тестировании" для небольших компаний? Чтобы руководители компаний / руководители отделов тестирования / тестеры / программисты, без чтения кучи статей и инструкций, смогли представить и другим объяснить, что и как нужно делать. Для начала могу выложить то, что имеется у нас. Если предложение принимается, скажи в каком разделе лучше создать тему, или сам создай.

Не смог найти, как это сделать.
Подскажите.