Qa automation engineer как повысить свою зарплату

Как QA-инженеру получить зарплату выше рынка? Высняем у Head of QA

Что нужно, чтобы ваше резюме читали внимательно, а не по диагонали? Какие вопросы будут на интервью и о чём стоит спросить работодателя? Как вести переговоры о зарплате? Про подготовку к собеседованию Алексей Петров, Head of QA Сбермаркета, рассказал у нас на вебинаре очень подробно. Все основные рекомендации — в статье!

Каким должно быть резюме

На чтение одного резюме у интервьюера в среднем уходит 1–1,5 минуты, лист смотрят по диагонали. Если эти атрибуты выполнены, резюме прочитают чуть внимательнее. Чтобы «продать» себя, есть одна минута: поэтому важно подчеркнуть самые интересные случаи из опыта.

• Объём не более 1,5 страниц. Это то, что бросается в глаза сразу: резюме должно быть лаконичным. Многие стремятся к «Повести временных лет» и описывают опыт в десятках или сотнях строчек. Старайтесь делать выжимку самого важного: больше 3 листов интервьюер не читает, лучше всего — одна страница или полторы.
• Описаны результаты. Здорово, когда резюме структурировано по принципу «зона ответственности + достижения». Не просто «участвовал в тестировании», а написано, за что сотрудник отвечал, что с него спрашивали. В работе любого специалиста есть достижения: знаковые релизы, выпущенные фичи, карьерный рост — это очень важно, надо указывать.
• Опыт и инструменты соответствуют. Например, если человек занимался мобильным тестированием — упомянут инструментарий, характерный для мобильного тестирования. Например, Fiddler, Charles, Android Studio, Xcode. Если тестировал бэкенд — Insomnia, Postman, что-то такое. Возникает вопрос, насколько поверхностно специалист знаком с работой, когда есть только опыт без инструментов, и наоборот — если инструменты выглядят, как ключевые слова без реального опыта применения. Например, указан Zabbix, а инженер всю жизнь занимался клиентским тестированием — наверное, он очень мало работал с Zabbix.

Каким бывает стандартное интервью

Пользуюсь этим рецептом, когда сам собеседую кандидатов.

• Сначала — представляю компанию, описываю процессы, рассказываю про команду и ожидания от будущего коллеги. Сразу скажу, в этой части люблю оставлять «ловушки»: о чём-то сознательно не рассказываю, чтобы на этапе вопросов от кандидата ему было, о чём спросить, а мне — можно было углубиться в подробности.
• Дальше — очередь кандидата: его опыт, контекст применения инструментов, методик. Как часто они в компании релизили, что делали, зачем, почему. На этом этапе меньше интересует рассказ про продукты. Иногда люди уходят в дебри, говорят про тонкости реализации архитектуры их приложений. Это здорово, но самое важное для меня — инструменты, подходы, решения различных кейсов.
• Следующий этап —собственно решение кейсов. У меня есть своё собрание вопросов, которые использую для разных профилей: для мобильных тестировщиков одни, для специалистов по бэкенду — другие, для кроссфункциональных тестировщиков — третьи.
• Завершает обязательный этап с вопросами от кандидата. Есть такое понятие как инвертированное собеседование. Это для меня, как интервьюера, круче всего: когда создается впечатление, что не ты собеседуешь, а тебя — задают вопросы. Как устроен процесс разработки, что с CI/CD, как у вас автотесты, а какой фреймворк, зачем, почему… В этот момент понимаешь, что специалист вовлечён и ему не всё равно, а еще понимаешь, что его волнует. И для себя делаешь пометки: например, кандидат больше смотрит вширь. Очень важно, чтобы человек задавал вопросы, которые помогали бы ему подстраховаться от ошибок, которые он совершил на прошлом месте. Если рассказывают про уход из прошлой компании и на собеседовании не «подкладывают себе соломки» под ту же причину — для меня это тревожный звонок.
• Под конец —оргвопросы. Зарплатные ожидания: всегда прошу озвучить кандидатов минимум, исходя из базовых потребностей — дети, семья, ипотека. И максимум: если у человека есть адекватная профессиональная оценка собственных навыков, компетенций по рынку — это здорово. По возможности я стараюсь прямо давать кандидатам обратную связь, чтобы у них было понимание, как всё прошло. Хотелось бы, чтобы собеседования проходили в таком свободном формате — это позволяет расстаться на позитивной ноте, даже если конкретно сейчас кандидат на место не подходит. У меня много примеров, когда с кандидатами расстались по причине «сейчас не время», и спустя какой-то период мы с ними работаем.

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

Самый популярный кейс на интервью

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

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

Наверное, теперь придётся исключить из собеседований этот вопрос, но приведу пример. Форма авторизации: логин-пароль, всё просто. Логин по маске либо телефон, либо имейл, пароль имеет какое-то ограничение.

Большинство кандидатов начинают перебирать комбинаторные варианты: введу много пробелов, ещё что-то такое. А для пользователя важны другие кейсы: при существующем аккаунте, пускай при корректной связке логин-пароль (имейл+пароль, номер телефона+пароль) пускает, по несуществующей связке — не пускает. Дробить тут можно бесконечно. Почему-то забывают про кейс с восстановлением пароля. По старому тебя не должно пускать, а по новому — должно. Именно по таким кейсам можно посмотреть, как кандидат владеет техниками тест-дизайна, может ли он от них абстрагироваться и думать о продукте не как о наборе кнопочек и формочек, а как о пользовательском сценарии, с которым сталкивается самый обычный пользователь.

В тестировании безусловно играет роль и product vision. Сейчас есть такая модная штука: shift-left testing. Тестирование подключается как можно раньше, включается в процедуру планирования, проработки требований. Такой подход всё популярнее во многих крупных компаниях, и разумеется, что QA-инженер понимает, какое есть продуктовое видение.

Пусть в бэклоге заложено 15–20 задач: зачем мы их делаем, какую пользу приносим пользователю — в зависимости от этого строятся кейсы. Например, хотим повысить ретеншн у мобильного приложения. Значит всё, что связано с реактивирующими пушами — для нас в высоком приоритете. Поэтому они должны работать идеально, как часы: приходить ровно, таргетировать человека в то место, куда должны, и так далее. Безусловно, QA должен понимать, зачем и как это происходит.

Есть альтернативный подход: shift-right testing. QA-инженер не начинает работу, когда тикет приходит в состоянии ready for test — подключается раньше, и не бросает её, когда тикет перешел в tested. Инженер помогает зарелизиться, помогает сопровождать в продакшене.

Речь и про регрессионные тесты, которые в будущем повторяются и говорят о том, что данный функционал не деградировал. Речь и про продуктовые метрики. Нередко, глядя на них, можно сделать предположение, что что-то пошло не так: смотрим на тот же DAU, а он резко просел после последнего релиза. Может, по техническим метрикам мы это не уловили, на регрессах проблемы нет, но всё равно это сигнал разобраться, что пошло не так, что повлияло на эти события. Плюс не надо забывать А/В-тестирование, feature toggling и так далее. Многие компании выпускают фичи на часть аудитории, QA вместе с продуктовыми аналитиками оценивают, оправдывает ли фича возложенные на неё надежды, если да — занимаются раскаткой дальше. QA не должны бросать фичу, протестировал — не значит, что работа закончена.

Что спрашивать интервьюеров на собеседовании

Позволю себе отойти в сторону: 50-60% кандидатов фейлится на вопросе про свой самый большой провал. Очень многие комплексуют признаваться в неудачах. Ощущение, что они начитались книг про успешный успех и думают, будто все истории построены на череде исключительно успешных кейсов. Это не так: не ошибается только тот, кто ничего не делает.

Я призываю всех искренне и прямо рассказывать о собственных неудачах. Не пытаться увиливать, спихивать ответственность на коллег, обстоятельства, фазы луны. Если человек хорошо рассказывает про собственные фейлы, например, как проанализировал их с помощью техники «Пять почему» или Диаграммы Исикавы, разобрался в причинах ошибок и устранил их, что сделал для того, чтобы проблема не повторялась — это очень подкупает. Если вам задают такой вопрос — будьте искренними, это ключ к успеху.

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

Спрашивайте то, что максимально релевантно функциональной нагрузке в будущей компании: как будет проходить испытательный срок, какие будут задачи, как понять, прошли ли вы испытательный срок или нет, есть ли kpi. Можно сразу задать встречный вопрос о негативных аспектах в работе в компании, о факапах — это актуальный вопрос для обеих сторон. Я предельно искренне рассказываю, если есть проблемы, неотлаженный процесс или мало автоматизации — прямо говорю и не преследую цели любыми способами заманить к себе специалиста. Люди ошибаются, и в компании тоже есть ошибки.

Soft skills для QA: 3 качества, которые стоит прокачивать

Центральный навык — самообучаемость. Часто кандидат рассказывает, как хочет погрузиться в специфику мобильного тестирования или автоматизацию, хочет стать тимлидом — а злой и коварный работодатель не даёт ему это сделать. Поэтому он ищет работу, где сможет себя проявить, и ждёт, что его, как в «Волшебнике из страны Оз», возьмут за ручку и по дороге из желтого кирпича поведут в мир новых знаний и компетенций.

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

Второе: важно, чтобы человек излучал уверенность. Иногда встречаешь кандидатов, просишь рассказать, какие http-методы он знает. Неуверенным голосом он говорит: «get, post, кажется, patch, put… delete… options…». Спрашиваешь, в чём отличия get и post, а в ответ: «ну, я не уверен… по-моему, один получает, другой создаёт объект, или что-то такое…». Если видно, что человек выдаёт правильные ответы на собеседовании, но делает это очень неуверенно — в реальной работе его съедят.

Модная концепция, набирающая обороты в продуктовых командах: есть закреплённый тестировщик, и он единственный и самый компетентный QA в команде. Если на планировании он будет точно так же говорить: «ой, ну не знаю, может, не стоить брать, я могу не успеть» — это не прокатит. Человек должен излучать уверенность: такая черта характера не позволит проскочить багам на уровне «и так сойдет». QA должен убедить коллег, привести аргументы, что так делать не стоит.

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

А отсюда — и инициативность. Нужно её прокачивать, не бояться выражать мнение, подсвечивать проблемы. Может, попросить добавить новый статус? А может, начать делать код-ревью? Сопротивление и легкая конструктивная оппозиция. Для всего этого, безусловно, должна быть инициативность.И всё равно — на одних софт скиллах далеко не уедешь, под ними должна быть техническая подложка. Опытный интервьюер быстро смекнёт, если человек умеет только рассуждать.

Зарплата по грейдам

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

Джуны — от 20 тыс. до 100 тыс. рублей. Найти работу с большой зарплатой сложно, одними курсами не обойдёшься, но устроиться можно. К тому же сильно зависит от региона.

У миддлов зарплаты тоже отличаются в зависимости от региона, компании, в каком секторе она работает. Финтех обычно платит больше всего — область специфичная. Для миддла — от 70–80 тыс. до 150–160 тыс. Тут ещё вопрос, кто какой уровень считает миддлом — в моём представлении, это сформировавшийся QA, который представляет, куда развиваться, чувствует почву под ногами, понимает, что хочет, может ответить на «пять почему».

Сеньоры: нижняя граница — от 100–120 тыс. рублей. Я видел ребят-сеньоров, не лидовых, кто на своей позиции получает 300 тысяч. Это даже не зарубежные компании, такие зарплаты существуют внутри российского рынка. Единственное, нужно отдавать отчёт, что если сфера — криптовалютный блокчейн и подобное, есть риск, что в понедельник вы проснётесь, а тимлид написал: извини, работы больше нет, зарплаты нет, ноутбук можешь оставить себе. Как ни печально, такие истории я слышал.

Тимлиды получают от 140 тыс. до 300 тыс., для хэдов я видел вакансии до 500 тысяч рублей. Все цифры называю с учётом налогов.

Как торговаться о зарплате

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

Лайфхак — давать вилку с небольшой «горкой», так, чтобы даже отступив от верхней планки, держать марку. Нормальная техника, если назвал: от 100 до 150, а по факту устроит и 130, к такому можно прибегать.

Ещё два пункта: честность, даже в таких базовых вещах, как назвать свой текущий уровень дохода. И аргументация — по опыту, если было 100 тыс., а хочу 150 тыс., но есть действительно понятные аргументы, та же ипотека — такой подход намного лучше сработает.

Важно быть честным, если вопрос финансов — определяющий. Неприятные ощущения остаются от беседы с человеком, который всё собеседование бьёт себя пяткой в грудь, говорит про развитие и интерес к продукту, желание работать в продуктовой команде, а потом называет цифру в 140 тыс., при текущей 95 тыс. Про таких невольно думаешь: и рыбку съесть, и косточкой не подавиться.

Здорово, если деньги становятся не самоцелью, а дополнительной наградой, плюс хочется соразмерности. Безусловно, ни для кого не секрет, что переход в другую компанию сопряжен с ростом з/п. Но если это не выпячивается — то вызывает симпатию. И, честно скажу, бывали случаи, когда я давал сверх ожиданий, как дополнительный мотиватор. В тех случаях я понимал, что человек стоит больше, к тому же эта история с Даннингом-Крюгером: часть людей себя недооценивает. Им важно показать, что они классные специалисты, в том числе в финансовом эквиваленте. Поэтому если у меня есть возможность и есть бюджет, я захеджирую свои собственные риски: что через полгода-год, почувствовав уверенность в себе, специалист не пойдет смотреть рынок. Дам ему хорошие деньги — и он будет работать не один год.

Где и как готовиться к интервью

У меня и моих бывших коллег есть несколько статей типа «как подготовиться к собеседованию на тестирование бэкенда» или «какие есть требования/ожидания от QA». Они актуальные, очень рекомендую.

Есть пара ссылок про инвертированное собеседование: какие вопросы задавать и зачем. Это архиважно: когда перед тобой сидит кандидат, и на вопрос о компании или продукте не знает, что ответить — выглядит не очень. И наоборот, на моём опыте был человек, который погуглил наши статьи на Хабре, почитал, что пишут СМИ, установил продукт, сделал тестовый заказ, записал несколько баг-репортов, сопроводительное письмо — это подкупает.

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

Подготовка к собеседованию

• Собеседование для собеседующих (Хабр)
• Погружение в Charles Proxy (Хабр)
• Образ современного тестировщика. Что нужно знать и уметь (Хабр)
• Что должен знать тестировщик бэкенда (Хабр)
• Обратное собеседование (Github)

«Зарплата QA может быть выше, чем у разработчика»: блогер-эксперт по тестированию о мифах IT и пользе LinkedIn

Герой нашего нового интервью — Олекса Мащиц — в прошлом музыкант и общественный деятель, теперь — прокачанный QA с 12 годами опыта и блогер-эксперт, имеющий аудиторию в LinkedIn более 11 тысяч. А еще – ментор, работающий над созданием собственной школы для тестировщиков.

Детям из Мариуполя нужно 120 ноутбуков для обучения — подари старое «железо», пусть оно работает на будущее Украины

Он ломает любые стереотипы и мифы, существующие в обществе про IT. К примеру, гуманитариям в разработку всегда горит «зеленый свет», а вот заходить в программирование через QA – это плохая идея. Кроме того, Олекса рассказал, как LinkedIn помогает айтишникам зарабатывать даже без постоянного ведения экспертного блога.

Передаем слово герою.

Гуманитарий в IT

Не скажу, что всегда мечтал быть программистом или тестировщиком – так сложились обстоятельства. Я находился в финансовом кризисе, как и многие новички. Но в отличие от современных свитчеров, не имеющих бэкграунда в IT, он у меня был . В конце 90-х я учился программированию в специализированном лицее, затем изучал компьютерные системы в Харьковском политехническом институте, прошел ряд профессиональных онлайн-курсов и 2,5 года обучения на курсе «Компьютерная графика и дизайн». Поэтому у меня за плечами был значительный багаж знаний и практика в нескольких языках программирования, и мне было очень легко свичнуться.

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

Курс Стратегический маркетинг.

Від хаосу до системного маркетингу разом із Тетяною Лукинюк, B2C-директором у Kyivstar, колишнім CMO у Coca-Cola, Mars Ukraine та генеральною директоркою у Red Bull Ukraine.

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

Считается, что IT – это для технарей. Можно ли сказать, что у меня гуманитарный склад ума? Да. Но в то же время у меня есть техническое образование. Возможно, его не хватает, и склад ума не столь техничен, чтобы стать классным разработчиком, писать код и чтобы это было в кайф и легко. Но его гораздо больше, чем у других гуманитариев.

Нельзя делить людей ровно пополам — это гуманитарии и им в IT нельзя, а то — технари. Все люди разные.

А еще — IT очень разное. Здесь есть HR, рекрутинг, сорсинг, бизнес-анализ, проджект-менеджмент и куча других нетехнических специальностей. Ты даже можешь быть бухгалтером в IT и у тебя будут совсем другие условия работы, чем в любой другой сфере. Это большая отрасль, где можно найти себя, главное — копать глубже и понять, что тебе будет близким.

Не заходите из QA в IT

Есть мнение, что QA – это «низшая каста» в IT. Так обычно думают люди, у которых нет технического образования программиста. Это свитчеры, которые по многим причинам не могут и не хотят понять, что такое IT. Им требуется самый простой вариант для входа в индустрию. А что проще? Тестирование. Потому что если бы шли только за деньгами, все учились бы на девопсов. Но не делают этого, потому что понимают, что не смогут. Потому что слишком сложно.

Вернемся к тестировщикам. Какое-то время был дефицит QA – было открыто много вакансий, требования к специалистам были низкими. Те времена давно прошли , но миф, что тестирование – это легко, до сих пор живет.

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

Если ты попадаешь на них, у тебя два пути. Первый — ты должен развиваться дальше, потому что на самом деле ты еще не тестировщик. Ты учишься, практикуешься, но ты еще не специалист. У тебя самая низкая зарплата, она тебя не удовлетворяет. Тогда ты хочешь большего, учишься дальше, добросовестно работаешь и становишься классным специалистом с высоким доходом.

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

Курс Python basic.

Після курсу ви зможете впевнено працювати з чатботами, скриптами, вбудованими системами, веб- та мобільними застосунками, а також навіть ігровими програмами.

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

Часто профессию QA используют в качестве плацдарма для входа в IT, чтобы затем пойти в менеджмент или разработку. Я думаю, что это неправильно. Люди просто тратят время. Это разные специальности, опыт тестировщика для разработчика почти нерелевантный. То же касается менеджмента. Единственный вариант — когда ты очень спешишь, у тебя есть возможность запрыгнуть прямо сейчас, ты хочешь потрогать айтишку как будущий менеджер и посмотреть, как работают команды изнутри. И все же я не сторонник такого. Если хочешь в разработку или менеджмент, иди сразу туда.

Как тестировщику зарабатывать больше разработчиков

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

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

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

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

Linkedin – мастхев для айтишников

Linkedin – это профессиональная сеть, и она имеет гораздо больше пользователей и компаний, чем можно себе представить. Вы просто откройте статистику! Сеть большая, профессиональная, и там есть компании со множеством направлений. Для IT это мастхев, потому что там уникальная информация. Если ты хочешь развиваться как специалист в IT, тебе необходимо им пользоваться. Ты можешь просто читать пассивно, как 90% пользователей, а можешь писать посты.

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

Ведение Linkedin имеет преимущества, которые мы можем разделить на два аспекта:

Курс Микросервисная архитектура.

програма, яка допоможе опанувати головні принципи розробки мікросервісної архітектури, щоби ви могли проєктувати незалежні сервіси, а потім інтегрувати їх в одну систему. Практики буде багато.

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

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

Монетизации нет, финансовая польза — есть

У Linkedin нет монетизации. Если YouTube создан для того, чтобы люди массово потребляли контент (весь подряд), а ты мог зарабатывать, то Linkedin – это профессиональная сеть. Если ты хочешь ее профессионально использовать, ты будешь платить немалые деньги . Очень дорого стоит премиум-подписка, где есть отдельные аккаунты для рекрутинга, бизнеса — они дают хорошие инструменты для поиска потенциальных клиентов.

Linkedin – это доступ к аудитории, где ты можешь сказать: «Я ищу работу». И быстро ее находишь. Или говоришь, что у тебя много профессионального опыта, и ты хочешь консультировать за деньги, и желающие напишут тебе. Прямой монетизации на Linkedin не существует, но финансовая выгода для айтишника будет точно.

Особенность этой соцсети: если твое сообщение интересно сообществу, оно будет иметь просмотры. Несмотря на твое количество подписчиков.

Если у меня 11 тысяч подписчиков, это не означает, что каждый пост имеет охват в 11 тысяч. Если это сообщение не «ОК», сообществу оно не интересно, его могут показать до тысячи раз. А человек, только зашедший в Linkedin, имеет 50 контактов и написал интересное сообщение, может получить охват в десятки тысяч легко. Соцсеть это позволяет.

Как эффективно собирать и удерживать аудиторию

Есть два типа популярных постов:

• Чисто профессиональные , которые информируют и учат. Если вы пишете что-то очень интересное, что касается вашей отрасли, все будет хорошо.
• Эмоциональные . Здесь алгоритмы бессильны, но если тема актуальна для читателей, он тоже может залететь. Есть такие темы: война, политика, поиск работы, например, сейчас можно увидеть кучу челленджей «я ищу работу за месяц». Но здесь нужно быть осторожным: добавляйте эмоциональный контент очень ограниченно.

Олекса Мащиц, фото из архива героя

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

Есть в этой соцсети еще одна фишка: здесь можно без огласки подать объявление, что ты ищешь работу. Бывает, что люди начинают писать сообщения, в которых прослеживается недовольство текущей работой – рекрутеры это чувствуют и делают предложения, даже если у вас нет соответствующего статуса. К сожалению, у нас не развита культура поиска работы, и часто специалисты исподтишка ищут новое место, чтобы не было проблем со стороны текущей компании (давление или увольнение). Молча искать новую работу — это нормально , главное — чтобы вы выполняли свои контракты и отрабатывали, сколько необходимо. Это этично, зачем вам рисковать.

Собственный опыт

Я завел Linkedin в начале карьеры, где-то 12 лет назад. Но не всегда был активен. Из-за того, что соцсеть профессиональная, резко взлететь не так легко.

Если вы хотите, чтобы вас зафоловили десятки тысяч, готовьтесь системно работать годами – для Linkedin это нормально.

Вы не сможете так раскрутиться, дать рекламу, как в ТіkТоk или Facebook. Здесь важна ваша репутация. Как вы все построите, так и будет.

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

Где брал идеи для контента столько лет? Преимущественно я наблюдаю за тем, когда есть “вспышка” — просто могу что-то делать, о чем-то читать, и тогда приходит мысль «а это интересно». Либо возникает вопрос к сообществу, либо я хочу поделиться своим взглядом на какое-нибудь событие. Когда вы почувствуете, что вас что-то эмоционально вывело из равновесия, то записывайте тему. Это оно.

Еще одна разновидность контента — какое-то классное экспертное мнение: пусть оно не мое, но я увидел такую ​​штуку и хочу ею поделиться. Кроме того, иногда возникают вопросы, которые вы не можете решить – для этого на Linkedin есть опрос. Обычно они имеют большой охват. Еще можно тянуть компетентного эксперта, чтобы он помог решить проблему. Представители профессиональных IT-компаний отвечают достаточно активно. Репутация у Linkedin очень важна, компании это понимают. Они не могут вас игнорировать .

Сколько времени тратить на ведение соцсети вы решаете индивидуально. Можете отнестись к этому профессиональнее: разработать контент-план, делать красиво оформленные сообщения в одном стиле, а можете вести соцсеть менее системно. Касательно меня , иногда я за пять минут быстренько делаю сообщение с телефона. Иногда делаю что-то более глобальное: сижу и пишу длинное сообщение, добавляю полезные ссылки, думаю над изображением, чтобы оно несло определенную мысль – это занимает много времени. То есть работаю над блогом от нуля (когда ничего не происходит) до нескольких часов в день. Ведь нужно еще смотреть и комментировать сообщения других специалистов.

Потребность учить

Скажу банальную штуку, но жизненную: у меня с детства было желание помогать людям. Есть такие психотипы. Свою потребность я реализовал во время работы общественной организации, где занимался развитием общин, затем в Linkedin – я передавал свои знания, проводил персональные консультации. Когда есть много профессионального опыта, у тебя есть определенная экспертность, логично, что у тебя могут возникать мысли, как приносить сообществу больше пользы.

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

Сейчас я работаю над созданием собственной школы для QA – The Matrix Space – курс еще разрабатывается. Она не будет большой, но я вижу определенный запрос относительно образования. Как обычно происходит обучение? «Мы хотим все как можно скорее» . Это возможно, когда ты даешь знания в форме небольших навыков. Но это не дает глубочайшего системного образования. Есть много примеров, когда у молодого сотрудника есть конкретные навыки, но есть большие проблемы в конкретной работе. Потому что человек не понял, что это как строится, на чем работает, что такое тестирование. Студенты учат термины, на этом все. Я же вижу школу как более системную историю, дающую верное мировоззрение специалисту-тестировщику. Чтобы он имел базу, на которой все строится, а потом уже мог сам эффективно учиться.

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

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

Курс UI/UX для геймдеву.

Під час навчання ви розробите проекти для портфоліо, що складається з 5 ключових аспектів UX/UI-дизайну, та отримаєш необхідні навички для професійного росту.

Я работаю QA-инженером и получаю 178 000 ₽ в месяц

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

Случайно после окончания универа (2020) наткнулась на специальность тестировщика ПО и решила попробовать. За несколько месяцев выучилась самостоятельно, тк денег на курсы у вчерашней студентки не было. Использовала статьи, ютуб, платформу краудтестинга.

Опыта не было, искала работу месяц, на сотню-другую откликов было 5 собесов, в январе 2021 получила 2 оффера. В одном был 6-часовой рабочий день и 38к на руки, в другом полный день и 65 после испыталки, 50 во время. Формат — строго в офисе. Выбрала второе.

Суть профессии

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

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

Место работы

Работаю около полугода в крупной компании, у которой есть айти-направление. Я маленький руководитель, в моей команде 2 QA и я ищу третьего.

Рабочий день

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

Скачиваю приложение на тестовый телефон, открываю требования и начинаю проверять на соответствие ТЗ. Если нахожу расхождения — завожу задачу на исправление. Разработчик должен ее взять в ближайшее время, переделать и снова отдать мне приложение.

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

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

Подработки

Зарплаты более чем хватает, тем более при моем затворническом образе жизни. Думаю о том, чтобы начать преподавать русский иностранцам (у меня английский примерно В2-С1), но в связи с последними событиями это призрачная перспектива — непонятно, как получать из-за границы оплату.

Можно ли подрабатывать QA-инженером — не знаю, мне кажется, что найти такое сложно, но можно. С почасовой оплатой.

Доход

Сейчас оклад 178 тысяч на руки. Был еще бонус, с ним получается 195 тысяч на руки.

Такую зарплату мне предложили полгода назад (декабрь 2021), когда у меня даже года опыта работы не набралось (не хватало пары недель). Это очень много для моего опыта тогда, тем более с учетом того, что на момент этого предложения у меня не было никакого опыта с написанием автоматизированных тестов, то есть кода. Тем QA, кто пишет код, платят больше, но даже для таких QA с годом опыта 178 (195) тысяч — достаточно много.

Зарплатой пока довольна. Надеюсь двигаться в сторону повышения благодаря становлению руководителем и развитию умения писать код для автоматизированных тестов где-нибудь в район 220-250к на руки.

Расходы

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

Хочу прыгнуть с парашютом и получить сертификат AFF, на это еще уйдет тысяч 30, давно не смотрела цены.

Финансовая цель

Хочу иметь несколько миллионов на счетах, пока не знаю зачем. Раньше думала взять ипотеку в Москве, когда накоплю на первый взнос, но после событий в Украине решила, что в России оставаться не хочу. Страну для переезда пока не выбирала — рано, все равно сейчас вряд ли смогу найти работу за рубежом, слишком мало опыта. Года через полтора смогу, если интернет не запретят и не сделают айтишников невыездными.

Будущее

Думаю, останусь в QA. Цель — стать каким-нибудь Head of QA с большим штатом в подчинении и получать большую зарплату по меркам той страны, где буду жить.

Варианты развития QA специалиста если вы еще линейный специалист, но уже «у потолка»

Данная статья несет познавательный характер и не несет цели кого либо задеть или оскорбить.

Вступление

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

QA Automation Engineer

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

Кто такие автоматизаторы (QA Automation Engineer). Как правило, это специалисты, которые переводят тестовые сценарии в код для инструментов, которые по этому коду будут тестировать.

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

1. Нужно ли это вашей текущей команде?
   С этим всё просто: спросите у лидера, сформируйте договоренности и идите учиться. В противном случае, готовьтесь менять работу (что, в целом, не плохо, так как часто рост связан с сменой рабочего места).
2. На каком языке вы планируете автоматизировать.
   Тут, во многом, зависит от того, в каком направлении IT вы планируете развиваться, Например в геймдеве, то C# \ плюсы \ C, а в вебе, это Python
3. Определиться с инструментами
   Для геймдев движков существуют свои инструменты, которые прикручиваются в юнити, у не геймдева, это Selenium, JUnit, Cucumber, Selenide и другие.

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

Если вы пришли почитать именно про автоматизацию, то я вам рекомендую эту статью автора digitalsibur который хорошо раскрыл это направление

Performance Engineer

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

Основная цель perfomance-тестов — Определить и исправить причины медленной работы системы. Для этого проводится мониторинг показателей «железа» и софта, хотя порой это делают и DevOps-инженеры.

Как вкатиться? да как всегда. Читаем нужную литературу, наподобие этой и этой, и этой и др.

Практикуемся на текущем месте, и, если нравится, то двигаем дальше на полноценную должность

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

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

Тест-аналитик

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

Что может быть на страже тест-аналитика

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

Основной задачей тест-аналитика является организация максимально эффективного (при существующих ограничениях) тестирования программного продукта и анализ качества этого продукта на основе аналитики и анализа.

Более подробно про тест-аналитиков можно почитать тут: Тест-аналитики – кто это?

QA lead

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

Для того, чтобы стать хорошим лидом, нужно всего четыре вещи:

1. Опыт
2. Знания, если команда не практикует повышение по сроку службы, тогда знания не важны (мы такое не поддерживаем)
3. Соответствующие софты (иногда об этом забывают)
4. Вакантное место

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

Какие основные обязанности лида:

1. Понимать процессы и методологии используемые на проекте (и не только)
2. Развивать в команде всесторонний взгляд на качество
3. Знать и использовать разные практики в своей работе и работе отдела
4. Улучшение процесса при необходимости
5. Управление людьми
6. Настройка прозрачной работы с возможностью ее поддержки

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

QA Аrchitect

Честно говоря, специальность достаточно редкая и в командах приято, закрывать ее силами QA лида, но встречается и отдельная позиция.

Кто же он такой?

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

1. Разработку стратегии тестирования: Определение методологий и подходов к тестированию продукта, включая выбор инструментов и технологий.
2. Проектирование тестовых сценариев: Создание и планирование тест-кейсов и сценариев, которые помогут проверить функциональность и производительность продукта.
3. Анализ и управление рисками: Идентификация потенциальных рисков, связанных с качеством продукта, и разработка стратегий по их снижению.
4. Сотрудничество с командами разработки: Взаимодействие с разработчиками и другими членами команды для обеспечения качества в каждой фазе разработки.
5. Управление инструментами и автоматизацией: Разработка и внедрение автоматизированных процессов тестирования и управления качеством.
6. Обучение и консультирование: Помощь другим членам команды в понимании и соблюдении стандартов и практик качества.

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

Для успешной работы, QA архитектор должен обладать:

1. Экспертным знанием QA и тестирования
2. Уметь в автоматизацию тестирования
3. Владеть знанием программирования: Чем глубже, тем лучше.
4. Архитектурным мышлением
5. Навыком управления рисками
6. Знанием инструментов тестирования
7. Навыками моделирования данных

Application Security Tester

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

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

1. Знание уязвимостей: Глубокое понимание различных видов уязвимостей в безопасности, таких как SQL-инъекции, XSS, CSRF, утечка данных и другие.
2. Программирование: Знание языков программирования и понимание кода приложений, чтобы обнаруживать уязвимости и предлагать их исправления.
3. Понимание архитектуры приложений: Способность анализировать архитектуру приложений и их компоненты с точки зрения безопасности.
4. Тестирование на проникновение: Навыки проведения тестирования на проникновение для выявления уязвимостей и потенциальных слабых мест в приложениях.
5. Знание инструментов безопасности: Умение работать с инструментами для сканирования уязвимостей, анализа безопасности кода и другими инструментами, используемыми в безопасности приложений.
6. Знание принципов шифрования: Понимание методов шифрования и мер безопасности данных.
7. Понимание принципов аутентификации и авторизации: Знание принципов проверки подлинности и установления прав доступа к ресурсам.
8. Базовые знания сетевой безопасности: Понимание принципов сетевой безопасности, включая файрволы, VPN и другие средства защиты.
9. Умение анализировать код: Способность анализировать исходный код приложений на предмет уязвимостей и безопасных практик.
10. Обучение и коммуникация: Хорошие коммуникативные навыки для взаимодействия с разработчиками и другими участниками команды.
11. Безопасные практики разработки: Помощь разработчикам в применении безопасных практик в процессе разработки.
12. Обучение и самообразование: Постоянное обучение и отслеживание новых тенденций и угроз в области кибербезопасности.

Уфф, бывает и такое, но чтобы во всем разобраться подробнее, приглашаю в статью, где подробно раскрываются все особенности работы AST, а мы подходим к концу

Итог

Как мы с вами увидели, Тестирование многогранно и необъятно, так что не попадаем под эффект Даннинга — Крюгера, анализируем, какие навыки нам не обходимы, читаем полезные статьи и книги, и растем профессионально.

Если вы считаете, что я где то был не прав или вам есть, как дополнить статью, то добро пожаловать в комментарии!