Это перевод статьи.
Еще в июне я с большим интересом прочитал статью Джона Стивенсона, в которой обсуждается карьерный рост для тестировщиков. В то время (и до сих пор) статья задела меня за живое, потому что аналогичные вопросы начали подниматься в моей нынешней компании.
Примечание переводчика: Небольшое отступление и пара слов о той статье. В статье приводятся разная статистика о тестировщиках – пол (75% мужчины, хотя, в моей практике я бы сказал, что женский пол превалирует), способ развития (совпадает с этой статьей) и зарплата. Последнее меня весьма удивило, потому как, если верить ей, то тестировщики в среднем получают столько же или больше программистов и разработчиков, что явно расходится с моим опытом (к тому же в статье делается упор на то, что меньше, хотя цифры говорят обратное).
После некоторых забот о вовлеченности сотрудников, я (глава тестировщиков) а так же остальные начальники функциональной части (разработка программного обеспечения, управление проектом и техническая разработка), занялись разговорами со всеми своими людьми в пределах наших компетенций. Мы разработали набор вопросов, направленных на получения реальной картины: их текущего взгляда на свою карьеру и свою роль в компании.
Во-первых, это было здорово, просто обойти и поговорить со всеми, а во-вторых, разговор со всеми двадцатью тестерами дал мне довольно хорошее представление о том, где лежат проблемные участки.
Джон Стивенсон в своей статье пишет: «Да, ХХХ, был таким отличным тестером, но он был вынужден перейти в разработчики, чтобы иметь возможность развиваться в компании» и именно эту фразу я слышал в той или иной форме несколько раз. В нашем случае это был переход либо в разработчики, либо в управляющих проектом. Оба варианта рассматривались в качестве единственного реального прогресса для тестировщика. //Примечание переводчика: не совсем ясно, почему игнорируется путь QA Engineer -> Senior QA Engineer -> Lead QA Engineer. Но оставляю это на совести автора.
Это сделало меня грустным.
Потом, когда я изучил данные получше, выяснилась тенденция, что большинство тестировщиков, которых мы приняли на работу выпускниками год-два назад, сейчас заинтересованы в переходе в разработчики, в то время как тестеры со стажем 3-5 лет смотрят в сторону управленцев.
Так почему же наши тестеры с менее двухгодичным опытом хотят перейти в разработчики? В дальнейшем стало очевидно, что компания стремится к частым релизам продукта; заметен существенный рост автоматизации тестирования. Мы всегда много времени уделяли автоматизированному тестированию, но теперь больше, чем когда либо. Совокупность малого времени на подготовку и акцента на быстрых выпусках, привела к тому, что наши новые тестировщики делали в основном автоматизированное тестирование и тупое ручное регрессионное тестирование.
Ручное тестирование == Исследовательское тестирование
Возможно, желание сменить область деятельности является следствием узкого зрения на роль тестирования. Когда тестировщиков спросили об исследовательском тестировании, некоторые из них утверждали, что они делали его каждый выпуск, но это было очень скучно и они просто делали то же самое снова и снова.
Именно в этот момент я начал соединять точки. Вероятно, реальная проблема была в том, что даже если они и знали о существовании других областей тестировании, они не понимают, что эти области собой представляют на самом деле. Например, в их глазах исследовательское тестирование == ручному тестированию, так что если их единственная возможность проявить себя как тестировщика было прогоном регрессионного тестирования по заранее составленным спискам, неудивительно, что они захотели покинуть корабль!
Поэтому, возможно, реальной проблемой является образование. Как компания, мы упорно работаем над более частыми релизами за последние пару лет, и поощряем команды адаптировать свои методы работы под более гибкие условия, чтобы быть более эффективными. В результате, большая часть нашей команды работает на полную мощность большую часть времени, что не оставляет времени на обучение и развитие. Есть конечно некоторые люди, которые находят время, для того чтобы узнать что-то новое, но мы должны смотреть в общем — «время» является барьером в этом уравнении.
Это было подтверждено многими тестировщиками, когда их спросили, был ли у них какой-либо прогресс в процессе обучения. Их частый ответ был: «Нет, у меня нет времени» или «Нет времени в течение дня, чтобы сделать это».
Зная, что вы не знаете
Как прямой результат этого исследования мы смотрим на то, как мы можем ввести время на подготовку в проекты. Есть уроки, которые можно извлечь из Google убрал 20% времени и нашего собственного опыта, поэтому мы уверены, что сможем реализовать что-то у себя. Работа над этим продолжается.
Но само по себе это не решит проблему. Как вы можете научиться чему-то, если вы даже не знаете, что это такое — то, что вы должны узнать. Существует некая вещь в знаниях, в рамках вашей роли, но вы не знаете что именно. Может, вы считаете себя опытным тестировщиком, когда как вы, на самом деле, просто не в курсе некоторых областей вашей роли. Это может показаться абсурдным, но представьте, что у вас было мало контактов с обществом тестировщиков, за пределами вашего маленького командного пузыря тестеров или даже всей компании. Тогда ваше представление о своей роли будет значительно меньше, и обрезаться до тех навыков, которые необходимы вам ежедневно. Если мы приняли подход мастеров программного обеспечения, то у нас есть много учеников, очень немного подмастерьев, а мастеров и того меньше. Это означает очень мало возможностей для наставничества.
Это приводит меня к другому существенному различию между разработчиками и тестировщиками, о котором я подозревал в течение длительного времени, и которое было подтверждено нашими данными. Разработчик обычно играл в компьютер, будучи ребенком, узнавал компьютер лучше в школе, продолжал обучение в сфере информационных технологий и возможно даже получал степень в университете и все это с целью стать разработчиком. Желание разрабатывать что-то это их страсть и они, как правило, занимаются программированием все свое время (по крайне мере до брака, детей и тому подобном).
У тестировщиков нет высшего образования по тестированию программного обеспечения, нет занятий по тестированию в школе и я уверен, что ни у кого не было жгучего желания ребенком или подростком стать тестировщиком программного обеспечения. Грустно осознавать, что изрядное количество тестировщиков (и я тоже) раньше получили эту работу, потому что им не хватило знаний или упорства для разработчиков. Навыки, необходимые для тестирования, такие как любознательность, внимание к деталям, способность смотреть на общую картину (а так же многие другие) являются теми чертами, что у меня всегда были, так что, к счастью, все стало благополучно.
Тем не менее, я думаю, что тестирование программного обеспечения в настоящее время рассматривается как добросовестная карьера в своем праве и многие компании сейчас не рассматривают это как неудачный путь разработчика.
Но я хочу сказать, что без этого жгучего желания быть тестировщиком, новый тестировщик должен изучить практически с нуля все те навыки, что включает в себя роль тестирования.
И это то место, в котором мы ошиблись. В моей компании разработчиков и тестировщиков рассматривают на равных, да и вообще много навыков являются общими. Однако новым тестировщикам возможно гораздо больше внимания уделить для объяснения ролей и навыков необходимым им.
Карта навыков
В попытке открыть глаза нашим тестировщикам и пролить свет на навыки, которые охватывает роль тестирования, мы собрали карту навыков. Центр карты представляет собой набор тех основных навыков, в каких каждый тестировщик должен иметь хотя бы базовые знания. После расходятся от центра четыре квадранта. Эти квадранты определяют направления, которые человек мог бы взять. Он все еще оставался бы тестировщиком, но мог бы уже определить какую именно форму тестировщика он мог бы принять.
Путем явного просмотра набора основных навыков, таких как исследовательское тестирование, методики испытаний, проблема отчетности, парное тестирование, автоматизация тестирования, намеренная практика, предоставление обратной связи и др., это становится намного проще для тестера для определения того на чем он должен сосредоточиться. Очень важно, чтобы основные навыки были изучены, практикованы и отточены, прежде чем думать о специализированных навыках.
Эта схема используется в личных беседах по развитию между тестерами и их руководителем, чтобы помочь найти им сильные и слабые стороны и сформировать цель для дальнейшего обучения.
Мы испытали это на нескольких людях, и мы до сих пор занимаемся настройкой и оптимизацией. Но этот инструмент выглядит перспективным для помощи в обсуждении карьеры.
Есть надежда, что некоторые из тестеров-новичков, посмотрят на раздел основных навыков и определят несколько областей, которые они должны улучшить.
Конечно, это долгий путь и мы не утверждаем, что эта схема ответит на все вопросы, но это только начало.
Автор: Palomnik
