Open Source как возможность для развития QA-инженера

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

Мне кажется, что за последнее время начинающим специалистам становится всё сложнее трудоустроиться.

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

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

Но где здесь практика?

Источник: ProgrammerHumor.io

Некоторые курсы предоставляют возможность выполнять задания. Иногда помогают частные консультации менторов. Иногда люди самостоятельно находят тренировочные задания из области QA и практикуются на них. При этом не факт, что такие задания до сих пор актуальны.

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

От учебных заданий к реальным проектам

Как мне кажется, здесь есть несколько вариантов.

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

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

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

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

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

И наконец, третий, пожалуй, самый сложный вариант — Open Source.

С чего начать в Open Source?

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

И вот тут как раз та самая теория с курсов должна прийти на помощь. Именно здесь она должна соединиться с практикой.

Но с чего начать? Как выбрать проект?

Пожалуй, самым логичным решением будет выбрать какой-то устоявшийся проект, у которого уже есть пользовательская база, история коммитов и звёздочки на GitHub.

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

Возможно, вам нравятся AI-агенты или веб-парсеры. Может быть, вас интересуют приложения с веб-сервером и графическим интерфейсом.

После того как удалось найти что-то понятное и интересное, можно начать с нескольких сторон.

Например, с функциональности: посмотреть, что заявлено, что есть в документации, а чего в ней нет. Это, кстати, тоже своего рода тестирование проекта.

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

Так постепенно появляется систематический подход к анализу Open Source проекта.

Как съесть слона

Комикс Robin Cain — Mindzai Comics

Конечно, всё это может показаться действительно сложным или даже невозможным на первых порах.

И тут мне нравится выражение, что слона надо есть по частям.

Какое-то время уйдёт на то, чтобы просто оценить проект, осмотреть его и свыкнуться с мыслью, что вот он — слон.

И только спустя некоторое время, после того как вы поняли, что это за проект, можно приступать к его декомпозиции.

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

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

От изучения к собственному вкладу

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

Именно с таких моментов можно начать контрибьютить — вносить собственный вклад в Open Source проекты.

Безусловно, никто не обещает, что ваши правки будут приняты и что произойдёт это быстро.

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

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

В целом о подобном опыте можно рассказать как об участии в реальном инженерном проекте, объяснив, с какими задачами вы столкнулись и что именно сделали.

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

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

AI как проводник в Open Source

Всё, что я описал выше, было актуально на протяжении достаточно длительного времени. Open Source существовал задолго до нынешнего развития AI-ассистентов и всегда предоставлял возможность получить реальный инженерный опыт.

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

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

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

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

Конечно, AI не заменит ментора полностью. Его рекомендации необходимо проверять, а предложенные решения — осмыслять. Но иногда даже такой первичной информации может оказаться достаточно, чтобы приблизиться к своей цели.

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

И такой опыт может оказаться неоценимым в дальнейшей профессиональной деятельности. Он позволяет расширить кругозор и сформировать более широкое представление о том, как устроены реальные проекты и работа над ними.

Но главная моя мысль заключается в другом.

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