Зачем тестировщику портфолио, или Как выделиться на рынке труда

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Мне нравится выражение «рынок труда». Оно значит ровно то, что значит. Каждый из нас буквально продает свои навыки и умения. Более опытные и известные рынку могут обойтись скромным прилавком (например, «Пишу на Java 10 лет») — и будут пользоваться спросом. «Средняки» часто выставляют весь ассортимент своих способностей. Малоизвестным продавцам приходится бродить по рынку и кричать «Мануальный тестировщик, свежий мануальный тестировщик!».

Интуитивно кажется, что то, что стОит дороже, сделано качественнее, но опыт показывает, что это не так. Дороже стОит то, за что установили более высокую цену, а точнее, то, за что эту цену готовы заплатить. Здесь можно вспомнить и про «зарплатный пузырь в IT», и про «дефицит высококвалифицированных низкооплачиваемых кадров», и про «синдром самозванца». Но эта статья не об этом. Эта статья о том, как и зачем организовывать свой прилавок.

Тестовые задания как необходимое добро

Меня зовут Виктор Максименко, я Senior AQE и AQA Manager в AB Soft. Последние два года я занят формированием и расширением своей команды. Мне довелось провести множество интервью, некоторые из моих сокомандников уже и сами собеседуют себе инженеров. Вместе с тем, немало собеседований я прошел как кандидат. Возвращаясь к аналогии с рынком, я бывал и продавцом, и покупателем.

Признаться, я не очень люблю собеседования. Я могу выучить техники тест-дизайна и принципы ООП, но значит ли это, что я умею их применять? Я могу заучить названия паттернов, но использую ли я их в своем проекте? И главное: разве моя работа заключается в том, чтобы отвечать на вопросы?

Потому я люблю тестовые задания. Хотя и понимаю тех, кто их не любит. Я уже слышу взрыв негодования: «Почему я должен работать бесплатно??? Еще и в свое свободное время!!!1!». Ответ: потому что вы пытаетесь себя продать. Безусловно, дефицит на рынке позволяет «продавцам» диктовать свои условия: «не купишь ты — купит другой, у меня таких очередь». Тем не менее, у ваших навыков должно быть большее подтверждение, чем строки в вами же написанном CV. Увы, объективных категорий и градаций у нас нет, а сертификации часто не подтверждают наличие умений.

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

Для меня тестовое — это возможность проверить себя и добавить проект в портфолио. Для чего? Чтобы показать его следующему «покупателю». Потому кандидатам в свою команду я предлагаю или сделать тестовое задание, или поделиться примерами своего кода на GitHub. Если в CV уже есть ссылка на GitHub, то вопрос может отпасть сам собою.

Почему GitHub

Несмотря на наличие аналогов (GitLab, Bitbucket, и т. д.), GitHub по факту стал домом для множества проектов с открытым исходным кодом, потому это отличное место, чтобы и на других посмотреть, и себя показать. К тому же, его можно использовать как место знакомства с другими разработчиками. Или как инструмент для поиска работы.

Отдельно выделю его фичу GitHub Pages, при помощи которой можно создать свой персональный сайт и хостить его непосредственно на GitHub. И нет, увы, GitHub не платит мне за рекламу.

Открываем исходники

Однажды Eddie Jaoude, активный участник open-source community, так ответил на мой вопрос о том, что же можно отдавать в open-source: «Все, кроме того, что нельзя». Другими словами, не стесняйтесь демонстрировать то, что вы делаете. Да, большинство подписывает NDA и не могут показывать свои наработки. Тем не менее, в нашей профессии обучение может идти и в нерабочее время, и вот о нем уже можно рассказать, а его результаты — показать.

Приведу пару примеров:

  • Вы сели изучать Java — отлично, добавьте листинги кода из ваших уроков в свой репозиторий на GitHub. Вы их уже написали, потратьте 3 минуты и добавьте доказательства вашего нового навыка в LinkedIn.
  • Изучаете Bash — добавьте репо со скриптами.
  • Осваиваете Git — пусть в вашем репо будет несколько веток и множество коммитов. И поместите в README.md описание изученных вами команд и то, как их применить на вашем репозитории.
  • Читаете «Чистый код» Роберта Мартина — покажите листинги «плохого» и «хорошего» кода, а еще лучше — «плохого» и «отрефакторенного».
  • Учитесь работать с CI инструментами — прикрутите CI к вашему репозиторию.
  • Посетили конференцию — сделайте GitHub Gist с заметками.

Отдельно замечу важность README-файла. Он, как и листинги кода, показывает как вы умеете документировать ваши проекты и как относитесь к этому в целом. Хорошая документация должна помочь новичку на вашем проекте разобраться без вас. Указывайте требуемые зависимости, платформу, инструкции для развертывания и запуска, contributors и style guide, и любую другую информацию, необходимую для работы с проектом. Навык составления подобных руководств не стоит скрывать.

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

«Я — Manual QA, у меня нет исходников»

Но есть артефакты тестирования.

  • Сделайте репозиторий с тест-кейсами для демо-сайта в Excel таблице. Excel — не лучшая Tests Management System, но вполне достаточная, чтобы показать ваши умения в тест-дизайне. Покажите примеры разных техник, составьте тест-комплект и чек-лист, покажите, что умеете.
  • Добавьте на GitHub ваш шаблон для тест-плана. Безусловно, есть стандарт IEEE 829 для составления плана, но иногда он избыточен. У вас может быть ваш собственный шаблон, почему бы им не поделиться? Или аналогично пункту выше, можно разместить пример составленного вами тест-плана.
  • Оформите баг в GitHub issues. GitHub используется для open source проектов, и позволяет пользователям сообщать о проблемах или запрашивать новые фичи через GitHub issues. Выберите демо-сайт и поищите на нем баги. Если нашли — заведите их как issue в вашем репозитории. Покажите, что правила оформления баг-репорта вам известны.
  • Экспортируйте коллекции Postman. Если вы занимаетесь тестированием API, покройте тестами какой-то из публичных API. Экспортируйте запросы (Postman-коллекции, команды cURL, etc) и добавьте их под контроль версий. Добавьте инструкцию к использованию, и ваш будущий интервьюер наглядно увидит, что вы умеете

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

Contributing to Open Source

Этот раздел — продолжение списков выше, но он заслуживает отдельного упоминания. Участие в Open Source проектах показывает не только ваши навыки в написании кода, но и умение работать в команде, критиковать и принимать критику, формулировать проблемы и главное: договариваться с людьми со всего мира, которых вы, возможно, никогда не видели и не увидите, но которых интересует то же, что и вас. Последнее особо важно в эпоху распределенных команд и удаленной работы.

Если вы не знаете, с чего начать свой путь в open source — загляните на goodfirstissue. Или просто подберите интересующий вас проект на GitHub.

Опенсорсим свою работу

Этот путь может быть простым и гладким, если в компании есть культура open source, и сложным и тернистым, если ее нет.

Если вы хотите сделать свои наработки open source проектом, нужно быть готовым к тому, что придется проходить через множество бюрократических проволочек. Нужно будет доказывать, что открытым компаниям больше доверяют, что open source — это мировой тренд, что не все нужно скрывать и что привлечение энтузиастов может принести компании новые идеи. Тем не менее, в результате вы сможете добавить себе в послужной список большой проект, требующий не только Hard, но и Soft Skills. А еще начальство, к которому вы придете со своей инициативой точно вас запомнит. Стоит оно того или нет — тут уж решать вам.

Не Open Source единым

Напомню, что наша цель — показать свои навыки и доказать свою ценность. Развивайте персональный бренд.

  • Выступайте на конференциях. Рассказывайте об интересном опыте, изученных технологиях, успехах и провалах.
  • Заведите YouTube/LinkedIn/TikTok/Twitch/Twitter/любое другое соцмедиа. Делитесь с другими своим карьерным путем или тем, что вам интересно. Главное — ваш аккаунт должен больше показывать ваш профессиональный навык, а не что вы едите или где отдыхаете. Лучше отделять личное от рабочего.
  • Пишите статьи. Если публичные выступления не для вас — выливайте свои мысли на бумагу. Даже если вам довелось страдать с каким-то инструментом или технологией — пишите, предостерегите остальных, пусть учатся на ваших ошибках.
  • Займитесь преподаванием и менторингом. Не важно, помогаете вы джунам в команде или учите людей в школах, университетах и на курсах. Если вы поможете вашим ученикам, они точно вспомнят вас добрым словом и, возможно, однажды замолвят за вам словечко или расскажут уже своим ученикам.

Отдельно укажу, что перечисленные выше активности интересны не только вам, но и, скорее всего, вашей компании. Если они хотят показать, какие крутые, опытные и проактивные инженеры у них работают, они будут рады упоминанию на популярных ресурсах. К примеру, у нас в AB Soft написание статей и проведение докладов поддерживается и финансируется.

Подведем итог

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

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

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

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось32
До обраногоВ обраному15
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
. К примеру, у нас в AB Soft написание статей и проведение докладов поддерживается и финансируется.

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

Я реально хз, зачем предлагать тестовое не джунам.

Затем, что не все, у кого в title указано middle или senior этому тайтлу соответствуют. Как я и писал

объективных категорий и градаций у нас нет, а сертификации часто не подтверждают наличие умений

И по поводу

Никогда ещё не удавалось дойти до конца списка предложений, не получив по пути оффер, чтобы сделать тестовое.

Такая ситуация связана с высоким спросом. Насколько это ок — отдельная холиварная тема, но «маємо те, що маємо»

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

Вы сели изучать Java — отлично, добавьте листинги кода из ваших уроков в свой репозиторий на GitHub.

Нужно больше хлама в интернете!

Когда отбирал резюме кандидатов на одной из прошлых работ, даже беглый просмотр их гитхаба выдавал, что сделано по урокам, а не своими mad skillz.
Особо забавляло, когда одинаковые примеры были у нескольких кандидатов. Этакий солипсизм: «уроки давали персонально мне, больше никто так не делал», как же.

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

Если кандидат отвечает что-то в духе

«ну, нам на курсах что-то рассказывали про git»

То это либо интерн, и тогда это должно быть ок, либо непонятно как этот человек вообще попал к вам на интервью ))

Легко, в CV может быть написано много слов, и они вполне быть правдой. Кандидат может сказать, что имел дело с гитом и не соврет, он же что-то слышал о нем на курсах.

не понимаю, как 20 hello world проектов помогут оценить

Senior AQE, AQA Manager.

Senior AQE — не факт, а его навыки вполне. Как минимум увидеть, что перечисленные технологии не просто скопированны из открытых вакансий. Ну или увидеть, что с условным Ruby он не работал много лет :) Ну и со стороны интервьюера наблюдал, что у кандидата может быть 5-7 лет опыта в автоматизации и Senior AQE в title, а тестовое уровня hello world проекта хромало на обе ноги. Вот вам и оценка сеньерности.

Зачем Git и Bash выделять в особые умения? Умение выйти из vim более уникальное чем скриптики на баше, или не запороть репозиторий.

Как и писал выше, любой навык имеет смысл подтверждать и показывать. Если для вас умение выйти из vim важнее, сделайте видео-урок на эту тему, залейте на YouTube и добавьте ссылку в CV. Раньше вопрос об этом был самым популярным на StackOverflow, думаю, видео тоже соберет свои просмотры и лайки :) Хотя лично мне при поиске инженера было бы важнее знать, что он может починить запоротый репозиторий

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

Скорее, автор сам еще и деконструирует свои доводы:

Я уже слышу взрыв негодования: «Почему я должен работать бесплатно??? Еще и в свое свободное время!!!1!»

Ответ в духе: потому что так надо.. Ну, ок.. Надо.. Зачем надо?

Я могу выучить техники тест-дизайна и принципы ООП, но значит ли это, что я умею их применять? Я могу заучить названия паттернов, но использую ли я их в своем проекте?

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

В итоге, автору просто нравится делать тестовые — ну пусть делает.. А объективно профитного отношения эффорт/резалт я лично не наблюдаю..

Ух, попробую ответить по порядку. «известный бренд» в QA сфере, построенный на выполнении тестовых не сделать. Но боюсь вы пропустили все следующие разделы. Из моего опыта, я сталкивался с ситуациями, когда я думал «о, я о нем слышал, грамотный инженер». И следующей мыслью было или «хочу, чтоб он у нас работал», или «хочу работать у него в команде».
Но даже если ваше имя не на слуху, но у вас в CV или репо есть участие в каком-то проекте — это уже возможность посмотреть на вас как на специалиста в действии. Даже если я, как интервьюер, буду несогласен с вашим решением или мнением — это уже повод начать разговор. Так мы можем вести диалог, а не устраивать экзамен.
Собственно, вот и ответ на вопрос «Зачем надо?». Чтобы не рассказывать, что такое Wait в Selenium, просто пойдите и посмотрите в моем репо, как я его использую.

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

Может, но и то, и то — время, плюс не все хорошо решают задачки во время интервью, это стрессовая ситуация. Я не пишу код под надзором одного или нескольких незнакомых мне людей. Я пишу его дома, под пледом и с чашкой чая. И не всегда с первого раза хорошо. Значит ли плохо решенная задачка во время собеса, что я буду плохо решать рабочие задачи? Тут уже каждый интервьюер сам решает.

В итоге, автору просто нравится делать тестовые — ну пусть делает.. А объективно профитного отношения эффорт/резалт я лично не наблюдаю..

Здесь спорить не стану, ваша жизнь — ваши правила

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

Про участие в опенсорс проекте спорить не буду — однозначно плюс в копилку, а вот выполнение тестовых — такая себе инициатива. Требовать тестовое у человека с опытом — вообще, считаю, моветон. Разве что оплачиваемое, и то если необходимо проверить ооочень важную для проекта узкую специализацию :)

Согласен, я тоже не отправлял интервьеров в свой гитхаб и отвечал на вопросы, в конце концов, если они выбрали такой способ проверить мои знания — это их решение. Но тогда почему предлагать тестовое человеку с опытом — моветон, а спрашивать у него базу типа видов селекторов или вейтов — нет. Моя идея заключается в том, что тестовое — это способ отбросить базовые вопросы (зачем мне спрашивать о селекторах и вейтах, если я вижу, как их применяют) и перейти к более конкретным типа «почему вы здесь выбрали такой подход, какие у него плюсы-минусы? Что можем улучшить? А как бы это запустить в параллель? и т.д.» . Часто мы находили баги в самом решении и обсуждали их с кандидатом.

Код себе в репо можно и скопипастить, попросить кого-то за бутылку хенеси сделать тестовое, а ход мысли — нет :)

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

Что ж, советую тогда предлагать кандидату развернутый фидбек по тестовому за бутылку хенеси :))

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

Є приказка, що «покращення власного CV, портфоліо і т.п. — це сама високооплачувана робота».

Людина з бездоганним CV, доступними прикладами власної роботи — це не тільки зручність для тих, хто наймає.

Це хак, як виглядати на голову вище інших кандидатів і швидше знаходити саме більш круту роботу.

их тут же начнут делать «под ключ» и смысл исчезнет едва появившись (вместе с доверием).

Практично всі круті команди звертають увагу і на «брендовість» кандидата, і на його портфоліо.
І ніби всі про це знають, але реально цим займаються одиниці.

Із власного досвіду (провів десятки тех. інтервю і розглядав порядка сотні кандидатів після рекрутерів):
Навіть spell-checker не кожен використовує і відправкою CV з помилками.
Власне портфоліо чи організовані приклади коду також є далеко не у всіх.
В цьому контексті ідея про пошук платного виконавця для портфоліо під ключ виглядає дуже малоймовірною.

Є приказка, що «покращення власного CV, портфоліо і т.п. — це сама високооплачувана робота».

Я б сказав що проходження співбесід — це сама високооплачувана робота.
Я провів дуже багато співбесід і поступово відмовився від усього зайвого що часто включають в процес найму.
— Гітхаб проекти: люди тягнуть туди все підряд — те що робили не самостійно на курсах в кращому випадку, в гіршому — різну копіпасту, яку потім не можуть прокоментувати.
— Домашні тестові завдання: друзі допомогають чи ще хтось, а на співбесіді виявляється що кандидат взагалі хз як воно працює
— Лайв кодінг (а тим більше кодінг на дошці чи папірці): це далеко від реального процесу роботи, кандидати стресують, а інтерв’ювери схильні інтерпретувати все дуже суб’єктивно.
Детальна глибока розмова про реалізацію набагато цінніша за все це.
Якщо людина добре розуміє як вирішувати задачу, то не важливо чи пам’ятає вона назви методів, параметрів і т.д.
З практичного ще працює код-рев’ю (або аналог): показуєш кандидату код / тест-кейс / баг репорт / інтерфейс, і людина коментує що на її думку варто зробити інакше.

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

Up to you, как говорится. На моей памяти не было прецедентов, когда кто-то говорил «сделайте тестовое, а мы вам больше зарплату дадим» :) Все-таки зарплата и тестовое идут отдельно, хотите запрашивать оплату тестового — это ваше право, так же как и за компанией остается право принимать или не принимать это условие. Я могу сказать за себя, мне не принципиально важно увидеть, как кандидат решает именно мою задачу, мне важно увидеть, как он умеет делать свою работу.

«Известность» и «брендовость» — это ведь не имеет отношения к работе тестировщика, его эффективности.

Безусловно, но может показать уровень компетентности.

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

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

Підписатись на коментарі