Вступление от переводчика

Был удивлен, что этот текст уважаемого Канера, написанный в далеком 1999 году, до сих пор отсутствует на русском языке. Прочитанный мной году в 2010-м, он тогда был актуален более чем. 

Затронув в QAsmokeQA сейчас, в 2022-м, тему "Мне 40+ и я с нуля иду в QA" - это вообще нормально?”, я начал искать русский перевод для аудитории, пока еще неуверенно владеющей английским. И обнаружил, что его до сих пор нет. Возможно, в этом виноват сам Канер, в 1999-м году во вступлении к тексту пообещавший, что тот вскоре станет главой в 3-м издании “Тестирование программного обеспечения”. Которое так и не вышло. Во всяком случае, пока.

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

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

Несомненно, некоторые подходы уже устарели. Требования в IT выросли. И привлечение “транзитного пассажира” в тестирование только на шесть месяцев на текущем этапе развития IT может быть нерентабельным. Появились новые форматы вроде удаленной работы.

Но открытость Канера к каждому кандидату, отсутствие зашоренности, предубеждения к опыту или возрасту, умение видеть в любом соискателе уникальное сочетание потенциальных возможностей и потребностей будут актуальны и через сто лет. Кстати, эти мысли коррелируют и с идеями одной из лучших книг по работе с человеческим капиталом "Сначала нарушьте все правила. Что лучшие в мире менеджеры делают по-другому" (“First, Break All the Rules: What the World's Greatest Managers Do Differently”).

Люди, которых вы ищете

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

И, как это всегда касается анализа требований, вы можете погрузиться слишком глубоко и впасть в ступор. Процесс очерчивания должностных обязанностей и определения личных качеств будущих соискателей кажется мне отличной возможностью для вхождения в состояние “аналитического паралича”. Поэтому, пожалуйста, прочтите текст и поразмыслите над ним. Но также помните про правило 80/20. 80% пользы принесут первые 20% усилий.

Сила в разнообразии

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

Кроме того, процесс тестирования требует иногда совершенно разных наборов навыков. Например, несколько лет назад мы с Джеком Фальком (Jack Falk) работали с компанией, производившей программное обеспечение для управления опционами сотрудников. Эта прикладная область является предметом сложного государственного регулирования (налоги, вознаграждение работникам, закон о ценных бумагах, а иногда и закон о кредитах).

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

• Тест-лид или QA-менеджер с опытом руководства.

• Тест-лид или QA-менеджер с сильными навыками планирования. Если это тест-лид, ему необходимы отличные навыки наставничества, потому что иначе у него не останется времени на собственное тестирование.

• Специалист по автоматическому тестированию, готовый помогать остальной группе с инструментарием. 

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

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

Некоторые из этих людей обладают навыками программирования. У других есть специальные знания в прикладной области. Другие владеют инструментами и ​​методами тестирования вроде «черного ящика». 

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

Некоторые из наиболее эффективных тестировщиков, с которыми я работал, не имели опыта программирования. С другой стороны, большинство высокоэффективных групп тестирования, с которыми я работал или консультировал, имели в штате хотя бы одного опытного автоматизатора. Разнообразие необходимо. Повторяйте до тех пор, пока не будет завершен набор. Разнообразие необходимо.

Отношение к тестированию как к промежуточной станции

Тестирование — это самая простая точка входа в IT-компанию, и поэтому многие люди попадают в тестирование на пути куда-то еще. Они хотят стать программистами, маркетологами, руководителями проектов, техническими писателями и так далее. За прошедшие годы ко мне пришло огромное количество людей с блеском в глазах и готовностью выложиться в тестировании за соответствующее количество денег. Если они предлагали мне правильное сочетание способностей, я их нанимал, хотя знал, что рано или поздно они уйдут. (Опять же, в конце концов все уходят.) Удивительно, но многие из этих людей оставались в тестировании надолго или возвращались к нему позже. Тестирование может стать для вас притягательной областью. Как только вы его прочувствуете. 

Даже распознанные “транзитные пассажиры” могут добавить существенную ценность и разнообразие в вашу группу. Рассмотрим следующие примеры. 

Это реальные люди, но имена изменены: 

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

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

• Сэнди была руководителем службы техподдержки и имела опыт продаж ПО. Когда ее отдел был передан на аутсорсинг, она перешла в тестирование. Наряду с ориентацией на клиента, что всегда приветствовалось в этом отделе, она привнесла сильные навыки планирования, составления бюджета и отчетности. У нее также был представительный вид (продавцы могут быть очень ценны в отделе тестирования) и она умела сообщать плохие новости, не создавая межличностного конфликта. Через короткое время (примерно два месяца) после присоединения к группе тестирования она стала руководителем крупнейшей в компании группы тестирования, работающей над наиболее важным проектом с точки зрения сроков поставки. Ее умение отслеживать текущий статус, давать ранние предсказания о проблемах и менеджмент “без кнута” дали большой положительный эффект. Проект был выполнен в нужном качестве на день раньше срока. Примерно через год после присоединения к группе тестирования Сэнди перешла на должность старшего специалиста по технической поддержке в другом месте. За тот год, что она провела в тестировании, она была бесценна. 

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

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

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

Есть много других историй, подобных этим. Историй людей, которые пришли в тестирование с сильным набором навыков и желанием поработать в тестировании на относительно короткий срок (от 6 до 18 месяцев). Которые очень быстро начали вносить огромный вклад в группы, к которым они присоединились. Или которые внесли бы огромный вклад, если бы ими правильно управляли. 

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

«Найм возможности»

Мне нужен отличный персонал. Это непросто. Труднее, когда отрасль процветает, как сегодня, потому что людей меньше, чем рабочих мест (пер.: текст написан 23 года назад!). Еще сложнее, когда я работаю с компанией, которая платит меньше, чем по рынку. (Я создавал группу тестирования в одной компании, чьи продукты были очень интересными, но чья максимальная зарплата соответствовала ставкам начального уровня в других компаниях-разработчиках программного обеспечения. Мне удалось набрать высококвалифицированный персонал, но для этого потребовался творческий подход.) Когда я не могу предложить лучшие деньги, или самую захватывающую линейку продуктов, или карьерный путь в этой области, я должен найти какие-то другие стимулы для привлечения крепких талантов. И поэтому я ищу людей с особыми потребностями, которые я могу удовлетворить. Эти люди обладают сильным набором навыков, но у них также есть некоторый багаж, из-за которого другие QA-менеджеры не хотят их нанимать. И это приносит мне пропорционально больше подобных специалистов. Если я могу установить связь с группой (группами) таких людей, и если у меня есть интересная именно для них работа, я уже могу выбирать. Я называю таких людей «найм возможностей» (opportunity hires). Для них работа, которую я предлагаю, — это особая возможность. Для меня навыки, с которыми они приходят, также дают новые возможности. 

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

Вот несколько примеров:  

• Пенсионеры, особенно пенсионеры, которые хотят работать только 20 или 30 часов в неделю. Люди увольняются со своей динамичной работы с полной занятостью и обнаруживают, что им нужны деньги или что им стало скучно. Те, о ком я говорю, не ищут напряженной работы, которая может требовать много сверхурочного времени. Они ищут интеллектуально стимулирующую активность, которая предлагает постоянный рабочий день и дает некоторую гибкость, чтобы проводить свободное время, когда им приходится заниматься личными делами.

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

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

• Возвращение к работе. Типичным случаем является мать, которая возвращается к IT после того, как несколько лет посвятила заботе о своих детях. Шон (менеджер проекта, о котором говорилось выше) остался нанятым, но не в разработке ПО. Аналогичное касается и технического специалиста, который годами занимался продажами и маркетингом, а потом понял, что ему больше нравится заниматься чем-то техническим. Эти люди приходят к вам со способностями и опытом, но без текущих знаний инструментов, языков и передового опыта.  

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

• Смена карьеры. Некоторыми из моих самых успешных наймов были людьми, которые покидали должности среднего и старшего уровня в другой области, чтобы войти в IT. Эти люди не приходят к вам и говорят: «Я хочу поработать в тестировании год, прежде чем двигаться дальше». Это люди, которые говорят: «Я хочу быть в IT. С чего можно начать?» Они вполне могут остаться в тестировании. Ключом для этих людей часто является не шкала заработной платы. Это возможность обучения новой профессии. Если вы можете/желаете потратить дополнительное время на обучение, у вас может получиться конкурентоспособное предложение. Даже если кандидату придется пойти на резкое сокращение заработной платы. 

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

Возможность как риск

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

И снова имена изменены: 

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

• Сэнди хотела работать программистом уже сегодня. Она согласилась на место в группе тестирования, но, начиная с первого рабочего дня, начала делать все возможное, чтобы добиться перевода в группу программистов.  

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

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

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

Минимизация рисков «найма возможности»: краткосрочные контракты

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

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

Если кандидат не тянет, но очень старается и достаточно хорошо ладит с остальным персоналом, я обычно держу его шесть полных недель. Таким образом, он завершает контракт. И это помогает ему на следующем собеседовании, когда потенциальный работодатель спрашивает: «Почему вы ушли из BugWare, Inc.? Вы проработали там всего шесть недель». Он может честно ответить: «Это был всего лишь шестинедельный контракт. Я его выполнил». Таким образом, шестинедельный контракт ограничивает и мой риск как работодателя и риск кандидата. Любой из нас может уйти без осложнений. 

Минимизация рисков «найма возможности»: групповая заинтересованность 

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

Послесловие от переводчика

Этот перевод - часть цикла хабр-статей (более 140'000 прочтений за два месяца) в рамках исследования QA-курсов:

• Беда “войти в айти” или курсы тестировщика отзывы. Глава 0, в которой перитониты

• Беда “войти в айти” или курсы тестировщика отзывы: Глава 1, в которой нас разводят на деньги

• Беда “войти в айти” или курсы тестировщика отзывы: Глава 2.1, в которой легкий испанский стыд

• Беда “войти в айти” или курсы тестировщика, отзывы: Глава 2.2, в которой сильный испанский стыд

• Беда “войти в айти” или курсы тестировщика отзывы: интермедия про чек-лист выбора IT-курса

• Беда “войти в айти” или курсы тестировщика отзывы: 5-минутный тест на перспективы в QA

• Беда “войти в айти” или курсы тестировщика отзывы: Глава 3, в которой эксперт с 15+ годами QA-опыта разбирает содержимое курсов, а студенты дают обратную связь изнутри (релиз-кандидат)

  Если не хотите пропустить следующий материал автора, что-то новое в QA-курсах или нюансы QA-собеседований, подписывайтесь на http://t.me/QAsmokeQA