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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я отменил конференцию для своих сотрудников.

Зря. Это в вас эмоции говорят. Вы ожидали одно (уже на него настроились), а вам выдали другое. Внутренний конфликт, а подчиненные страдают.

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

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

Да, про школы верно замечено. Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: 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.

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

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

Коллеги!

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

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

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

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

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

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

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

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

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

Green, а что с переводом глоссария ISTQB получилось? Проект заглох или закончился?

PS
Прошу прощения, если просто пропустил какое-то знаковое мгновение.

Ни то и ни другое.
Временно заморожен.
Но разморозка зреет.

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

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

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

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

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

Коллеги!

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

Некоторое время назад, при проведении предпроектных работ с продуктом компании САП я познакомился с методологией ведения проектов, разработанной этой компанией. Называется она ASAP. В принципе, данная методика не сильно отличается от других проектных подходов. Но есть и специфика, связанная с подходами компании САП в автоматизации процессов компании.

Знаете ли вы другие методологии ведения интеграционных проектов?

Заранее благодарю.

У меня был случай. Пришлось тестировать 4-е активных (по ним велась разработка) проекта одновременно. Это был просто кошмар. После месяца такой работы я был выжат как лимон. При этом не было большой уверенности в качестве тестирования. Практически везде удавалось проводить только smoke tests.

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

Черт кроется в деталях.

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

А военный после двух лет службы это уже профессия?

В моем понимании "военный" - это когда работал офицером в армии, а не служил срочную службу.

Сейчас многие успевают сменить 3-4 профессии за свою жизнь.

Сейчас это когда? Сегодня, в этом году, за последние 10 лет, за последние 40 лет?
Многие это сколько? Есть хоть кто-то кто знает человека, который сначала был врачом, стал юристом, а потом инженером? Или смена профессии это с дворника на грузчика, с тестировщика на QA инженера?
Я бы даже переход программист -- тестировщик, не причеслял к смене профессии.

Сегодня - это сейчас, в этом году, в этом столетии.

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

Даже мои родители и те сменили: папа - четыре, мама - две профессии. И это не считая увлечения дачей.

Ряд занятий (не профессий) действительно мало изменились за последние сто лет. Как Муссорский или Чайковский сочиняли музыку, так ее сочиняют и сейчас (я имею ввиду, тем же местом). Но профессия композитора изменилась сильно. Мой родственник заканчивает консерваторию в Бельгии на факультете "дирижирование". Так от них требуют знаний того, что Чайковскому даже под кайфом присниться не могло.

Или взять бухгалтеров. Да, основные инструменты учета были придуманы еще в среднем веке. Однако, профессия состоит не только из знания основ. Существует целый набор окружения, который требуется для выполнения своих функций. Уверен, что бухгалтер даже 90-х годов не смог бы сейчас пойти работать без серьезной переподготовки.

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


С примером про Генри Полсона, это ты хорошо меня поймал на слове! Вот что значит, глазастая молодежь.


Действительно, правильнее было бы написать "в качестве иллюстрации".


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

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

В России из школ в ВУЗы поступает около 80% (а может и больше) — итого 7.5 миллионов студенов. Как они бедные без инфраструктуры учатся.

Сорри, пропустил фразу, что речь идет о выпускниках высших учебных заведений.

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

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

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

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

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

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

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

Коллеги!

В последнем номере РБК (11.2008) как раз появилась статья о проблемах образования в России. Ниже я перескажу основные пункты статьи для тех, у кого нет возможности прочитать саму статью.

1. В России практически отсутствует отсев "на входе" ВУЗов, так как практически все выпускники школ поступают в высшее учебное заведение. С одной стороны демографический провал 90-х, а с другой - почти полное бесконтрольное развитие коммерческих учебных заведений. Если сравнивать числа с Советским Союзом, то в те времена в ВУЗы поступало не более 20% выпускников.

По статистике зарубежных стран в той или иной мере после выпуска продолжают обучение:
- в Европе
-- с высшим образованием 47%
-- со средним - 14%
- в США
-- с высшим - 47%
-- со средним - 15%
- в Канаде
-- с высшим - 33%
-- со средним - 8%

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

2. Практикуемая модель обучения подразумевает, что специалист получает багаж знаний, которым он пользуется в течение всей своей трудовой жизни. Но ситуация изменилась. Сейчас многие успевают сменить 3-4 профессии за свою жизнь. Более того, за этот период ряд профессий может просто исчезнуть или трансформироваться до неузнаваемости.

В качестве примера приводится самая консервативная профессия - бухгалтер. "И в советские времена был бухгалтер, и в 90-е, и сейчас. Но это три совершенно разные профессии."

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

В качестве примера приводится Генри Полсон, Министр финансов США. Он специализировался на английской литературе в Дартмутском колледже, после чего работал в аппарате министра обороны и Белом доме, а так же руководил финансовой корпорацией Goldman Sachs.

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

***
Так что спасение утопающих - дело рук самих утопающих.

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

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

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

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

Вы очень хорошо все описали, но к сожалению это скорее ситуация "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, то это определенный сигнал для меня об профессиональной активности кандидата.



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

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

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

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

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

Сотрудник для удалённой работы на дому.doc

Лохотрон.
Не тратьте время.

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

Алексей,

культуры много не бывает!