Как 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. Можно сразу задать встречный вопрос о негативных аспектах в работе в компании, о факапах — это актуальный вопрос для обеих сторон. Я предельно искренне рассказываю, если есть проблемы, неотлаженный процесс или мало автоматизации — прямо говорю и не преследую цели любыми способами заманить к себе специалиста. Люди ошибаются, и в компании тоже есть ошибки.

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

Всё-таки хочется, чтобы человек был сам заинтересован в собственном обучении. Конечно, работодатели предоставляют возможности для роста внутри компании: конференции, митапы, посещение профильных мероприятий, бюджеты на обучение и прочее. Но важно, чтобы человек сам делал шаги в этом направлении: пет-проект по автоматизации, ссылка на 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)

• Тестовые площадки для тренировок настоящих ниндзя (блог Noveo)
• Can’t Unsee

• Software Testing
• Automated Testing
• Testbase
• Про Тестинг
• Качество и тестирование ПО (Youtube)

• SQA Days
• Heisenbug 2020 Moscow
• TestCon Moscow 2020
• Podlodka

• GeekBrains
• Яндекс.Практикум
• Нетология
• Otus.ru

• QA.Guru
• RFT.QA

• uTest
• TestBirds

• https://t.me/qa_ru
• https://t.me/qa_bad_company
• https://t.me/qaevents
• https://t.me/yetanotherqa
• https://t.me/radioqa

• Тестирование Дот Ком или Пособие по жестокому обращению с багами в интернет-стартапах, Роман Савин
• Тестирование программного обеспечения. Базовый курс
• 5 лучших книг по тестированию ПО от Натальи Руколь
• Книга для начинающих тестировщиков