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

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

Мне нравится выражение «рынок труда». Оно значит ровно то, что значит. Каждый из нас буквально продает свои навыки и умения. Более опытные и известные рынку могут обойтись скромным прилавком (например, «Пишу на 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 написание статей и проведение докладов поддерживается и финансируется.

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

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

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

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