Уверен так и будет!

Ладно, результатом выебываться мы умеем, но есть и часть работы которая мало мной освещается (честно, хз почему), но внутри коммьюнити проводится колоссальная работа. Изменения в материалах (как доп задания, которые разрабатываются с взаимодействием дизайнера/разработчика), как частые созвоны внутри коммьюнити с приглашенными спикерами (от трудоустроившихся учеников до продакт лида Т-банка и психолога), разборы вопросов с собеседований и сходка на каяках в конце мая. Мы (я говорю Мы - это и команда, и коммьюнити в целом) работаем не просто над поддержанием работающей системы, но и стремимся ее улучшить. Я искренне верю что хороший продукт лучше маркетинга, и пусть я могу ошибаться, пока мой подход работает. Почти 30 человек трудоустроенных за первый квартал со средней зп - 170к


Ахуй? Ахуй

Всем привет! Мы записали ролик с Ромой Омелаенко (да-да, кокосовый QA 🌴) прямо на берегу океана, на Бали. Это не подкаст в студии — это разговор в кайф, с шумом волн и честными темами.

Мы говорим о том:
– как Рома стал ментором и зачем он вообще этим занялся;
– почему нужно 10 сеансов психотерапии, чтобы поверить в себя;
– что такое «кармический долг» и где его граница;
– что сейчас реально происходит на рынке IT;
– как меняется жизнь у учеников — от официанта до айтишника с квартирой;
– и как выбрать, кого менторить, а кого — нет.

Это не интервью и не мотивация в духе «успешного успеха». Серьёзно, смешно, местами философски. Но точно — по-настоящему. Приятного просмотра!

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

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

И начинается само собеседование, я отвечаю на теоретические вопросы какие-то, и в момент нашей милой болтовни тимлид кидает вопрос:

«Как бы ты протестировал кнопку?»

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

В общем, тимлид молчит и потом спокойно говорит:

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

Честно признаюсь, я завис просто пиздец.

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

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

А бывало ли у тебя на собеседовании, что понесло куда-то не туда? Поделись — соберем коллекцию проебов вместе.

Эх, вот бы научится писать прогревочные посты…

Как тестируется интеграция, На примере

Допустим, есть вопрос: "расскажи, пожалуйста, как ты взаимодействуешь с интеграционным тестированием на проекте." Как об этом рассказывать? На что обращать внимание? Как структурно подавать эту информацию? Об этом сейчас подробнее я расскажу. Допустим, я работал на проекте видеоконференции, видеосозвонов и буду рассказывать об этом. Итак, вопрос звучит следующим образом: «Расскажи, пожалуйста, как ты взаимодействуешь с интеграционным тестированием на проекте видеоконференции».

Во‑первых, интеграционное тестирование – это важный этап проверки систем, построенных на нескольких взаимосвязанных модулях или микросервисах. На проекте видеоконференции, где я работаю, система состоит из нескольких ключевых компонентов: это сервис аутентификации, сервис видеостриминга, сервис управления комнатами (room management), чат, уведомления. И всё работает через REST API и WebSocket‑соединения. Каждый из этих компонентов можно успешно тестировать через модульное тестирование, но в реальности всё может сломаться именно на стыке при взаимодействии между модулями. Именно для этого нам и нужно интеграционное тестирование.

Как я подхожу к интеграционному тестированию? Во‑первых, анализирую архитектуру. Перед началом тестирования я изучаю, какие модули участвуют в конкретной бизнес‑функции. Например, чтобы пользователь вошёл в видеоконференцию по ссылке, участвуют Auth, (не авторизация - временный пользователь не авторизуется), Room, Streaming, UI и Notification. То есть я строю для себя схему взаимодействия и поток данных: от нажатия кнопки «Войти» до появления в комнате. Схему держу в голове, отдельно не рисую.

Дальше мы определяем ключевые точки интеграции. Например, вызов Auth API и выдача токена, использование токена для подключения к видеостриму.

Далее идут тест‑кейсы: они пишутся вручную, часто в виде сценариев «end-to-end», но ориентированных на взаимодействие между сервисами. Например, пользователь с валидной ссылкой и токеном успешно подключается и попадает в комнату; пользователь с истёкшим токеном получает ошибку авторизации от стрим‑сервиса и не может войти; после подключения второго участника оба видят друг друга и работает чат; сообщения передаются по WebSocket и отображаются корректно.

Какие инструменты мы используем? Для REST API — Postman: вручную отправляем запросы, подставляю разные параметры, проверяю, как один сервис реагирует на результаты другого. Могу использовать Swagger либо как документацию и описание API, или отправить через Swagger эти запросы. Для WebSocket — эмуляторы или встроенные DevTools, если соединение устанавливается в браузере.

Какой подход к тестированию интеграции? Тут есть два режима: «чистая» комната, когда ещё никого нет и мы первые туда заходим, и «грязная» комната, когда уже есть пользователь, комната создана, чат активен, и мы добавляем нового участника. Важно проверять форматы запросов и ответов, время ответа, устойчивость при сбоях: например, если аутентификация вернула 401, что происходит дальше? Делаю негативные сценарии: токен просрочен, комната удалена, сервис чата недоступен — чтобы проверить, как поведёт себя UI и другие сервисы.

Если возникают баги, мы анализируем логи каждого микросервиса через ELK (Elasticsearch + Kibana). Также могу посмотреть состояние в базе данных: создался ли пользователь, записался ли участник в room_members(столбец в таблице бд) после подключения, появился ли временный пользователь. При записи у нас сохраняется статистика о звонке, и мы можем проверить, отображается ли там наш новый пользователь.

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

ПРОДОЛЖЕНИЕ В КОММЕНАТРИЯХ:

Отчет за 1 квартал 2025


Квартал вроде как закрылся ещё в марте, но у меня апрель пролетел в режиме «отдыхаем‑поддерживаем, не разгоняемся» — отпуск же. Так что отчёт только сейчас. Короче, что наделали, где круто, где лажанули, и чуть‑чуть про ближайшие планы.

Что круто:
Команда расширилась. Четыре куратора, пм в команде - ахуй.

Вернули созвоны со спикерами и разборы собесов. Итог? 28 трудоустроенных с середины января до конца апреля. На нынешнем рынке это ахуенно.

Два пилотных потока уже обкатываются. Первый поток почти готов, люди скоро выходят на рынок. Серёга, Саня — спасибо, вы топ.

Статейный конвейер пашет, на YouTube стартовал курс по тестированию. Коллабов с тестировщиками стало больше (Булгаков, Омелаенко, Пше) — подкаст с Сашей на подходе. Видео по материалам так же в процессе съемок и монтажа, работаем!

Оффлайн. 30 человек на кинопоказе в Питере, 35 — на сходке в Москве. Ахуй? Для меня да! Дальше: каякинг 31 мая—1 июня (сначала Питер, потом будем планировать Москву) и летом летим в Дагестан.

Где можно лучше:
Созвоны и собес‑разборы подустали к концу квартала — возвращаем в привычный темп.

Есть ребята, у кого трудоустройство буксует. Я знаю, работаем точечно.

Что готовлю (без лишних обещаний):
Сокращаем трек обучения без потери мяса: пересобираем домашки, обновляем материалы (то, че делаем пока ни у кого нет), переводим их в индивидуальный формат в Jira. Цель — быстрее выводить ребят на рынок.

Майские созвоны с людьми из смежных направлений — iOS, фронт, product, дизайн. Плюс 27 мая большой разговор с психологом.

Апгрейд материалов + ещё видео. Стараемся сильно не уходить в YouTube, чтобы обучение не просело.

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

Всем привет! В этом долгожданном выпуске, ради съемок которого я прилетел в Дубай, мы встретились с Сашей Пшеборовской — айтишницей и предпринимательницей, которая начинала свой путь с подработок по ночам и дошла до оффера в Deutsche Bank, а потом ушла в свободное плавание. Говорим про путь через страх, выгорание, синдром самозванца и про то, как вывозить, когда кажется, что всё против тебя.

Саша поделилась:
– как жила одна с юных лет и совмещала работу с учёбой;
– что чувствовала, получив первую зарплату в 80к после смен по 900₽;
– как приняла решение уйти из найма;
– как справлялась с английским, работая в команде из индийцев;
– особенностями жизни в Европе, будучи экспатом;
– своим опытом руководства командой;
– и почему даже «подаренные шансы» – это всегда следствие большой работы.

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

Как я тестирую внешнюю интеграцию на примере YooKassa

Давай разберем ситуацию тестирования внешней интеграцию в проекте интернет-магазина — я всегда привожу в пример работу с платёжным шлюзом YooKassa. Это отличный кейс, чтобы показать, как я подхожу к тестированию: системно, но без отрыва от реальных задач и пользователей.

Что вообще такое внешняя интеграция?

Если говорить простыми словами — это когда наш сайт (или приложение) должен взаимодействовать с внешним сервисом, чтобы всё работало. В моём случае — интернет-магазин, и нам нужно было принимать оплату через YooKassa

Интеграция построена на REST API: мы отправляем HTTP-запросы (например, чтобы создать платёж), а YooKassa отвечает, и в нужный момент сама присылает нам уведомление (это и есть webhook — когда сервис сам «стучится» к нам и сообщает, как прошёл платёж).

С чего начинать?

Первым делом читаю документацию от и до — спецификацию YooKassa. Там расписано:

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

Например, чтобы создать платёж, мы отправляем POST-запрос на /v3/payments с суммой, валютой, типом подтверждения (чаще всего redirect — то есть пользователя перекинет на форму YooKassa), ссылкой на возврат и уникальным idempotence_key (он нужен, чтобы два одинаковых запроса случайно не создали два платежа).

Как я рисую схему взаимодействия

Я не сразу лезу писать тест-кейсы или проверять. Сначала в голове (а иногда и на бумаге/миро) строю цепочку:

1. Создание платежа
2. Редирект пользователя на форму YooKassa
3. Оплата (в песочнице — тестовыми картами)
4. Получение webhook (то самое автоматическое уведомление от YooKassa о результате)
5. Если webhook не пришёл — можем вручную запросить статус

Потом под каждый шаг составляю сценарии. Вот базовые:

- Всё прошло успешно, пользователь получил подтверждение.
- Попытка оплаты неудачна (например, карта просрочена).
- Пришёл webhook → мы обновили заказ.
- Webhook не пришёл → сами дернули API и узнали, что с оплатой → мы обновили заказ.

Инструменты и подход

Для ручной работы использую Postman. Сначала создаю платёж и смотрю, что в ответе есть payment_id и confirmation_url. Перехожу по ссылке, ввожу тестовые данные (есть специальные карты от YooKassa для[песочницы.
Дальше руками отправляю webhook (имитирую его через Postman), чтобы проверить, как среагирует наше приложение — обновит ли статус заказа, отправит ли уведомление пользователю и так далее.

А как же ошибки?

Обязательно прохожу и негативные сценарии. Они ничуть не менее важны:

- неправильные данные карты (например, несуществующий номер),
- удалённый заказ (если пользователь оформил, но потом отменил),
- отсутствие обязательного поля (например, забыли amount),
- повторный webhook (не должен создать второй заказ),
- имитация сетевых проблем (например, webhook не дошёл, или платёж не завершился).

Где ищу баги?

Если что-то пошло не так, и платёж не обработался, — иду в Kibana или Grafana, смотрю логи по payment_id, проверяю, пришёл ли webhook, и есть ли нужный статус в базе. Иногда просто смотрю в таблицу заказов напрямую.

Примеры багов и что с ними делать

Баг 1. Изменился формат webhook (после обновления API)
После обновления YooKassa немного изменила структуру webhook-сообщений — поле `status` переехало в другую часть JSON. Наш код этого не «заметил» — и заказы просто не обновлялись.
Почему случилось: мы не следили за обновлениями и пропустили изменение.
Как починил: добавили JSON-схему, сделали проверку формата, написали юнит-тесты на парсинг webhook'ов. Теперь любое несоответствие быстро видно.

ТВИТТЕРЕДА ПОДПИСАТЬ / ПРОДОЛЖЕНИЕ В КОММЕНАТРИЯХ

Вы спрашивали – я отвечаю!

Всем привет! В этом видео я открыто и честно отвечаю на анонимные вопросы подписчиков: и про менторство, и про деньги, и про выгорание, и про обратную сторону работы с учениками. Мы поговорим не только о тестировании, но и о том, что остаётся за кадром — эмоциях, страхах, перегрузах, мотивации и росте.
Что внутри ролика:
– отказываю ли я людям в обучении?
– почему обучение – это не «волшебная таблетка», а процесс;
– как устроено взаимодействие с учениками, если кто-то «тяжёлый» или медленный;
– сколько времени уходит на трудоустройство с желаемой зарплатой;
– менторство: реальный труд или инфоцыганство?
– как справляться с ответственностью, когда учеников становится сотни;
– можно ли обучать других и не работать в индустрии?
– и даже… сколько я зарабатываю!

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

Иногда на собесе ты готовишься обсуждать реальные штуки: чем занимался, какие были задачи, как устроены процессы в компании. А на деле — ловишь пулю из набора классических «HR-вопросов 2010 года»:

— Кем вы видите себя через 5 лет?
— Назовите свои слабые стороны.
— Почему выбрали тестирование? (да, серьёзно, до сих пор спрашивают)
— Что будете делать, если задач не будет?

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

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

Сейчас я к таким вопросам отношусь спокойно.
Хотя раньше, если честно, они меня дико раздражали. Потому что вообще непонятно было — зачем.
Теперь понимаю: собес — это не только про навыки. Это про человека.
Потому что по тому, как ты рассуждаешь, реагируешь, держишься — уже можно многое понять.
Ты либо показываешь, как думаешь, либо начинаешь играть в угадайку «а что бы он хотел услышать».

Ирония в том, что чаще всего берут не тех, кто идеально отвечает, стараясь угодить, а тех, кто остаётся собой.

Ты можешь не знать ответа. Можешь взять паузу, подумать, сказать: «не уверен, но думаю, что так».
Это звучит куда сильнее, чем заученные формулировки из интернета.
Собес — это не экзамен с правильными ответами, а диалог
И даже странные вопросы — это часть диалога. Они не про твои знания, а про твою устойчивость.
Если ты держишь фокус, не теряешь себя и не начинаешь играть роль — ты уже выделяешься.
Всё остальное — детали.
Это та мысль, которую я стараюсь донести до своих учеников.
Как только человек перестаёт воспринимать собеседование как экзамен — он начинает дышать.
Он не боится, не спешит с ответом, переспрашивает, если что-то непонятно.
Не паникует, если вопрос странный, а остаётся собой — внутри предложенной игры.

А какие странные вопросы были у вас?

У меня однажды спросили: насколько сильно мнение моей второй половинки влияет на выбор компании.
Компанию я в итоге скипнул. А вопрос — до сих пор помню.

Пост - личный инсайт

Привет.

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

Первая. Менторство изначально задумывалось как противоположность школам. Оно должно было быть гибкой, «ручной» историей — живым диалогом вместо лекционного конвейера. В какой-то момент сами менторы начали превращаться в школы: фиксированные наборы, воронки, менеджеры, KPI. Я не осуждаю этот путь, понимаю его логику, но ощущаю, что он чужд моему первоначальному импульсу. Если наставничество становитcя копией того, против чего задумывалось, – теряется сама ценность идеи.

Вторая. Чтобы масштабироваться и экономить ресурс, нужно становиться менеджером и строить онлайн-школу. А для меня всё это, как ни странно, не просто бизнес. Да, я зарабатываю, у меня есть команда; есть финансы и привычные таблички в Notion. Но моя внутренняя мотивация не в графиках роста. Она в том, чтобы видеть, как конкретный человек, с которым я говорю, делает ещё один шаг вперёд. Когда формат превращается в «поток», я перестаю чувствовать этот контакт: начинает работать система, а я оказываюсь на вторых ролях, в роли администратора собственного же проекта. И вот тут возникает дискомфорт – ощущение, что я подменяю живую связь схемой.

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

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

Что будет вместо потоков?

1. Личное менторство сохранится. Без жёстких дат «старта» – беру ровно столько людей, во сколько способен включиться сам. Да, это медленнее, да, меньше денег на единицу времени, но я ясно чувствую результат и не теряю интерес.

2. Поддержка новых менторов. Я вижу, что рынок ручного тестирования растёт, спрос на наставников есть. Готов делиться своим опытом с теми, в ком вижу потенциал, – помогать методически, делиться материалами, подсвечивать «подводные камни». Но это будет не курс «Стань ментором за 30 дней». Скорее индивидуальное сопровождение, где мы обсуждаем реальные кейсы, а не рисуем идеальную воронку.

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

Зачем всё это?

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

Вчера вот такое сообщение прилетело, когда мы искали места работы для учеников. И это не шутка. Это реально кто-то считает нормальной моделью «стартапа».


«Само собой платить не буду» — это вообще что за позиция? Если вы строите продукт, но не можете позволить себе даже символическую оплату тем, кто делает работу — у вас не стартап, у вас хобби, за счёт чужого труда. Я всегда думаю о том, а стал бы ли я сам делать ту или иную работу без платы?
«Ребята без опыта» — это не оправдание. Даже если у человека ноль коммерческого опыта, он тратит время, силы и мозги. При этом он может быть куда более прокачан в навыках чем человек который действительно работал. И особенно если вы хотите 24/7 — вы уже ждёте результат. Значит, вы признаёте, что это работа. Значит, платить надо. Если сомневаетесь - берите на оплачиваемую неделю и смотрите результат, потом решайте.
«Готовы учиться» — звучит красиво. Но в такой постановке это не обучение, это эксплуатация. Учиться можно под наставничеством, с фидбеком, с ростом. Можно ли это сделать на проекте где нет людей ответственных за тестирование? Не думаю.
Меня не раздражает факт существования неоплачиваемых стажировок сам по себе (хотя это безусловно бесполезная трата времени со стороны кандидата). Иногда это действительно трамплин. Но когда это подаётся как норма — «само собой» — вот тут и начинается злоупотребление. И нет, это не «рынок». Это тупо неуважение к чужому времени и труду, и не нужно его нормализовывать.

Зачем QA-инженеру думать как аналитик

Когда тестировщик подключается к задаче только после того, как всё уже сформулировали, согласовали и отладили, он получает в руки готовый результат, который далеко не всегда совпадает с изначальной идеей. В такой позиции ты ловишь последствия решения, но пропускаешь момент, когда стоило задать принципиальный вопрос: “А нужно ли вообще делать эту фичу именно так?” Вместо того чтобы влиять на исход, остаётся только фиксировать баги и оформлять баг-репорты— и фиксить там, где можно было избежать ошибок.
Аналитическое мышление в тестировании — это способность работать не с формальной поверхностью задачи, а с её основой. Это не про то, чтобы лезть в чужую зону ответственности, а про то, чтобы понимать, какие решения лежат за формулировкой требований, что на самом деле хочет решить бизнес и где в пользовательском пути возможны искажения. Такой подход позволяет не просто находить ошибки, а замечать слабые места ещё до того, как они успели проявиться. И в этом состоянии ты не «перестраховываешься», а участвуешь в создании продукта наравне с другими, потому что видишь его логику, а не только результат. Это и отличает qa инженера от манки тестера.

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

Так что такой «расширенный подход» не усложняет твою роль, а делает её ценнее. Вместо исполнителя ты становишься соавтором продукта, человеком, чьё мнение учитывают до релиза, а не после. И именно этот переход от фиксации к пониманию превращает QA-инженера в надёжную точку опоры команды и гарантом того, что продукт движется в верном направлении.


А на канале у Андрея вышла статья "Зачем аналитику думать как тестировщик"!

В QA можно так зарабатывать, ОКАК!

Я писал в одном из постов о том, как QA-инженеру получать больше денег, и менторство — это один из таких вариантов. Это не самый простой, но 100% развивающий путь.

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

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

Менторство сейчас на хайпе, все больше людей берут менторов и обращаются за помощью в трудоустройстве.

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

Таймкоды:

00:44 — Опыт работы Эда до менторства
02:19 — Что такое галеры, и есть ли плюсы?
07:45 — Продукт vs Аутсорс: плюсы и минусы
11:35 — Почему ушел из найма?
12:32 — Чем круто быть QA и чем нравится работа?
19:33 — Кто виноват в факапах: QA или вся команда?
20:00 — Тенденции рынка труда: автоматизация или фуллстек, что тренд?
25:00 — Почему ученики выбирают ментора, а не курсы?
29:00 — Сколько человек устроил на работу за последний месяц? И какие офферы?
31:00 — Сколько идет обучение до трудоустройства с ментором?
32:40 — Говорим про автофильтры и резюме
35:35 — Как все успевать?
38:50 — Многоработничество: плюсы/минусы/подводные камни!
41:52 — Как строится работа с ментором и отличие от курсов
45:00 — Говорим про деньги, считаем, что выгоднее: курсы или ментор
47:54 — А сколько людей не доходит до оффера?
56:29 — Сколько зарабатывает Эд и другие менторы?
58:57 — Внутренняя кухня менторства
1:05:20 — Обсуждаем курсы
1:08:35 — Топ навыков QA, необходимых на рынке прямо сейчас
1:09:12 — Как выбрать ментора и не быть обманутым?
1:15:00 — Стажировки или накрутка?
1:20:00 — Как сохранить ментальное здоровье после накрутки и многоработничества?

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

Екатерина, ну ептвоюмать, ну соберись! Никто не запрещает работать на отъебись, но не на столько же (с)