О QA за гаражами

ТОП-5 рекомендаций по составлению резюме

За почти 20 лет работы мне довелось отсмотреть несколько тысяч резюме. Ниже поделюсь советами/рекомендациями на тему их составления с учетом потребностей нанимающих менеджеров.

1. Резюме должно быть честным (спасибо, кэп!). Очень жаль потраченного времени на собеседовании, когда понимаешь, что написанное в нём откровенное вранье или попытка выдачи стекла за алмазы. Нанимающие менеджеры не дураки и выкупают такое на раз-два. Пишите как есть, чтобы не краснеть и не чувствовать себя неловко, когда Вас просят раскрыть тот или иной пункт в резюме подробнее.
2. Краткость – сестра тала… Для многих этот факт будет удивительным, но зачастую на вычитку резюме у опытного нанимающего менеджера уходит 1-2 минуты, а потому если Ваше резюме представляет из себя талмуд в 4 томах, то из него просто сложнее будет вытащить «самую мякотку» и Ваше УТП.
3. Сделал vs. Делал. Многим известно выражение «делал много, сделал ничего», такого не должно быть в резюме (ну или по минимуму). Работодателю важно увидеть реализованные проекты и завершенные задачи, результаты Вашей работы. А потому на своих консультациях касательно описания места работы часто рекомендую придерживаться конструкции «зона ответственности + результаты».
4. Факты и цифры. Внедрили новый инструмент или процесс – отлично! А как Вы измерили изменение результата? Добавляйте в резюме побольше фактуры, желательно в цифрах. Это касается не только результатов, но и зон ответственности, так как с помощью фактов и цифр Вы сможете лучше передать контекст решаемых задач. Ведь одно дело, внедрить что-то новое в масштабе микро-команды уровня «Я и друг мой Вася» и совсем иное – проделать аналогичную работу в коллективе, например, 100+ человек.
5. Консистентность. Информация в Вашем резюме должна соответствовать самой себе. Занимались автоматизацией тестирования -> в результатах должны быть факты и цифры об этом, а в инструментах указан тех.стэк. Руководили проектом -> в результатах факты и цифры об этом, в инструментах/компетенциях соответствующее ПО и востребованные знания/навыки. Выстроили пайплан найма и онбординга -> факты и цифры для контекста и в результатах, в инструментах и навыках… ну вы поняли.

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

#резюмекандидата

О чем Вы хотели бы, но побоялись спросить ментора?

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

- Ревью резюме и компетенций, для правильного позиционирования на рынке

- Создание и ревью ИПР, помощь в определении ближайших шагов по развитию

- Ревью по стратегии QA, помощь в корректуре планов по ее реализации

- Прокачка управленческих компетенций (от найма и онбординга до целеполагания, делегирования и обратной связи)

- Подбор и проведение собеседований, оценки существующей команды QA

- Аудит и консультирование по существующим процессам QA, помощь с их корректурой

Безусловно, практически все рекомендации носят адресный характер, так как сильно зависят от контекстов конкретных менти/компаний. Тем не менее есть и общие моменты, которые актуальны в широком спектре кейсов. А так как у меня нет задачи взять к себе всех менти мира, сакрализировав собственные знания за ширмой paywall’а, то хочу предложить своим читателям небольшой опрос, на тему того о каких темах вам было бы интересно почитать сильнее прочих.

Опрос ниже, следующим постом.

Комментарии под постом с предложениями альтернативных тем приветствуются.

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

Выступил на XII конференции «Стачка» в Санкт-Петербурге. Делал небольшую историческую ретроспективу (слайды по ссылке, видео будет позже) в стиле недавнего поста.

Рассказывал о том, как менялись за последние десятилетия такие аспекты нашей профессии:

- отношение к качеству
- специалисты и требования к ним
- методологии работы
- процессы
- инструменты и автоматизация

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

Использование ИИ войдет в такую же обыденность, как и написание автотестов. Рынком продолжат править спрос и предложение, но расширенная после COVID’a география несмотря на глобальные контексты продолжит сильно влиять на ожидания/возможности специалистов и компаний. Специфика бизнеса и доменные знания будут расти в цене вслед за растущим трендом востребованности продуктовой вовлеченности экспертов. Новое дыхание получит базовое образование в тех областях знаний, где этого будут требовать сами продукты (импланты, интернет вещей, виртуальная и дополненная реальность, автопилоты, продукты на больших данных и с использованием ИИ).

Предлагаю продолжить дискуссию в комментариях. А каким вы видите будущее отрасли?

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

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

🎤 На следующей неделе пройдет интересное мероприятие для тех, кто, интересуется темой публичных выступлений!

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

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

😎 Менеджер, как инженер 🤖

Рано или поздно многие инженеры сталкиваются с необходимостью/возможностью стать управленцем. Часто такая трансформация достаточно болезненна и протекает с трудностями. Ведь с одной стороны становясь на менеджерские рельсы мы начинаем стремительно деградировать в вопросах, где еще буквально вчера, будучи специалистами, были экспертами, с другой стороны объем новых знаний и требуемых компетенций для роли руководителя решительно отличается и требует снова сесть за парту и учиться, учиться, учиться. Здорово, если рядом есть заботливый руководитель или ментор, который направит. За годы работы я, например, обучил и менторил несколько десятков начинающих руководителей. Если перед вами стоит похожая задачка, смело пишите в личку, помогу и поделюсь знаниями.

🤔Но как еще можно облегчить себе жизнь в вопросе становления руководителем?

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

⁉️Регламенты и инструкции. Для чего они?

Порой они кажутся избыточными, от них веет бюрократической скукой и унынием. Но давайте представим, что люди, это микросервисы, которые общаются между собой по различным протоколам. В мире ПО очевидно, что протоколы взаимодействия должны быть определены в соответствии с решаемыми задачами, а в идеале программные интерфейсы нуждаются в минимальной спецификации, которой сервисы буду соответствовать для бесперебойного общения между собой и клиентами. В этом же смысл регламентов и инструкций, они позволяют стандартизировать взаимодействие между людьми-сервисами или определяют принципы их функционирования. Так написание багрепорта по соответствующему шаблону упростит и стандартизирует взаимодействие между QA и разработчиком в вопросах совместной работы над дефектами, а правильное заполнение необходимых полей упростит последующий сбор статистики по работе сервисов-людей и их анализ менеджеру. Регламент написания и выполнения тест-кейсов или code style для автотестов будут являться задокументированными требованиями к работе людей-сервисов, которые обеспечат их прозрачную и корректную работу, в том числе совместную. Точно также, как документация по API в условном swagger’e поможет корректно общаться приложениям на уровне сервер-сервер/сервер-клиент, документация по взаимодействию между коллегами поможет улучшить их совместную работу.

💬В следующих статьях рассмотрим другие примеры из инженерной плоскости, применение которых возможно и полезно и при работе с людьми. А пока пишите в комментариях, делитесь своими наблюдениями по этой теме. Какие еще подходы к работе с ПО вы могли бы/хотели применить или уже применяете при работе с людьми?

Кто ты воин?

Интересная мысль пришла недавно в голову в поисках ответа на извечный вопрос «Кто ты, воин?» (Senior, middle, junior).

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

👶Junior - личное отношение.
Сотрудник выполняет работу и погружен в продукт на уровне личного восприятия, то есть смотрит на то, насколько новый функционал или исправление ошибок улучшит жизнь лично ему (сделает продукт лучше, приятнее, понятнее, расширит его возможности и прочее). Например, ставит баги, исходя из формальных требований и личных акцентов в работе с продуктом.

🤓Middle - клиентский опыт.
На данном уровне участник команды работая над фичей или фиксом багов на регулярной основе делает оценку личного/командного вклада и влияния на конечных пользователей, анализируя продуктовые метрики и руководствуясь ими при принятии решений. Как пример, внимательнее относится к выставлению severity/priority дефектов и лоббирует их исправление в соответствии с ценностью в рамках пользовательских сценариев.

😎Senior - бизнес.
Апофеозом продуктовой вовлеченности становится момент, когда работник выполняя поставленные задачи ориентируется не только на результаты для пользователей, но и для бизнеса. Иллюстрацией к такому подходу может быть поиск баланса в треугольнике деньги/качество/сроки или наблюдение за трендом показателей бизнесовых метрик, таких как, например, выручка, в процессе или по результатам работы.

Безусловно данный маркер не является единственным, однако, при этом он достаточно репрезентативен. А самое главное, если принимать его во внимание, то становится чуть понятнее как развивать у сотрудника ту самую пресловутую продуктовую вовлеченность и «синьорность мышления». Также становится очевидным необходимость прозрачной трансляции соответствующих метрик и умение ими оперировать. Например, мы в Одноклассниках на еженедельных синках команды регулярно рассказываем не только о фактически проделанной работе в режиме «что было сделано?», но и делимся влиянием запусков новых фич/исправлений багов на пользователей и бизнес, которое наблюдаем по результатам анализа продуктовых и бизнес метрик.

💬Пишите в комментариях, согласны ли вы с наблюдением, и на что еще обращаете внимание при определении уровня вовлеченности в продукт?

На прошедшем недавно CodeFest выступал с докладом, по мотивам которого выпустил статью на Хабре по теме совместной работы над обеспечением качества в рамках деятельности всей команды, от Product Owner'a и разработчика до QA-инженера. Прошу любить и жаловать.

Доклад/статья вряд ли произведут вау-впечатление на бывалых QA, а вот для PO и разработки могут дать немало полезных подсветов на тему того, как их работа может помочь делу обеспечения качества! А потому смело делитесь статью со своими коллегами:)

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

По мотивам недавнего выступления на SQA Days про матрицы компетенций и ИПР на их основе на Хабре вышла моя статья "С самого начала выбираем какую-то тактику и придерживаемся ее: говорим об индивидуальных планах развития". Делитесь в комментах здесь/на Хабре впечатлениями и своими лайфхаками по самообучению и развитию сотрудников в своих коллективах.

Ностальгии псто (это ссылка, клик/тап для перехода к лонгриду) или рассказ о том, как за последние 20 лет развивалось QA и менялся скоуп инструментов, задач и подходов.

Делитесь в комментариях своими наблюдениями и контрастами того, как поменялась индустрия с момента, как Вы начали работать в сфере ИТ и по сегодняшнии дни. А если Вы новичок, то расскажите о своих ожиданиях от ближайшего будущего нашей сферы.

Тестирование? И так сойдёт..

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

Мне вспоминается случай, когда в одной из компаний, где ранее работал, так без тестирования закатили небольшую фичу на пару строчек кода таск, который решили не тестировать. Итог был закономерен – баг в проде, в виде пары сотен тысяч пустых сущностей с поздравлениями пользователя с днем рождения (название было, а вот тело сущности было пустым, в общем классическое «С ДР кароч!»).

На разборе инцидента стало понятно, что если бы было проведено тестирование, то баг до прода бы не добрался. Разработчик сделал фикс и отдал на тестирование. Время было позднее, коллег на рабочих местах не было, тестирование, даже будучи уже директором по качеству, проводил я сам вместе с разработчиком.

Правочный скрипт должен был найти все неоткрытые пустые сущности и удалить их, чтобы снизить аффект от бага на пользователей. Фикс осложнялся тем, что его проблематично было проверить на тестовом стенде. И нужно было тестить на живом. До его запуска решили посмотреть код фикса на perl. Один неудобный вопрос от «а что будет если в этом if’е передать в переменную Null?” избавил нас тогда от нового бага - был риск удалить все неоткрытые сущности, title которых был на английском языке, а таких было не мало (тот самый кейс, когда в if’е передавался бы Null).

Ошибку поправили до запуска скрипта. Пользователи были спасены. С тех пор у разработчика больше не возникало вопросов о необходимости и важности тестирования:)

А как Вы склоняли коллег к проведению тестирования?;) Делитесь в комментариях своими историями.

В конце мая, 25-26 числа, в Новосибирске будет проходить одна из крупнейших ИТ-конференций в РФ - CodeFest, где буду выступать с докладом о лучших практиках обеспечения качества стараниями всей команды - от продакта до разработки.

Конференция традиционно собирает экспертов из самых разных направлений в области ИТ, а потому скучно точно не будет!

А чем это он там занимается этот ваш QA-менеджер?

Традиционно принято считать, что менеджеры в принципе либо "ничем" не занимаются, либо занимаются «очень важными» делами. Немного уже раскрывал эту тему в одном из предыдущих своих постов, но а если серьезно, из чего состоят будни и каковы зоны ответственности QA-менеджера?

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

Я выделил 5 основных сегментов:

⁃ Управление качеством (стандарты, требования, методы и виды контроля качества, процедуры для повышения качества, регламенты, шаблоны, покрытие, критерии, метрики…)
⁃ Управление процессами (планирование, дежурства, релизы, инциденты…)
⁃ Управление технологиями (инструменты, стэк, тестовые окружения, тестовый парк…)
⁃ Управление командой (найм, онбординг, обучение, делегирование, решение конфликтов, ФОТ, кадровые решения…)
⁃ Управление коммуникациями (внутри руководимой группы, внутри компании, за пределами компании)

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

Вам по-прежнему кажется, что менеджеры ничем не занимаются?;)

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

Уже скоро, 26-27 апреля в Санкт-Петербурге состоится конференция в области обеспечения качества – SQA Days. В рамках которой я выступлю с докладом об индивидуальных планах развития на базе матрицы компетенций. Приходите на конференцию и мой доклад, будет бодро и увлекательно✊🏻🔥

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

🔥 Это база с 1800 вопросами с собеседований на Тестировщика. Фишка в том, что просчитана вероятность с которой вопрос буден задан и есть примеры ответов. Теперь можно легко получить оффер, подготовившись к самым популярным вопросам 😏

В конце мая буду выступать в Новосибирске на CodeFest с докладом о том, что за обеспечение качества ответственна вся команда, а не только QA. Расскажу на примере процессов реализованных у нас в Одноклассниках как сообща мы строим качественный продукт.

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

Приходите или смотрите онлайн, будет интересно;)

В апреле месяце буду выступать на SQA Days с темой об индивидуальных планах развития на базе матрицы компетенций. Тема довольно актуальная и востребованная, особенно на фоне возросшей конкуренции на ИТ-рынке и потребности в квалифицированных специалистах в области обеспечения качества. Приходите на конференцию или залетайте в личку за консультацией, буду рад подсобить с построением ИПР для вас или вашей команды. К слову, мой метод применим не только к QA.

А есть ли у Вас свой собственный план развития, а у вашей команды? Придерживатесь ли Вы его? Делитесь в комментариях своими подходами, практиками и опытом по теме.

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

А как цели и их достижения помогают Вам?

Продолжение рубрики #моикниги.

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

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

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

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

Ключевым открытиями и вдохновляющими на дальнейшее изучение темами в этой книге я бы отметил:
-> мозг - механизм
-> свобода выбора - это удобная иллюзия
-> самоанализ - основа личности
-> развитие дивергентного мышления - must have
-> мысль - внутреннее действие
-> тело, которое хочет многого - счастливое
-> стараться быть «лучше всех» не только утопия, но и вредно, так как останавливает в развитии, ведь учимся мы у лучших
-> ретроспективный анализ продуктивнее предварительного
-> осознанность - способность видеть/ощущать новое в себе
…

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

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

Однозначно рекомендую к прочтению!

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

С сегодняшнего дня могу официально считать QA делом своей жизни. Мне исполняется 38 лет, 19 из которых я посвятил тестированию и обеспечению качества программного обеспечения.

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

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

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

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

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

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

А вы умеете признавать свои ошибки, и работать над ними? Цените ли те победы, которых достигаете исправляя ситуацию?

#моиошибки