Сергей, Юлиана, я работаю в аутсорсинговой компании, и я не разделяю вашу точку зрения :)

Да, про школы верно замечено. Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: http://www.questioni...of-testing.html

Кстати, эпиграфом к этой заметке служат вот такие слова Майерса, которого вы пытались привлечь как адвоката своей стороны:

"... one usually encounters a definition such as, 'Testing is the process of confirming that a program is correct. It is the demonstration that errors are not present.' The main trouble with this definition is that it is totally wrong; in fact, it almost defines the antonym of testing."

- Glenford Myers,
Software Reliability: Principles & Practices, 1976

Леша,
есть такой старый анекдот.

Принимают двоечника в комсомол и проверяют, как подготовился. Спрашивают:
- Знаешь, кто такой Ленин?
- Кто такой Хрущев?
- Кто такой Брежнев?
А двоечник абсолютно ничего не знает. Мычал он что-то, мычал, а потом спрашивает в ответ:
- А вы знаете Петьку хромого, Ваську косого и Фильку с пятой?
- Нет? Ну, так и нечего меня своими авторитетами пугать!

Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: http://www.questioni...of-testing.html

Первично то, что у нас есть задача и ее реализация. Нам нужно сравнить то что получилось с тем, что должно было получиться. Другими словами, сложить 2+2 и получить 4. Если мы складываем 2+2 и получаем 5, то это ошибка. В случае программы - дефект. Цель тестировщика - сравнить левую и правую части уравнения и сделать вывод о наличии или отсутствии ошибки. Если этот процесс не является поиском дефектов, то что это?

Теперь представим, что есть нечто сложнее, чем 2+2=4. Допустим по требованиям/спеке дано f(x)=y. По результатам эксперимента получается, что f(x)=2y. Где ошибка?
Если механически сравнить левую и правую сторону, то ошибка всегда получается в программе. А может ошибка в спецификации и правильно f(x)=2y, что и подтвержденено результатами эксперимента. Надо чуть чуть думать, просто сравнить не получается.
...

Вначале 2 LeshaL,
а кто сказал, что часть уравнения, с которой нужно сравнивать, - это программа?
А думать нужно всегда, даже когда просто гвоздь в стену заколачиваешь.


Теперь для двух Алексеев и всех остальных,
давайте рассмотрим типовое поведение тестировщика.

1. Тестировщик получает на тестирование некую программу (модель реализации) с задачей ее проверить (собственно, это типовая функция свойственная данной роли в проекте).

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

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


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

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

Правильно! Сто раз правильно!

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

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

Нам нужно сравнить то что получилось с тем, что должно было получиться.

Уточняющий вопрос: зачем нам это нужно?

Нам нужно поставить заказчику продукт, который он заказал. Если мы сделали не то, что он заказал, то это ошибка. Ее нужно найти и исправить для того, чтобы... СМ предложение 1.

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

Коллеги!
Вы что, сговорились? Все задают мне наводящие и уточняющие вопросы. А сообщить что-нибудь по существу можете?

Сорри за оффтоп. Но не могу пройти мимо.

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

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

В идеале: бизнес-модель=функциональная модель=модель реализации=бизнес-модель

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

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

Качество работы тестировщика напрямую зависит от двух навыков:
1. Навык формирования тестовой модели
2. Навык работы с моделью реализации

1. Навык формирования тестовой модели

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

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

2. Навык работы с моделью реализации

Необходимо знать, что тестировщик сможет самостоятельно выполнить работу по тестированию от начала и до конца. Если у вас в процесс тестирования входит настройка тестовой среды, а так же установка и настройка тестового приложения в него, то тестировщик должен УЖЕ это уметь. Знать основы операционной системы, основы настройки среды, основы управления базами данных. Если его работа этого не требует, то эту часть можно опустить.

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

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

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

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

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

Мне кажется, в форуме есть как минимум два оппонента для которых существует только два мнения - свое и неправильное:)

Yuliana,
я Вас разочарую.
Это свойственно всему человечеству.

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

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

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

Леша,
а кто сказал, что тестировщик - это не аналитик?

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

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

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

Кстати, а как на счет личных качеств?:)

Хотел про них написать. Но потом стало лень. Итак много книжек про это написано.

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

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

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

После моего поста они будут знать, что им следует отвечать на собеседовании.

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

Вот это в мемориз. Есть комсомольцы, которые в статью оформят?

Дык, у меня это в тренингах от лекции к лекции проходит пунктирной ниткой.

Коллеги!
Не сочтите за труд, растолкуйте убогому.

Если нахождение дефектов не является целью работы тестировщика, то какова его цель?
(Если это оффтоп, то согласен на другую ветку.)

Коллеги!

То что вы говорите - все правильно. Только это частности.

Что проверять первое, что второе? Вначале писать тест кейсы или потом? Нужен статус проекта или не нужен? Должен тестировщик думать или механически тыкать пальцами в экран и использовать язык глухих?

Все это вторично!

Первично то, что у нас есть задача и ее реализация. Нам нужно сравнить то что получилось с тем, что должно было получиться. Другими словами, сложить 2+2 и получить 4. Если мы складываем 2+2 и получаем 5, то это ошибка. В случае программы - дефект. Цель тестировщика - сравнить левую и правую части уравнения и сделать вывод о наличии или отсутствии ошибки. Если этот процесс не является поиском дефектов, то что это?

Алексей,

отлично написано, а главное, "в точку".

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


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

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

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

Что-то все затормозилось.... давайте реанимировать активности...

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

Но выплата высокой зарплаты не является мотиватором в долгосрочной перспективе.

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

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

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

Я бы определил следующие мотивирующие факторы, помимо денег:

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

2. Сложность (комплексность, новизна) и, как следствие, интересность задач. Без предыдущего пункта это, как правило, является демотивирующим фактором.

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

4. Перспективы роста по служебной лестнице. Как ни крути, а более громкое название позиции всегда являлось очень сильным стимулом. Я как-то читал про результаты опроса менеджеров в США. Более половины опрошенных отметило, что они предпочли бы более "громкую" должность против повышения зарплаты. Социальный статус человека в обществе никто не отменял и более высокое положение на работе подразумевает более высокий статус в обществе.

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

Получить три месячных оклада...

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

Так что...
Гудбай Америка, о-о-о

Коллеги!

Несколько примитивный подход. Что значит - а давайте забацаем!? Это как-то смахивает на пионерский энтузиазм типа, а давайте бабушку переведем через дорогу? А потом оказывается, что это не наша старуха!

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

Вот вам первый вопрос.
Кто будет платить за сертификцию?
Тестировщики? Компании?

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

И третий.
Чем эта сертификация отличается от существующих и чем она лучше высшего образования?

Коллеги!

Престиж - субстанция нематериальная. Ее зарплатой не измерить. Землекоп на кладбище, например, профессия не престижная. Но попробуйте туда устроиться без серьезной протекции! И кризис им, кстати, не страшен.


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

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

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

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

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

Александр Смирнов рассказывал (весна-осень 2008), как он нанимал тестировщиков в Бегун. Не хотят говорит идти. Приходится объяснять. Будешь следить за качеством кода, проводить кодеревью, покрывать код тестами. Когда до людей доходило, что им предлагают очень ответственную и сложную работу - отношение менялось. Ну и зарплату они предлагали $4000. Обычному тестировщику. Не ведущему. Обычному.

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

Почитал я эту ветку... и даже написать нечего. Уже все написано выше. Значит, буду критиковать.


Во-первых, Haul, видно, что знаний и опыта у вас в этой области нет. Зачем брались за эту работу? Но это вопрос риторический.

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

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

Кто виноват?
Виноваты конечно Вы. Если бы у Вас было больше опыта или был больший выбор, то Вы бы не оказались в этой ситуации.

Что делать?
1. Снять с себя миссию спасителя.
2. Четко ограничить рамки своей компетенции. Начать с точки приема программы в тестирование и закончить точкой выдачи результатов тестирования. Все что внутри - Ваше, что снаружи - на кого бог пошлет.
3. Определить, какой именно результат должна выдать группа тестирования по итогам тестирования (что будет написано в отчете).
4. Определить, что потребовать от разработчиков до начала тестирования программы (какую информацию они должны представить, в каком виде и что сделать), а так же чем грозит продукту не выполнение каждого из требований.
5. Определить, что должно быть сделано остальными по результатам тестирования и как это проверить/подтвердить.
6. "Выбить" из начальства санкции за не выполнение требований приемки/передачи продукта в тестирование.
7. Определить, что именно, в каком порядке и каким образом будет тестироваться (и в таком порядке результаты отмечать в отчете о тестировании).

Для начала этого хватит.

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

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

Возникли вопросы, тем кто знает на них ответы.
1) В Учебном центре Люксофта в конце курсов есть экзамен/зачет?
2) Дают ли там в конце обучения сертификат?

Все игнорируют вопрос. :( мне уже даже стало интересно...
Кто-нить вообще учился в этом учебном центре? Или его только рекламируют?

Я учился.
Но это другая история. В то время сертификатов не выдавали, экзаменов не проводили.

Самый лучший способ все узнать - позвонить в центр и спросить.

На мой взгляд, в обсуждении все поставлено "с ног на голову".
...

Вы очень хорошо все описали, но к сожалению это скорее ситуация "to be", а не "as is". Т.е. оно так и должно быть как вы описали, но в реальности это совершенно не так.
И не только у нас, например Бах в своем блоге пишет, что и у них не так все хорошо http://www.satisfice...og/archives/130 .

Я написал о механизме, о том как это работает.

Что касается Баха, так это история о конкретно взятой компании с ее конкретной сертификацией. Еще один пример перегибов на местах.

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

Все имеет экономическое обоснование.

Когда компания принимает на работу специалиста, то его производительность первое время минимальна. Для того, что бы он вышел на "рабочий " уровень нужно время и ряд условий. Нужно что бы новичок:
1. познакомился с командой и окружением;
2. познакомился с компанией и правилами трудового распорядка;
3. изучил правила проектной работы, процессы, принятые в компании;
4. изучил правила работы, процессы, шаблоны, применяемые в конкретном проекте (отделе и т.п.);
5. "устаканился" или установил личностные взаимоотношения с окружающими, другими словами, вписался в коллектив.

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

Если, к примеру, в вашем проекте работа строится по RUP (XP, SCRUM и т.п.), то специалист, получивший хотя бы и теоритические знания о данной методологии (не говоря уже о практическом опыте), значительно быстрее выйдет на 100% кпд. Следовательно, кривая его эффективности будет круче той, если вы возьмете на работу хорошего специалиста, но не имеющего хотя бы базиса в нужной области. Второй специалист обойдется компании дороже, чем первый.

Я гораздо менее революционер, ...

Алексей,

все таки любишь ты провоцировать народ!


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

Хорошо это или плохо?
Это хорошо! А что в этом может быть плохого?

Полезно это или нет?
Конечно же полезно! В любом случае специалист расширил свой кругозор, поделился опытом и что-то приобрел взамен.

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

Если ценность дипломов о высшем образовании девальвировалась за последние годы, то среднее образование и курсы повышения квалификации для ИТ специалистов так и не приобрели ее.

Кстати, показательная история произошла с сертификатами Майкрософт. Вначале, когда система сертификации только открылась в России, никто не знал, как правильно сдавать экзамены. Подготовка к ним, по тем временам, стоила бешенных денег и доходила до 3.000 долларов за один курс (это при том, что зарплата была от 50 до 200 долларов). Отправить специалиста на курсы могла позволить себе только очень богатая компания и обладатель сертификата ценился на вес золота, так как для получения льгот и статусов от Майкрософт нужно было обязательно иметь определенное количество сертифицированных специалистов.

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

Что получилось в результате?
Ценность сертификатов Майкрософт упала стремительно. За несколько лет их получили все, кто этого хотел. В результате были такие, кто сдавал полный набор экзаменов по всем специальностям.

Через некоторое время в Майкрософт опомнились и повысили сложность экзаменов. Но престижность их сертификатам уже не вернулась.

Чтобы сертификат начал работать необходимо, что бы работодатель знал и верил в то, что обладатель этой бумажки РЕАЛЬНО обладает ценными практическими навыками. Для этого нужно чтобы учебное заведение, проводившее обучение, преподавало реальный курс и давала актуальные знания и практические навыки. Это задача обычного бизнеса. Говоря обычного, я имею ввиду, что деятельность должна вестись по законам бизнеса - пропаганда, реклама и маркетинг являются двигателями торговли. Кто сможет убедить работодателей в высоком уровне преподавания определенных дисциплин, те сертификаты будут ценится и за их обладателями будут охотиться работодатели.


Но!
При всем выше сказанном, никто не отменяет ценность и правильность самообразования. Это всего лишь разные механизмы одного процесса. Если кандидат не знает ресурсы it4business и software-testing, то это определенный сигнал для меня об профессиональной активности кандидата.



И еще пару слов для руководителей курсов и тренинг центров...

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

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

Приведу простой пример. Допустим, вы решили получить образование в области рекламы. И вот вам попалось объявление о том, что открыт набор в Школу рекламы. Это вам что-то говорит? Нет. Пойдете вы туда? Навряд ли.

Но если добавить, что руководителем школы является Юрий Грымов (Чужие) и попасть туда так же сложно, как полететь в космос, а успешно выпуститься еще труднее? Бьюсь об заклад, в мечтах вы уже видете, какой эффект на работодателя произведет ваш диплом об окончании этой студии.

Black box software testing: A course by Cem Kaner & James Bach

Domain Testing

http://www.testinged...BST/Domain.html

Тестирование - это специфичная деятельность. Она может поглотить любой объем выделенного времени и его окажется недостаточным.

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

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

Некоторые методики включают в себя общий коэффициент затраты на тестирование, некоторые - нет. Введите свой коэффициент и вычисляйте затраты на тестирование.

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