Заметки о QA

🎄Новогодние советы 2.0🎄

Я очень люблю подводить черту: составлять достижения, писать списки, подготовить итоги. Листая свой телеграм-канал, я попала на новогодние советы. И захотелось повторить небольшие советы-размышления и в этом году!

Про баги
- За баг нет одного ответственного - это часть общих усилий и ошибок. Аналитик не прописал требование, разработчик не добавил это в код, тестировщик пропустил при проверках. Не обвиняй только себя, лучше постарайся сделать вывод и не повторять ошибок.
- Баги на проде - это часть работы тестировщика, а не наша смерть. Когда мне говорят, что не пропускали на прод серьезный баг, то у меня есть три объяснения: ты единорог, в твоем продукте нет пользователя или ты еще не нашел этот пропущенный баг. Баг пропускали все, это часть рабочего процесса.

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

Про планирование и время
- Намечай свой карьерный путь. План помогает упростить движение к цели, а отсутствие плана заставляет прыгать с места на место и терять время на вещи, которые тебе не интересны. Не поленись и подумай, что ты хочешь от работы. Это позволит тебе быстрее вырасти.
- Научись оценивать свое рабочее время. В этом году я плотно подсела на toggl track (наконец!). Сейчас я четко могу сказать, чем я занимаюсь, сколько я этим занимаюсь и прогнозировать сколько еще я буду этим заниматься. Рекомендую!
- Не переживай, если не понял с первого/второго/десятого раза. Все знания, которые ты получаешь, смогут помочь тебе в будущем, даже если кажется, что это не так. И ты обязательно когда-нибудь поймешь! Дай мозгу сделать свою работу.
- Очень часто стоит потратить время на то, что ты откладываешь. Например, наконец научиться запускать автотесты через консоль, а не руками. Или написать свод правил для работы. Кажется, что это не сильно ускорит работу, но практика показывает, что ускорение/упрощение/изменение рутины приводит к повышению эффективности.
- Критерии приемки - это круто! Тут добавить нечего.

И пусть каждая ошибка приносит вам опыт, а не боль. С наступающим 💫

Как рассказать о себе на собеседовании?

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

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

1. Имя, должность и количество лет в профессии.
2. Рассказ о последнем месте работы.
- продукт
- состав команды
- занимаемая роль
- обязанности
- соотношение автоматизации/мануального тестирования, web/mobile/desktop
3. Стек инструментов.
4. Рабочие процессы.
- методология разработки на проекте
- события команды (рабочие созвоны по типу дейли, груммингов, планирования)
- степень влияния на продукт
- участие в ревью документации
- этап создания продукта, на котором начинаешь тестирование
- участие во вне командных активностях компании
5. Зоны ответственности в команде/компании.
- проведение релиза
- онбординг
- внедрение продуктов
- проведение собеседований
- особые достижения, на которые хочется обратить внимание
6. Подчеркнуть релевантный опыт для компании.

Дополнительно можно рассказать о том, что ты ищешь в новой работе и почему хочешь сменить текущее место.

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

Полезный материал
1. Youtube-видео Самопрезентация учит нас доносить идеи

(план в виде картинки)

Советы для автоматизации [2]
Первую часть советов можно почитать тут, также рекомендую полезные советы по инструментам для программирующих на Java.

- Автоматизация тестирования - это инструмент для достижения цели, а не сама цель.
Часто, когда работаешь full-stack QA, легко увлечься автоматизацией и улучшением кода, забывая о главном — обеспечении качества функционала.
Поэтому хочется напомнить, что автоматизировать нужно для того, чтобы это приносило пользу бизнесу и помогало улучшить качество продукта, а не просто для того, чтобы писать код.

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

Мои любимые сочетания клавиш (macOS, IntelliJ IDEA):
cmd + click (либо b) - отображение, где метод/класс/прочее используется в коде
double shift - быстрый переход к классу/функции
option + cmd + l - форматирование кода (сделать по всему классу правильные отступы)
cmd + w - закрытие вкладки
control + options + o - удаление неиспользуемых импортов (также рекомендую включить автоматическое удаление таких импортов)
shift + options + click - курсор на несколько строк
cmd + d - дублирование строки без ее выделения и копирования
(буду рада увидеть ваши любимые горячие клавиши в комментариях)

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

- Разрабатывайте тестовые сценарии, учитывая реальных пользователей API.
Покрывать тесты и придумывать варианты использования - это хорошо. Но иногда эффективнее заглянуть к тем, кто использует бэкенд. Например, фронтенд.
Изучите, какие данные отправляются, какие запросы участвуют в работе и как происходит обработка ответа. Есть ли вариации, которые не описаны в ваших автотестах? Ведь именно реальные пользователи бэкенда находят баги, а не тесты в вакууме.

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

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

See you soon

#автоматизация #java #советы

Полезное про Selenoid

Selenoid - инструмент, который позволит вам запускать ваши UI или Anrdoid автотесты параллельно и изолированно в Docker-контейнерах. Рекомендую для первоначального ознакомления обзорный гайд по Selenoid

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

Варианты запуска Selenoid

1️⃣Скачать подготовленный образ с помощью curl или через браузер из официального github
Инструкцию для запуска образа можно почитать в документации либо рекомендую статья для windows.
Для macOS мне подошла вот эта статья (это medium, поэтому запуск через VPN)

2️⃣Самостоятельно создать docker образ (либо docker-compose), файл конфигурации браузеров (browser.json) и запустить сборку контейнеров через консоль.
Самостоятельное создание позволит гибко подойти к образу, необходимым вам браузерам и их настройкам
Примеры для самостоятельного создания
- Минимальный пример написания docker compose и browser.json
- Пример docker compose + browser.json и описание работы
- Настройка Selenoid для запуска UI-тестов на Android

Функции, которые понравились мне

➖Selenoid UI: инструмент для визуального отображения работы с Selenoid. Позволяет просматривать результаты тестов и прочую информацию, а также подключаться к тестам в режиме реального времени*
для этого необходимо включить опцию VNC в capabilities
➖ Доступ к видеозаписям прогонов
В инструменте есть возможность записи видео прохождения автотестов.
Мне кажется, что это очень удобная функция для добавления видео в баг-репорт.
В процессе работы я столкнулась с проблемой того, что видео прогона не записывалось. Что помогло мне:
- настроить файл docker-compose.yml: указать пути к папкам, где будут сохраняться видеозаписи, и прописать соответствующие команды в command
- создать папки для дублирования видео из docker в файлы
- настроить capabilities* в автотестах, которые можно подсмотреть на соответствующей вкладке в Selenoid UI
* Capabilities определяют возможности браузера во время тестирования
Также для кастомизации запуска видео рекомендую статью про Extensions (Java)

Прочие рекомендации
Более подробный пример работы с Selenoid (Java)

Подборка каналов про тестирование

В начале этого года я делилась с вами подборкой tg-каналов про тестирование.

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

Сегодня я рада представить вам обновлённую версию этой подборки!
Готовы погрузиться в мир тестирования? Тогда жмите на ссылку ниже и начинайте исследовать! 🌐

https://t.me/addlist/PNmSaWa9ktw2YjRi

Чем могут быть полезны Extensions в JUnit5

Extensions - список интерфейсов, которые появились в JUnit5. Они расширяют работу с жизненным циклом в автотестах.

Чем поможет
Сделает работу с автотестами гибкими.
Например, раньше мы могли работать в рамках автотеста только с Before и After. Благодаря extensions вы можете значительно повлиять на работу автотестов, сравните хотя бы количество этапов в жизненном цикле (картинка по ЖЦ автотеста в junit5).
Теперь легко повесить общую аннотацию @Something на класс автотестов, внутри которой будет реализация полноценной настройки окружения. Это позволит не дописывать в каждом новом классе велосипед, настраивающий окружение.

Примеры использования интерфейсов
- ExcisionCondition: может создать условие для запуска теста. Например, вы хотите запускать тесты только на ОС = Windows. Мы создаем реализацию класса и особенности запуска, добавляем его к классу и вуаля, ваш тест имеет особенности запуска.
- ParameterResolver: позволяет предоставить параметры для автотестов. Например, у вас специфический тип в параметрах, и вам нужно гибко его передавать, а стандартной работы JUnit5 вам не хватает.
- TestWatcher позволяет сделать что-то при падении или запуске теста. Он следит за тестами и ходом их выполнения.
(полная документация всех интерфейсов в extension)
В рамках extension мне очень нравится такой класс как ExecutionContext, который позволяет получить доступ к данным о тесте, его местонахождении, параметрам запускам и всем-всем, связанным с тестом.

Что почитать/посмотреть
Я познакомилась с Extensions благодаря выступлениям Дмитрия Тучс, которые рекомендую и вам:
- Дополнительная открытая лекция с продвинутого курса по Java, где я впервые услышала про extensions
- JUnit, дай пять! Переносим код в JUnit 5 Extensions
- Доклад The art of JUnit extensions с Heisenbug и The art of JUnit extensions 2

Прочие полезные материалы:
Статья про практическое применение Extensions (kotlin)
Полное руководство по расширениям JUnit 5 (java)
Практическое применение Extensions с канала Oleh Pendrak
Руководство по расширениям JUnit 5

#junit #автоматизация

(обязательный мем к посту)

Про правильное формулирование, мета-вопросы и решение проблем путем редких ответов

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

Например, сегодня ко мне пришли с запросом "Не могу найти документ в системе, помоги".
Я полезла в базу данных и логи двух микросервисов, чтобы проследить путь документа и обнаружила, что документ доставлен до системы.
После проведенного исследования и предоставления ссылки на документ, я получила ответ: "Да, ссылка на документ у меня есть. Но вот в другую систему он не направился, а еще в статусе ошибки подписи".
Тут возникает вопрос: значит коллега знал, что документ дошел до системы, но все равно спросил, где документ? Соответственно вопрос в поиске документа не стоял, а запрос оказался в другом: почему подпись не отработала. Из чего следует, что путь документа нам не нужно было отслеживать и я зря потратила на это свое время.

Если бы коллега сформулировал вопрос сразу с подробностями, это сэкономило бы мне минимум 10 минут и сохранило бы силы на решение более насущного вопроса, а именно почему в подписи возникли проблемы.

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

Как лучше формулировать вопрос:
- описать, где и когда произошла проблема
- перечислить, какие данные по проблеме собраны
- описать, какие действия уже были проделаны для решения (шаг необходим, чтобы собеседник не предлагал вам уже сделанные действия)
- объяснить, что требуется от человека, чтобы он тебе помог
Перед отправкой перечитайте сообщение и проверьте, нет ли уже ответа на ваш вопрос в нем же.

Примеры
Плохой вопрос:
я не могу понять, как замержить в репозиторий autotest

Хороший вопрос:
Мне нужно замержить новые автотесты в ветку master.
При попытке мержа через консоль у меня возникает ошибка 403.
Я пытался сменить пароль на новый, но это не помогло. Google подсказал, что ошибка может возникать из-за прав доступа к мастеру, но я их не могу посмотреть.
Можешь ли ты объяснить, куда мне сходить для получения прав, или объяснить, что еще можно сделать?

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

Что можно попробовать сделать, если вам задают плохо сформулированные вопросы
Чаще всего причина плохих вопросов в лени их формулирования. В этом может помочь игнорирование вопросы на 30 минут: через пол часа вопрос порой пропадает сам по себе или становится нормально сформулированным с описанием собранных материалов и проделанных шагов.

Мета-вопросы
В связки с формулированием вопросов, я бы порекомендовала вам почитать про мета-вопросы, которые съедают не только ваше время, но и время собеседника.
Пример мета-вопроса простой: когда ты вместо формулирования вопроса, просто пишешь "Тут?" и отвлекаешь собеседника. Подробнее почитайте по ссылке.

Важно помнить, правильно сформулированный вопрос - это уже половина ответа на него.

#softSkills

Блок-схема "Как выбрать язык программирования для автоматизации"

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

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

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

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

Блок-схема в хорошем качестве

Кратко повторю на что ориентироваться при выборе языка:

1. Область, в которой вы хотите автоматизировать (UI для web, desktop, backend, mobile), : при выборе языка также нужно учитывать что вы хотите автоматизировать: для мобильных чаще используется Swift и Kotlin.
2. Язык, используемый на работе мечты: изучить рынок, выбрать компании, которые сильнее всего вас привлекают и выбрать для изучения их язык программирования
3. Востребованность в области и в конкретной компании: например, какие языки чаще мелькают в вакансиях.
4. Простота и популярность (Python проще в освоении с нуля, Java даст отличное понимание ООП, но сложнее для освоения)
5. Язык, базу которого вы уже изучали
6. Знакомые/менторы/разработчики, которые могут помочь

Мой личный путь и поиск карьерного развития

Недавно мне посчастливилось поучаствовать в QA Sis Conf #2, где вместе с другими удивительными девушками я поделилась своим опытом работы в сфере тестирования и поиском путей для развития, которые использовали после года в профессии. Рекомендую к просмотру: QA Sis Conf #2 Год в тестировании - что дальше.

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

Теперь я хочу поделиться этим планом с вами:
📝Составление плана развития

Статья включает в себя три ключевые части: поиск своих сильных сторон, определение зон для развития и выбор конкретных целей для достижения этого развития. Подробнее читайте в источнике🥸
Надеюсь, что план вдохновит вас на поиск будущих целей в вашей карьере!

Практики хорошего кода

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

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

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

В статье Улучшаем код автотестов: популярные практики и их примеры я расскажу про такие подходы, как SOLID, KISS, DRY и YAGNI и на примере автотестов постараюсь показать применение этих принципов. В конце вас ждут полезные материалы, в которые обязательно стоит заглянуть.

#автоматизация

Блок-схема локализации бага: фронт или бэкенд?

Я создала небольшую блок-схему, которая может помочь вам определить источник обнаруженного бага. Вы можете добавить множество дополнительных ветвей. Допустим, если ошибка от бэкенда 5хх, то точно ли она корректно обрабатывается и не нужно ли изменить ее на 4хх, что будет более информативно?

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

(в хорошем качестве блок-схема представлена в следующем сообщении)

UPD общее правило: если ошибка была, а UI ее не вывел и бэк повел себя неправильно, баг и на UI, и на бэк

Логи и их применение в работе

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

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

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

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

Пример работы с логами
У меня возникла ошибка, например, при создании сущности возвращается 500 и сущность не создаётся. Я понимаю, что возникла ошибка, но должна найти причину и локализовать ее.
Я сразу иду в логи и изучаю историю, которая произошла в момент создания: возникла ошибка при сохранении сущности в базу данных: разработчик забыл заполнить обязательное поле, и запись просто не произошла.
При отсутствии логирования процесс локализации занял бы совсем не 5 минут.

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

Полезные материалы
О чём могут рассказать логи: важный инструмент в работе тестировщика
Как тестировщику работать с логами
Уровни логирования как использовать логи
Как снимать логи с устройств на Android и iOS
Инструменты для тренировки: Kibana (программа для удобной работы с логами) и ее функции + статья на habr, а также тренажер для практики в Kibana
UPD: тренажёр временно (надеюсь) отключен, но у вас есть возможность использовать бесплатный пробный период в Kibana, подробнее читайте об в комментариях, либо использовать советы из поста автора тренажера.

#инструменты

Как проводить собеседования🗣
[часть 2]

Подбор вопросов

Важный этап подготовки к собеседования - это выбор вопросов.

От чего я отталкиваюсь, когда составляю вопросы:
- резюме кандидата и его опыт: что он делал и в чем силен
- навыки и знания, необходимые именно для вакансии (в том числе учитывать материал, построенный на прошлом этапе подготовки), рекомендую статью на эту тему
- упор в оценку применения теории на практике
- мое обязательное знание ответа на вопрос, который я задаю!

Где взять базовые вопросы, которые позволят составить ваш идеальный список:
- Популярный список всех вопросов.
- Вопросы про автоматизацию тестирования.
- Вопросы для оценки опыта кандидата.
- Чек-лист тем для собеседования.
- Огромный список вопросов для QA.
- "Анализ 10 000 вопросов с технических интервью: частотность и вероятность встречи".

Подготовка себя как собеседующего

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

Если такой возможности нет, то советую приглядеться к следующим мок-собеседованиям:
- Публичное собеседование QA лида. Алексей Петров, Ольга Артемьева.
- Публичное собеседование: QA Lead.
- Automation QA мок-собеседование.
- Собеседование на микросервисный проект.
- Мок-собеседование Java QA Automation с разбором ответов и материалами
- Собеседование на должность Middle QA Automation.
- Публичное собеседование / мок-интервью для QA-инженера.

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

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

Как проводить собеседования🗣
[часть 1]

Обычно подбор кандидата проводится в несколько этапов:
- встреча с HR
- техническое собеседование (может быть разделено на несколько этапов)
- встреча с командой

Я хочу поговорить именно о техническом собеседовании и как к нему подходить со стороны нанимающего.

Стандартный план технического собеседования QA
(присутствие и отсутствие этапов зависит от вакансии):

1. Знакомство
- вы рассказываете о формате встречи
- кандидат описывает свой прошлый опыт и свои навыки.
2. Вопросы на базу теории тестирования.
3. Технический блок
- специфика тестирования: web/mobile/backend/desktop
- автоматизация тестирования
4. Практический блок
- задачи на теорию тестирования (тест-дизайн, локализация и прочее)
- ситуационные вопросы
- лайв-кодинг
5. Вопросы от кандидата

Для собседования обязательно нужно подготовиться (даже когда ты собеседующий!):
- выстроить процесс (например, построить матрицу компетенций, что вы хотите от кандидата)
- определиться с вопросами
- подготовиться к роли собеседующего

Поговорим о каждом поподробнее

Выстраивание процесса

Для построения хорошего процесса я бы изучила следующий материал

- Лучший дизайн процесса собеседований: объясняет, почему сейчас мы часто строим собеседования неправильно, как лучше выстраивать вопросы, как в этом поможет матрица компетенций и еще куча всего. По мне одно из лучших чтений на эту тему.
- Теория по собеседованиям: какие виды существуют, как подготавливаться, какие вопросы лучше задавать и все в этом направлении.
- Видео “Как проводить собеседования, чтобы было интересно кандидату и не обидно HR”: очень нравится подход, описание и общие шаги.
- Изучить чужой опыт, например, как проходит интервью в Тинькофф

О вопросах и подготовки себя поговорим в следующей части 🔜

как понять, что я норм?

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

а что делать-то (особенно пока я не беру на менторинг хехе)?

учиться авторизовывать результаты работы (и вообще замечать свою работу), формулировать свою ценность и собирать непрямой фидбек.

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

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

ну и не игнорируйте свою работу головой. работа лида во многом — это обдумывание вопросов и принятие решений. отрывайте оценку своей эффективности от работы руками и производимых артефактов.

об остальном поговорим завтра в 18 по мск на вебинаре.

а в целом подход "с тобой всё норм" будет активно использоваться на курсе :)

Сейчас я работаю full-stack QA в продуктовой команде и автоматизирую на Java. Но в будущем я мечтаю стать ✨лидом✨ .
На данный момент мне не полностью понятно, из чего состоит работа, как давать фидбек, оценивать качество своей работы и еще миллион вопросов, на которые я не знала, где найти ответы.

А теперь знаю. Потому что Наталья Петровская (великолепная специалистка, с которой мне повезло работать в качестве менти) создала свой курс про лидство. Подробнее про него и бесплатный вебинар в посте ниже ❤️.