твиттерэда
2.21K subscribers
280 photos
66 videos
96 links
Я Эд, ментор по тестированию.
Помогаю ребятам без опыта начать с нуля и выйти на стабильный доход в IT.
Записаться на обучение и попасть в коммьюнити с 400+ учеников: @edzi_qa
Download Telegram
Отчет за 1 квартал 2025


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

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

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

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

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

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

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

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

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

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

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

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

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

Очень честный, глубокий и местами трогательный выпуск про то, как выбираться из задницы, не сдаваться и учиться жить по своим правилам. Приятного просмотра!
🔥51👍159😈1
Как я тестирую внешнюю интеграцию на примере 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'ов. Теперь любое несоответствие быстро видно.


ТВИТТЕРЕДА ПОДПИСАТЬ
/ ПРОДОЛЖЕНИЕ В КОММЕНАТРИЯХ
👍18🔥1510
Какой фон лучше?
🔥21🥰87👍1😁1
Вы спрашивали – я отвечаю!

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

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

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

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

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

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

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

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

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

У меня однажды спросили: насколько сильно мнение моей второй половинки влияет на выбор компании.
Компанию я в итоге скипнул. А вопрос — до сих пор помню.
39🔥237👍2😈1
Пост - личный инсайт

Привет.

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

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

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

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

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

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

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

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

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

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

Потому что я не хочу превращаться в человека, который сидит на панели метрик и теряет вкус к собственному делу. Деньги, масштаб и узнаваемость – хорошие цели, но они не должны похоронить чувство, что ты делаешь что-то по-настоящему нужное конкретным людям. Я верю, что сила в отношениях. Когда исчезает отношение, остаётся пустая оболочка, даже если оборот внушительный.
191🔥32👍72😈11
Вчера вот такое сообщение прилетело, когда мы искали места работы для учеников. И это не шутка. Это реально кто-то считает нормальной моделью «стартапа».


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

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

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


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


А на канале у Андрея вышла статья "Зачем аналитику думать как тестировщик"!
🔥19951
В 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 дня праздников, так что обязательно посмотрите 💙. В интернете вы не найдете ничего подобного, поэтому с вас 🔥.
🔥3786😈11
Екатерина, ну ептвоюмать, ну соберись! Никто не запрещает работать на отъебись, но не на столько же (с)
😁84🔥1511
KPI-гейминг или инструмент фиксации эффективности?

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

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

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

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

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

Всё это можно было бы избежать, если бы не гонка за метрикой количества багов.

Метрика количества багов после релиза:
Здесь я, наоборот, согласен: эта метрика действительно говорит о качестве продукта. Главное — смотреть не только на количество, но и на критичность.


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

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

А как у вас реализованы метрики? Поделитесь, очень интересно!

пысы: так же есть прекрасная статья о метриках: https://habr.com/ru/articles/771070/
🔥38955
Ну….ээээ…пук…на менторство записывайся
1😁589🔥1
вот такие отзывы, одни из лучших что я получаю
105🔥25👍151🥰1
Однажды Хемингуэй участвовал в конкурсе самых коротких грустных рассказов. Он проиграл тестировщику с рассказом "2,5 года реального опыта. Работаю за 60к"
😁5512
Forwarded from QA lab 🪲
Выбирая работодателя постарайтесь найти такого, чтобы мыслил как девочки с Патриков. Хотя бы в вопросе сколько должен зарабатывать мужчина.
30😁25😈2
Ну что, с днем рождения меня, эх жаль не юбилей!
🥰9440🔥29