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

Но пример есть.

Однако:
1) это долгий путь.
2) успешная трансформация зависит и от окружения. Старое окружение, как правило, очень консервативно, и у некоторых улучшение наступает только после смены круга общения.
3) нужен “проводник” на следующий уровень. Лучше, чтобы он был физически близко. Редко можно самостоятельно перескочить в другую колею.

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

Это очень сложно для любого homo sapiens, который уже психологически оформился, а ответственности все еще никогда не проявлял, и теперь тоскует по упущенным возможностям (ничего личного, я о себе говорю).

Если ее правильно взять, то автоматически запускается механизм “прикрытия лидера”, и карьера летит вверх.

“Прикрытие” – это моя, очень обсуждаемая, терминология. Термин появился после прочтения книги “Аквариум” @ Виктор Суворов.

Вот отдельно ГЛАВА VIII – http://zsite.narod.ru/read/suvorov/aqua_08.htm – там смотреть части 3 (кусочек про план) и 7 (весь пассаж про летчиков) – там немного текста.

Если интересно – весь текст книги – http://lib.ru/WSUWOROW/akwarium.txt

Про Покрышкина отдельно хорошо написано – http://rkka.kiev.ua/about_pokryshkin

Как взять на себя ответственность, и не надорваться: надо идти медленными шагами.

В одном из учений по практической психологии (в целом – крайне не рекомендую, но в частностях – весьма содержательно) есть про ответственность следующая картинка: треугольник с буквами З, К, О. Буквы обозначают “Знание”, “Контроль”, “Ответственность”.

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

Дык вот, на примерах.

Водить автомобиль – это ответственность.

Чтобы взять на себя ответственность за его вождение, нужно уметь контролировать автомобиль.

Чтобы уметь контролировать автомобиль, нужно знать, как именно он работает, и как им управлять.

Получается треугольник “ЗКО”.

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

Хочешь быть отцом? А сможешь контролировать все мелочи, которые сопутствуют появлению младенца в доме? Учился этому?

Хочешь играть на гитаре? А умеешь что-где-когда надо нажимать и звук извлекать? Учился этому?

Хочешь быть программистом? А сможешь с сайта нацбанка через RSS новости на наш сайт перепостить? Учился этому?

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

Но есть исключение.

Оно кроется в следующем: большинство людей после двух ответов “нет” (особенно на вопрос “А учился этому?”) принимают решение не морочиться, и переключаются на что-то попроще.

И только немногие после череды “Нет” еще способны спросить “А где этому научиться?”

Мало кто может сказать: “Да, не умею, не учился, но ептыть, я ХОЧУ стать программистом, который ездит на автомобиле с ребенком и гитарой, а кто мне помешает, того, сука, урою на хрен!”

То есть, кроме желания еще нужна спортивная агрессия и целеустремление

Если помните фильм про Эрин Брокович или “Дьявол носит Prada” – то самое в плане “становления работы”.

Типа “Хотите мне помешать? Попробуйте…”

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

Про примеры, наверное, скажу сам про себя.

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

Нашел себе проблему и сам нашел ее решение. Сам, в свободное время, дома, ночами, брал это стремное расширение “Selenium IDE”, и овладевал им Потом принес записанный скрипт на работу, и в нужное время его применил. Поля в форме заполнил, всего-лишь. Сэкономил две минуты, всего лишь.

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

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

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

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

Еще раз повторю:
1) продвижение в хирурги – это долгий путь. Требует умения самостоятельно контролировать ситуацию (а факапы случаются всегда и у всех).
2) успешная трансформация зависит и от окружения. Иногда работу НАДО менять. На предыдущую иногда можно возвращаться в новом качестве – примеры знаю.
3) нужен “проводник” на следующий уровень. Нужно чтобы кто-нибудь изредка говорил “Ты делаешь правильно”.

Где-то читал интервью одного тестировщика-автоматизатора из Гугла, где он рассказывал о том, чем обычно занимается (источник не помню). Он обычно переходит из проекта в проект, по неделям или месяцами. После себя оставляет какие-то скрипты, которые стабильно работают, и запускаются и без него.

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

В случае protocol level load/performance testing обе роли в подавляющем большинстве случаев выполняются одним человеком, и требования сдвинуты в сторону программиста.

В случае Web UI click-based automation (Selenium и подражатели) framework уже создана и подготовлена, а создание скриптов унифицировано и не требует кодирования, поэтому роль программиста (как бы) не нужна, но при этом тестер-автоматизатор полностью ответственен за automated test design, coverage, и maintenance созданных им скриптов.

> Большинству этого хватает, потому что доходы
> менеджера вполне могут быть
> сопоставимы с доходами программистов
> (хотя есть и менеджеры программистов…).

1. Management skills встречаются чаще и развиваются легче, чем IT skills. Отсюда, по закону спроса и предложения, и зарплаты.
Пример. Не так давно видел на Монстре (monster.ca) 3 вакансии в одной компании. QA Manager – 65K-70K. Automation Team Lead – 75K-80K. Sr. QA Analyst – 60K-65K. Вот так менеджер вполне может получать меньше своих подчиненных.
Пояснения. QA Manager – начотдела из 2-3 тимов (team) по 3-4 человека, обычно. Automation Team Lead – “первый среди равных”, как правило имеет некоторые руководящие права и обязанности внутри своей тим. Один из тим лидов как правило замещает менеджера во время отсутствия.

У программистов примерно также. Как бы странно не выглядело, менеджер программистов бывает не программист вообще.

> Является ли тестировщик-автоматизатор
> «ступенью» к программированию?
> Нет.
> Не является.
> Задачи, которые решает
> тестировщик-программист, не сопоставимы
> с задачами, которые решает обычный
> программист ни по сути своей, ни по
> внешним признакам.

2. По сути, надо различать automated testing и test automation. И это 2 разных роли – тестера и программиста.

Первое – это _тестирование_ с применением программных средств.
Automated testing зачастую считается только подготовкой тест данных для скриптов, запуск скриптов на выполнение и контроль результатов (“смотреть, чтобы все было “зеленое” (passed)”).
ДОЛЖНО включать в себя анализ результатов.
ДОЛЖНО включать в себя automated test design, процесс, близкий к exploratory testing. В это время так же находятся и репортятся дефекты, хотя целью и являлось создание “automated test flow”.

Второе (automation development) – это _создание_ (development!) программных средств тестирования.
Это, в первую очередь, создание (или адаптация существующей) framework – на этом этапе тестирование продукта не производится.
Во вторую очередь, создание скриптов, которые будут следовать designed test flow, на этом этапе программист-автоматизатор взаимодействует с продуктом, и с некоторой вероятностью может обнаружить новый дефект.
В третью очередь, поддержка (maintenance) существующих скриптов. Поскольку производится в случаях, когда что-то в скриптах не работает (так, как работало раньше), с некоторой вероятностью можно обнаружить, что на самом деле что-то в продукте не работает (или работает не так, как раньше).

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

Это как две реки с разными фарватерами. Обе требуют изучения.

У некоторых людей развиты оба эти типа мышления.

У большинства – нет, развиваться получается только в одном направлении.

Не соглашусь. Тестировщику легче переквалифицироваться в программера нежели человеку начинающему с нуля. … и следовательно чем круче тестировщик тем ему легче. ИМХО

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

1.

обезьянка – это обидно, если подходить к этому делу с неимоверной серьезностью

Надо различать подтрунивание и обзывание.

Вот если сказать “Тупая обезъяна” или “Орангутанг с клавиатурой” – будет обидный аналог “быдлокодера”.

Например, я могу обратиться к моему коллеге “Уважаемый багосоздатель”. Это обращение по работе, и сугубо предваряет обсуждение какого-то бага. При этом я неимоверно ценю и способности, и работу девелопера, и он это знает.

Вот если я буду так говорить каждый день, и даже вне рабочего контекста, например, встретив его в магазине – меня явно можно будет считать неадекватным представителем орангутангов с клавиатурой…

2.

Сертификация знаний, в моей системе ценностей, ничего существенного работнику не приносит.

Зарплату поднимает умение getting things done, а не удостоверение о знаниях.

Это очень неоднозначный вопрос, алгоритмизировать его вряд ли можно… Кому полезно сдать экзамен, а кому – уже нет.

3.

Всё зависит от того, как САМИ тестировщики к себе относятся, а не “компания”.

Посмотрите http://testitquickly.com/2009/01/23/стимулы-мануального-тестирования-в-google/ и послушайте оригинал того интервью (по линку).

Тестировщики в Google – такие же инженеры, как и девелоперы. Мануальщиков, по моей информации, там мало, большая часть гугловцев работает над автоматизацией тестирования, бо у них очень часто надо перепроверять очень большие объемы функционала. Разумнее в таких условиях использовать тестировщиков-инженеров (хирургов), нежели кликальщиков (медсестер).

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

Плюс, в Google есть неимоверная для СНГ корпоративная культура на рабочем месте. О ней надо отдельно рассказывать. Общее – только названия должностей. По сути же разница неимоверная.

ЗЫ Покажите, пожалуйста, зарплаты тестировщиков в компании Google – мне действительно интересно.