Осень.

Я, безработный, «словно птица на сносях», иду собеседоваться в большую компанию.

А там на входе две анкеты «на адекватность».

Дадада, давайт сюдайт, адекватность — это же моё второе имя!

Первая анкета скучна, как радио «Шансон» в киевском варианте. Сто насущнейших вопросов из области программирования.

Что такое ООП, а вот предположим, что мы намазываем на бутерброд наследуемый полиморфизм, а в чем же насущная суть абстрактной сущности, а вот найди неправильный тэг в предлагаемом html-коде, а что б ты сделал, если б ты увидел молдавских коммунистов в церкви (ничего, это же неправильные коммунисты, они делают неправильный мёд), а кто такой тов. Стучка (один из организаторов коммунистической партии в Латвии с 1919 г.), а где теперь живет Карл Маркс (в сердцах пролетариата), и прочее…

Я отвечал этой занудной анкете честно, обстоятельно и неторопливо, мол, не брал я на душу покойников, и не испытывал судьбу, и не знаю я никаких ваших ООП, а вот этот тэг на html надо безусловно закрывать вот здесь, а тут тоже не знаю, и это пропущу, и тут я хз, а тут я вообще хз, и я начальник, спал спокойненько, и весь ваш МУР видал в гробу…

Вторая анкета поживее — сто вопросов про тестирование ПО. Там я тоже отвечал честно, обстоятельно и неторопливо, но тут уже, в отличе от первой, незаполненным не оставил ни одно поле.

Итого странная ситуация: коньдидатЪ продемонстрировал исчезающе мало знаний в программировании, но ВНЕЗАПНО оказался невероятно хорош в тестировании, набрал ~90% правильных ответов, каг же таг?

Разбираться со феноменом явилось двое тест-манагеров. Мое сопротивление было смелым, как атака кавалерии Келлермана под Ватерлоо, но таким же ненужным. Не суть, конечно, дело прошлое, но по итогу беседы мне был нанесён самый мощный coup de grâce в моей тестировщицкой жизни, о котором не забывается. Речь пошла про тестирование проекта, который вот-вот надо сдавать.

А именно: «А вот у вас проект, который вот-вот надо сдавать. Что вы предложите делать тестировщикам: проверять по тест-кейсам, или в свободном режиме потыкать проект, может и найдутся какие-нибудь баги?«

Я крепко подумал.

И ты подумай.

Саспенс же, ёпта.

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

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

Да, и непонятно, что в данном случае означает «выход на продакшн», бо я ж ни здоб ни здуб о том, какого рода проект происходит — он на сервере появится, или будет передан в разные офисы и установлен на разном оборудовании, а я ж хз, тестировались ли варианты «разного оборудования», и…

Ок, считаем, что другого шанса «сдать адекватный проект» не будет.

Можно заняться аналитикой: ещё раз пройтись по проекту и выяснить, все ли возможные сценарии работы приложения были продуманы и протестированы? Наверняка же не все… Но заниматься аналитикой перед финалом работы по проекту вобще?…

А если проект уже «надо сдавать» — это означает, что времени на багфиксы не будет?! Если в свободном поиске тестировщик найдёт что-то СТРАШНОЕ, то его свои же манагеры закопают у озера на Скулянке, лишь бы не сообщать в последний момент о том, что выходить в прод опасно…

Что-то хорошее в этой ситуации тоже нашлось — если проект «уже надо сдавать», это значит, что до сих пор тестировщики что-то в этом проекте ковыряли, и вероятно, уже не первый день, и вероятно, уже знают его очень хорошо. Знают сильные места, знают слабые места, знают то, о чем никому не надо говорить, знают то, что хочется развидеть, но без армии психоаналитиков мистер Крюгер все равно будет каждую ночь посещать и несчастного тестировщика, и несчастного девелопера, который всё это надевелоперил…

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

Подскажу бесплатно: или найдутся какие-то безумно идиотские экзотические сценарии перехода с одного экрана на другой, или какие-то безумно идиотские экзотические сценарии выполнения каких-то расчетов, которые закрэшат софтину, и тогда манагеры поедут на Скулянку выкапывать из благословенного молдавского чернозема тестировщика, который хотя бы что-то да знает о том, где у этой софтины слабое место, в которое НЕ НАДО тыкать…

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

Некстати подумалось, что если рискнуть, то можно дальше не читать, просто знайте, что убийца — не садовник…

Поэтому вариант «А давайте в режиме свободного падения покопаемся в программе, может быть, и найдём что-то…» мне не нравится КОТЭГОРИЧЕСКИ. Многовато экзотики. Потенциально можно доказать, что программа обладает страшными недостатками, но можно ли доказать, что она делает то, что…

А, кстати, программа уже делает то, что должна делать, без ошибок? Нет информации. Предположим, что я заказчик, который не врубается в градации экзотичности багов, и хочет, соппсно, получить софт, который будет делать то, что ему нужно… И как водится, предположим, что тестировщиков в проект пригласили просто потому, что кто-то убедил заказчика в том, что тестировщики — прекрасные эмуляторы «конечного пользователя». Следовательно, самая важная информация, которая должна приходить от тестировщиков — будет ли удовлетворён конечный пользователь, а он будет удовлетворён в принципе потому, что программа будет делать то, что она должна делать…

Вернёмся к исходникам:

1. проект «вот-вот» надо сдавать,
2. дальнейшая работа над проектом не объявлена,
3. у тестировщиков есть ТОЛЬКО две возможности:
   1. или проверять проект по тест-кейсам,
   2. или «тыкать проект» в поисках ранее пропущенных багов.

Ваше решение, фельдмаршал?

Решение такое: проверять проект по тест-кейсам.

Если есть время, то следует методично и последовательно убедиться ЕЩЁ раз в том, что программа делает то, что она ДОЛЖНА делать.

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

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

Я отказался.

Мне отказали.

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

Просто сегодня я хочу, чтобы все IT-рекрутеры стали браузерами.

У меня с рекрутерами отличные отношения. Я к ним уже привык.

Привык моментально отвечать на обращения стандартной отпиской «Спасибо, но не в этом году«.

Привык отвечать на звонки: «Слушайте, позвоните мне в 23.00, сейчас я не могу говорить«.

Кто-то реально начинает звонить в 23.00 🙂 Ну, это нормально.

Акулам всегда нужны лоцманы. Иногда акула — рекрутер. Иногда рекрутер — лоцман. Все ок, это симбиоз.

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

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

Пример алгоритмического мышления?

Пожалуйте.

Управление браузером.

Я могу открыть браузер и закрыть.

Если я кликну по иконке, браузер откроется. И никак иначе.

Если я кликну по кнопке закрытия (File > Close > Are you sure? > Yes! > Really? > Yes, bleati! > Well…), браузер закроется — так должно быть по-умолчанию, и так было вовеки веков еще до появления первого браузера, и так будет еще лет триста после смерти последнего тракториста.

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

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

Если я найду ошибку, я ее или приму к сведению, или исправлю, или сообщу о ней своему окружению (шоб все знали).

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

Тут та же магия, что возникает при общении матери и ребенка.

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

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

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

Если обладатель такого мышления говорит таксисту: «И еще завезите меня вот туда, я вам доплачу за овертайм столько-то«, а таксист ему ВНЕЗАПНО отвечает: «Дитынах!«, то у психотипа ВНЕЗАПНО случается проблема с выбором дальнейших действий.

Типа, что Я не так сделал?

Куда нажать, чтобы всё исправить?

Таксист не работает as expected!

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

Такой человек подразумевает, что процесс найма должен происходить по определенному алгоритму.

Такой человек может просидеть всё время беседы с мыслью вроде «Пить хочу, а эти козлы мне ни чая, ни кофе не предлагают«, хотя разумнее было бы сказать: «Парни, я пить хочу. Где у вас чай вода кофе коньяк?«, но что-то останавливает. Типа, полагается, чтобы они додумались о потребностях, чтобы угостили водой, чтобы проводили в туалет, ну и тыды. Типа, они же должны были это предусмотреть.

Да, им бывает сложно сообщить о том, что «Все, я умываю руки! Где тут у вас рукоумывальная?«.

Зато потом несложно в твитере сообщить о том, что в такой-то компании странные рекрутеры, не предложили сходить в нужник 🙂

Рекрутинг во всех отраслях принципиально однообразен, но «айтишные рекрутеры» должны существовать как отдельная категория. Там не столько во фреймворках надо разбираться, сколько в понимании определенных психотипов.

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

Им плевать на то, что «Рекрутер жужжит, потому что: добросовестно выполняет свою работу» — рекрутер не должен жужжать, он должен появляться «по запросу». Как браузер. И исчезать, если ему посылают команду «Исчезни!»

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

До тех пор, пока рекрутер не понадобится, его активность излишня, и должна быть подавлена. Как браузер.

Рекрутер, который/ая/ое начинает работать с айтишниками, должен некоторое время молча понаблюдать за этим зоопарком, не пытаясь заставить всех жителей вольера волков разделять его культуру общения с овечками (сферическими в вакууме). Лично он, рекрутер, «бедных овечек живьем сжирать ни за что не станет«. А они — жрут.

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

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

Помните о ваших главных аргументах: «Готов работать нелимитированные часы. Готов работать в выходные и праздники. Готов работать на любых условиях по оплате«.

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

Выйдя из комнаты, менеджер понял, что из всего сказанного этим русским он на сто процентов понял только одну фразу «Выл ворк дэй энд найт» («Will work day and night» — Буду работать день и ночь).

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

— Сдается мне, Джим, что этот парень не совсем хорошо говорит по-английски. Но зато какое отношение к работе!!! Пойди-ка и поговори с ним на любую тему: о природе, ценах на нефть, скучает ли он по России. Самое главное, что тебе нужно выяснить: будешь ли ты в принципе понимать его.

Джим пошел и поговорил, потом пришел к менеджеру и сказал

— Конечно, акцент у него будь здоров, но дело в том, что я вырос в среде русских в городе Чикаго и даже немного говорю по-русски. Так что надо брать. Этот будет работать за троих. Да и на предложенную нами зарплату сразу согласился.

Нужно сказать, что ни менеджер, ни Джим ни разу не пожалели о своем решении.

Дык вот, это безусловно хорошее отношение к делу, но это плохой пример для подражания «в лоб».

«Выл ворк дэй энд найт» — это кислая вишенка.

• Если она находится на сладком и красивом торте — она рулит.
• Если она просто сама по себе, плюс положена на какое-то недоразумение под названием «праздничный пирог» — это буэ, это кисло. Это фу.

В принципе «Выл ворк дэй энд найт» — это позиция слабого. Это просительное выражение. Само по себе оно производит очень нехорошее впечатление.

Правильное впечатление оно производит только будучи произнесенным вслух (не в тексте CV) в уместном контексте, и только если произносящий четко знает, что он из себя представляет и на каком свете он находится.

Анадысь очередной кандидат написал этот «Выл ворк дэй энд найт» непосредственно в своем резюме.

Это вызывало ряд вопросов с тэгом «Недоумение», и дальнейшая встреча все это недоумение зацементировало — просто начинающий тестировщик (без огонька) просто ищет просто работу, бо ему надо здесь и сейчас.

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

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

Походу, ему было страшно.

Цель его была озвучена в таком стиле: «Готов работать днем и ночью до тех пор, пока вы не посчитаете меня профессионалом«. А потом что? Стал профессионалом и резко перешел на двухчасовой рабочий день? А если пять лет никто не будет считать тебя профессионалом?

И что за абстракция такая — быть профессионалом…

В общем, Савина продолжаем читать, но и по сторонам глядим.

Например, готовность работать день и ночь оценит менеджер общего плана, но совсем не оценит технарь…

На что надо обращать внимание при собеседовании

Оказывается, на зубы.

На сайте art-hr.com очень ржачно рассказывают о том, что говорят о собеседнике его зубы.

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

Зубы большие и крепкие принадлежат доброму и храброму человеку, долгожителю.

Длинные и твердые зубы — прожорливому и злому.

Этот отличный верблюд вряд ли пройдет собеседование на должность тестировщика

Длинные, остроконечные и выпятившиеся — ненасытному, злому и скупому.

Толстые зубы — нежному, но прожорливому.

Вот так сочетание…

Ровные зубы характеризуют сердитого, красноречивого и дающего доб­рые советы человека.

Неровные — глубокомысленного человека.

Белые — глуповатого, пустого.

Редкие зубы характеризуют похотливого, сквернословного человека.

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

Большие чистые зубы бывают у людей грубых инстинктов, жаждущих животных наслаждений.

А если маленькие чистые зубы?

А если они и маленькие, и белые, и во сне сегодня я видел часы с персиками?

Странно, что не указан самый очевидный вариант — «у кандидата нет зубов»…

Я так понимаю, в рунете появился околочикатилльный рекрутер-стоматолог. Перед походом к нему на прием надо подпилить зубы согласно приведенным параметрам, чтобы полностью «соответствовать».

Скоро этот дядя объединится с рекрутером-урологом, и они начнут выступать в Comedy club и у Геннадия Малахова…

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

Длинные волосы носят и мужчины, чаще те, кто причастен к миру ис­кусства, к музыке. Особенно часто можно встретить длинные волосы у муж­чин, которые занимаются тяжелой музыкой: тяжелый рок, например.

Женщины с неуравновешенной нервной системой часто меняют цвет волос и форму стрижки. Причем — несколько раз во время собеседования. Что Москва с людьми творит…

Теперь о серьезном.

О чем надо рассказывать при начале собеседования

1. Кто ты в этой компании.
2. Какая работа тут делается.
3. Какую работу требуется выполнять будущему наймиту.
4. Место работника в структуре компании.
5. Что входит в служебные обязанности сотрудника на данной позиции.
6. Как в компании выглядит процедура найма. Как долго она длится, из скольких этапов состоит. Кто принимает окончательное решение о найме.
7. Это новая вакансия или позиция уже существовала в компании. Почему она освободилась.
8. Перспективы карьерного роста.
9. Каким образом будет оцениваться качество работы.
10. Охарактеризовать корпоративную культуру компании.
11. Какие в компании существуют правила.
12. Как выглядит типичный день работы в отделе. Из чего он состоит.
13. Атмосфера в коллективе.

Уложиться надо в десять минут. Все, что более — утомляет.

Если предварительно с кандидатом беседовал HR, следует учесть заметки о том, что «в принципе интересует кандидата», и корректировать свою речь.

О чем можно спрашивать в ходе собеседования

Отмечу, что «можно, а не «надо».

Лучше сосредоточиться на компетенции кандидата. Но можно и смешивать…

Опыт: последовательно задавать вопросы из указанных областей не получится.

Компетенции тестировщика

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

Компетенции тест-проектировщика

все предыдущее +

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

Компетенции тест-менеджера

все предыдущее +

• управление персоналом
  • теории мотивации
  • конфликтология
  • коммуницирование
  • власть лидерство влияние
• управление командами
  • подбор команды
  • построение и развитие команды
  • управление деятельностью команды
• стратегическое планирование
  • управление рисками
  • планирование качества продукта
  • декомпозиция работ
  • планирование ресурсов
• тактическое управление
  • передача на тестирование
  • исправление дефектов
  • оценка трудозатрат
  • глубина тестирования
  • управление исполнением
  • сообщение информации
  • контроль расписания
• мониторинг работы
  • мониторинг качества продукта
  • мониторинг эффективности процесса
  • мониторинг рисков
  • управление расписанием
  • управление стоимостью
  • управление содержанием
  • отчетность

Компетенции инженера по автоматизации

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

О личном

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

Дополнительно

Принципы организации проведения интервью перед проведением интервью толково изложила Натальи Руколь «12 правил успешного собеседования тестировщиков«.

Уйму корректных вопросов о тестировании можно найти, если шариться по сайтам вроде softwareqatest.com За всю свою карьеру я насобрал около трехсот таких вопросов, и могу продержать «на вопросах» любого кандидата на протяжении нескольких часов (эдакий стресс-тестинг).

Другое дело, что применять всё это даже в отношении самого себя мне совершенно не хочется. Да и это даст немногое. Ну, стрессоустойчивость… А если это просто здоровый пофигизм?

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

Всех и сразу заклинаю проводить грань между знанием и понимаем.