твиттерэда | QA: резюме, собесы, оффер

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

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

Также под видео есть ссылки на канал моего друга, где он рассказывает и снимает видео про Vibe Coding и использование AI. Очень сильно рекомендую.

Видео на YouTube: https://youtu.be/fa_kg4T9VcQ

Канал друга про AI / vibe coding:
https://t.me/codeonvibes


Предзапись на модуль по AI в работе тестировщика:
https://forms.yandex.ru/cloud/6a4f6755068ff05af4c4ad8d

У нас появился новый метод HTTP, который называется QUERY.

По сути, он как GET, но при этом у него есть body, как у POST-запроса.
Отвечая на логичный вопрос: «А нахуя он вообще нужен?» — я отвечу.
Он нужен для тех ситуаций, когда мы ничего не меняем на сервисе, на сервере, но при этом создаём какой-то сложный поисковый запрос с большим набором фильтров.
В целом, когда мы хотим получить какие-то данные, мы отправляем GET-запрос. Но есть проблема: у него нет тела запроса, и, соответственно, все данные передаются в URL.
Если фильтров много или они сложные, много условий, какие-то вложенные JSON, пагинация, сортировка и так далее, URL становится огромным, нечитаемым и может упереться в лимиты.
Либо он попадает в логи, историю браузера, и, если в фильтрах есть какие-то чувствительные данные, это, соответственно, плохо.

Что же используют вместо GET-запроса?
В таком случае используют POST-запрос. Просто в body складывают все необходимые фильтры. На этом, собственно, всё.
Несмотря на то, что POST в RESTful — это про изменение данных, он использовался как раз-таки для таких запросов.
И наш новый метод, по сути, решает именно эту проблему.
При этом он уже стандартизирован, но на самом деле пока что какого-то массового использования у него нет, потому что он опубликован буквально в прошлом месяце. Сейчас в основном встречаются всякие тестовые реализации.
Я хотел найти и показать вам, как он используется, но мы позже об этом проговорим.
Нам нужно понимать, что GET у нас безопасный и идемпотентный запрос, но параметры у него обычно передаются в URL.
POST может передать нам сложное тело, но это не обязательно безопасная или идемпотентная операция.
А QUERY — это безопасный и идемпотентный запрос с полноценным телом.
Сейчас какой-то реальной поддержки этого запроса нет. Я думаю, что в ближайшем будущем будет. Я здесь солидарен с Валентином Кимом.

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

- Открой любой сайт.
- Нажми F12.
- Перейди в Console.
- Выполни:

fetch("https://httpbin.org/anything", {
  method: "QUERY",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    filters: {
      status: "ACTIVE"
    },
    page: 0,
    size: 20
  })
})
  .then(response => response.json())
  .then(console.log)
  .catch(console.error);

- После этого открой Network, найди anything и посмотри:

Request Method: QUERY

Возможен нюанс: из-за CORS сначала появится запрос OPTIONS, а сам QUERY может быть заблокирован сервером. Это как раз одна из текущих проблем нового метода.

А для POST-запроса с большим количеством фильтров и сортировкой можно сделать следующее:

- Открой:
https://fontawesome.com/search

- Открой DevTools → Network.
- Включи фильтр Fetch/XHR.
- В строке поиска введи, например, user.
- Выбери несколько фильтров: стиль, категорию, бесплатные или платные и так далее.
- Найди запрос, в адресе которого есть:

algolianet.com/1/indexes/*/queries

У него должен быть:
Request Method: POST
При этом запрос только ищет и возвращает иконки. Он не создаёт новую сущность.

Думаю астрологи объявят совсем скоро неделю вопросов про новый запрос, этакая проверка слежки за новостями

прочесть про сам метод: https://www.rfc-editor.org/rfc/rfc10008.html

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

Поговорим не просто про “как тестировать задачу”, а про весь жизненный цикл:

- откуда вообще появляется задача;
- что такое backlog, sprint, grooming;
- как QA подключается к требованиям;
- что происходит до разработки;
- как задача попадает на тестовый стенд;
- что проверяет тестировщик;
- когда заводятся баги;
- зачем нужен ретест;
- как задача попадает в регресс;
- что происходит после релиза;
- зачем делать smoke на проде.

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

Если ты не понимаешь путь задачи, сложно нормально объяснить свой опыт, работу с требованиями, багами, регрессом и релизом.

---

Полезные ссылки

Telegram-канал:
https://t.me/twitereda

Хочешь попасть на обучение / оставить анкету:
https://t.me/edversitybot?start=960452529


СМОТРЕТЬ НА ЮТУБЕ

К предыдущему посту добавлю, что требуют от джунов/стажеров на хх ру сейчас?

Вакансия 1: https://hh.ru/vacancy/134928608?query=junior+qa&hhtmFrom=vacancy_search_list

Вакансия 2: https://hh.ru/vacancy/134492344?query=junior+qa&hhtmFrom=vacancy_search_list

ЧТО QA НУЖНО ОСВОИТЬ В 2026?

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

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

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

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

Первое — растёт доля требований к QA как к технически самостоятельному специалисту.

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

И это касается не только Kafka. Работа с backend, API, базами данных и SQL — это уже какой-то must-have, который необходимо знать любому более-менее сильному специалисту на рынке труда.

Сюда же можно добавить работу с логами, понимание асинхронного взаимодействия, тестирование интеграций на разных уровнях, инфраструктурные знания и понимание CI/CD.

Второе направление — это AI. Искусственный интеллект внедряется практически во все процессы.

Поэтому растёт использование AI как дополнительного инструмента, с которым должен уметь работать человек, в том числе и тестировщик.

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

В целом это согласуется и с публичными обзорами рынка за 2025 год, и с тем, что мы видим сейчас в 2026 году.

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

Но на самом деле здесь важно другое: нужно не бояться этой волны, а научиться её использовать.

AI не заменяет QA. Он заменяет механическую рутину и усиливает тех, кто умеет правильно использовать эти инструменты.

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

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

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

При этом я понимаю, что спрос на автотестирование никуда не исчезает.

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

Поэтому следующим шагом мы запускаем два отдельных направления по автотестированию.

Я искренне верю в то, что искусственный интеллект сейчас намного больше раскрывается именно в рамках работы автотестировщика.

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

Поэтому оставлю ниже три ссылки на заполнение анкет по разным направлениям.

В конце июля мы запускаем наборы:

— автотестирование на TypeScript;
— автотестирование на Python;
— отдельный мини-продукт по использованию искусственного интеллекта в работе QA.

Это будет полезно как начинающим специалистам, так и тем, кто уже работает в тестировании и хочет усилить свои навыки.

RTM, или Requirements Traceability Matrix, — это матрица трассировки требований.

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

В целом, главная идея матрицы трассировки в том, чтобы у команды была понятная картина покрытия требований тестами, чек-листами. Если объяснять совсем по-простому, то test case у нас отвечает на вопрос, как проверить и что проверить. А RTM отвечает на вопрос, что чем покрыто.

Например, у нас есть требование: пользователь должен иметь возможность восстановить пароль через email. В RTM мы можем увидеть, какие проверки относятся к этому требованию, были ли они выполнены, какой у них результат, есть ли по ним какие-то баги, нужно ли что-то retest-ить. Но это в такой расширенной версии(базовая версия на фото выше) — просто какие проверки относятся к этому требованию.

По сути, матрица трассировки помогает ответить на три базовых вопроса.

Первый — что мы уже протестировали. То есть, если требование связано с test case или чек-листом, мы видим, что оно хотя бы формально покрыто проверками.

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

Третий — почему мы тестируем именно это. То есть у каждого теста появляется какое-то обоснование. То есть не просто рандомный набор действий, а видно, почему мы тестируем это: потому что у нас есть такое требование.

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

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

Я вообще рекомендую чек-листы всегда писать, если задача не , где в этом нет необходимости, для того чтобы просто спустя неделю, не дай бог, обнаружится какая-то ошибка, вас спросят: «А что вы там проверяли?», и вы не помните, всегда можно опереться на этот чек-лист. Базовая минимальная структура RTM состоит из строки столбцов, где в строках мы указываем устойчивые ID требований, а в колонках указываем устойчивые ID тест-кейсов. И на их пересечении ставятся либо галочки, что вот это требование покрывается вот этими кейсами, вот это требование покрывается вот этими кейсами.

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

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

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

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

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

Старый подход «сделал резюме и ждешь» больше не работает.

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

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

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

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

Да, нужно понимать, что рынок просто очень сильно изменился.

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

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

«Эд, а у меня плохое резюме?»

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

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

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

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

Но если ты хочешь, чтобы я посмотрел твое резюме, пожалуйста, можешь написать мне в личку @edzi_qa, и посмотрим что можем сделать)

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

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

Для чего задают такой вопрос?

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

Например, ты можешь рассказать, что проверяешь не только статус-коды, но и тело запросов (не смешно! Часто слышал ответ: "смотрю код-ответа" и все), изучаешь логи сервера и базы данных, чтобы понять, где именно произошёл сбой. Или как минимизируешь шаги воспроизведения, чтобы передать разработчику максимально точное описание. Главное — дать понять, что ты не просто репортишь баги, но умеешь докопаться до их сути.

Что делать и как докопаться до сути?

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

Открываем инструменты разработчика в браузере (DevTools). Вкладка Console может показать, не возникает ли ошибок JavaScript. Например, бывает ошибка типа

Uncaught TypeError: Cannot read property 'clickHandler' of undefined

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

Если запрос отправляется, проверяем его содержимое. В Network есть две ключевые вкладки: Payload и Response.

- Payload показывает, что отправил фронт. Например, это может быть запрос с параметрами вроде:

  {
    "name": "Анна Авось Прорвемся"
  }
  

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

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

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

Следующий шаг — анализ базы данных. Проверяем, записалось ли имя в базу. Выполняем SQL-запрос, например:

SELECT * FROM users WHERE name = 'Анна Авось Прорвемся';

Если имя отсутствует, ищем ошибку: возможно, ограничения на данные (например, уникальность) или проблема с соединением базы и сервера.

Если данные в базе есть, но поп-ап не отображается, проблема, скорее всего, в фронтенде. Проверяем, запускается ли скрипт отображения поп-апа. Открываем вкладку Elements в DevTools, ищем элемент поп-апа, возможно, он просто скрыт или наложен другим элементом. Это не всегда работает, и многое зависит от технологий которые используют на проекте. Я лишь описываю шаги для рассуждения:)


продолжение в комментариях⬇️

Знания или практика?

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

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

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

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

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

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

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

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

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

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

Безусловно, можно сказать: "Эд, ну какие это отзывы, это ты сам написал и сейчас рассказываешь нам", поэтому я предлагаю следующее - 100 реакций и делаем созвон с теми, кто прошел обучение и стажировку, и уже работает😉

Сейчас на обучение можно попасть со скидкой по ссылке:
https://t.me/edversitybot?start=960452529

Я словил obsession на идею вкатить вообще ВСЕХ, и на выходных собирал разные источники вакансий, эх щас еще парсер собрать 😉

и в чем она не права?!

Что такое WebSocket и зачем он появился

WebSocket — это протокол, который позволяет установить постоянное соединение между клиентом и сервером и обмениваться данными в обе стороны в реальном времени. В отличие от классического HTTP, где всегда есть схема «запрос → ответ», здесь соединение остаётся открытым и данные могут приходить без нового запроса со стороны клиента.
Появился он из-за ограничений HTTP. Раньше, если нужно было обновлять данные в реальном времени (чаты, онлайн-игры, лайв-обновления, биржи), приходилось использовать костыли вроде polling или long polling. Это создавало лишнюю нагрузку на сервер и задержки, потому что клиент постоянно дёргал сервер, даже когда данных не было.
WebSocket решил эту проблему за счёт постоянного соединения и двусторонней передачи данных.

Где используется WebSocket?

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

А что тестировать в WebSocket?

Первое — это подключение. Ты смотришь, что соединение вообще устанавливается нормально, без ошибок, без странных падений.
Дальше — сообщения. Проверяешь, что сервер корректно их принимает, нормально парсит и не разваливается на кривых данных.
Потом реакция системы. То есть не просто отправили сообщение, а что дальше? Дошло ли оно, правильно ли отобразилось, всё ли работает как ожидается.
Отдельно смотришь ошибки. Например, невалидный JSON, слишком большие сообщения, обрывы соединения — и как система на это реагирует.
Если есть подписки на события или каналы, обязательно проверяешь, что подписка и отписка работают как надо, без утечек и багов.
Дальше — сессии и токены. Классическая история: токен протух, и важно, чтобы соединение корректно закрылось, а не начало бесконечно переподключаться.
Ну и безопасность. В проде это должен быть wss, а не ws, потому что данные всё-таки могут быть чувствительные.

Эд, это все круто, но где потрогать вебсокет?


Самый простой способ понять, как он работает — открыть любой сайт, где есть реалтайм. Например, онлайн-чат.

Можно взять тот же Wink (или платформу видеозвонков например) и открыть чат поддержки. Дальше заходишь в DevTools → вкладка Network → фильтр WS (или Socket).

Что здесь важно посмотреть:

- как соединение сначала устанавливается как HTTP, а потом апгрейдится до WebSocket
- какие заголовки приходят (Connection: Upgrade, Upgrade: websocket)
- как выглядит сам обмен сообщениями
- какие события отправляет клиент и что отвечает сервер

По сути ты наблюдаешь весь реалтайм «под капотом» — как сообщения уходят, приходят и как поддерживается соединение.


Написано в соавторстве: @mashaqasha

Как сегодня читаются посты в телеграм каналах

Я забил на YouTube, потому что

Занимаюсь другими вещами, но с радостью ассистировал Антону Назарову в разборе QA собеса: разобрали по софтам, самопрезентации и техническим вопросам.
Если ты проходишь собеседования сейчас - подмечай свои ошибки, исправляй и получай свой оффер!
Желаю только успеха!
А я обязательно вернусь на ютуб, очень скоро!
Посмотреть видео: https://youtu.be/vp0ijyXVgzc

Кстати, записаться на обучение по скидке все еще можно по ссылке: https://t.me/edversitybot?start=960452529

Привет! Меня зовут Эд.

Я Senior QA Manual Engineer и ментор по входу и росту в IT через профессию QA-тестировщика.

Этот канал для тех, кто:
• хочет войти в IT с нуля, но не понимает, с чего начать
• уже изучал QA сам или на курсах, но всё ещё не дошёл до оффера
• теряется на собеседованиях, когда спрашивают про реальные задачи
• уже работает в IT или QA, но хочет усилить навыки и выйти на зарплату выше

Здесь вы узнаете:
✅ с чего начать путь QA-тестировщика
✅ что действительно важно для трудоустройства в QA
✅ как собрать резюме без коммерческого опыта или усилить текущий опыт
✅ как проходить собеседования не как “ученик с курсов”, а как кандидат, готовый к работе
✅ какие ошибки мешают получить оффер или перейти на доход выше

Я прошёл путь от JunPlus до Senior и работал в проектах X5, .bank, Bars Group и VL Projects.

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

Начать советую с этого видеоразбора ⬇️
Как получить первую работу в QA без опыта

Жми на кнопку и забирай 🚀

Как я недозаработал 600+к за январь

Хотите услышать историю о том, как я недозаработал шестьсот тысяч рублей за январь?
Всё очень просто. Я отказываю некоторым людям.

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

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

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

Безусловно, мой внутренний компас на человека не всегда правильный и однозначный. Иногда я могу отказывать людям, с которыми в действительности мы бы могли сработаться. Иногда я беру людей на обучение, с которыми в конечном итоге у нас ничего не складывается, и меня либо обманывают (смешно звучит от человека который помогает накрутить опыт, да?), либо человек в итоге понимает, что это не его, и просто сливается сам. Такое тоже может быть.

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

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

И когда я стал отказывать людям, мне стало невероятно легче ко всему этому относиться.

У этого есть другая сторона медали — как раз-таки то, о чём я написал в самом названии поста. Я недозаработал 600+ тысяч только в январе, потому что отказал более чем 10 людям в обучении по разным причинам, абсолютно по разным причинам. Именно после созвонов, (знакомых), потому что некоторым ребятам я ещё отказываю до этого этапа — (их мы не учитываем).

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

Если хочешь проверить, а есть ли мэтч у нас, кстати, можно заполнить анкету в боте со скидкой - https://t.me/edversitybot?start=960452529

Так и живем, но ниче ниче, и с этим справимся!

А что там по стажировке?

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

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

Идея о том, что учиться нужно через практику, была всегда. Но на практике довольно сложно найти место, куда можно пристроить ребят на стажировку без опыта. С этим, слава богу, у меня получилось. Вторая сложность - это правильно и грамотно выстроить сам процесс. Как мне кажется, у нас это тоже получилось, пусть и не идеально, но тем не менее.

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

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

Привет, Стажировка прошла прекрасно .Я приобрел : 1. Реальный опыт работы с JIra. 2. Опыт коммуникации в команде 3.Опыт тестирования без документации (по началу) 4.Опыт работы с тестовой документацией. Понравилось все , даже если было что то не понятно , это играет на руку нам как специалистам , что бы мы активно общались и решали свои проблемы и трудности . Могу сказать что стажировка придала мне большей уверенности и понимания процессов работы , чувствую рост в осознанности чем буду заниматься на работе .

Во первых я очень рад что мне удалось попасть на стажировку. Больше всего запомнилось когда по найденной мною ошибке «спорили» разработчик (который говорил что это не баг) и главный QA Михаил. Понравилось все. И то что можно читать переписку разработчиков. И то что Катя (наш лид), не оставляла без внимания ни один наш вопрос. И то что проводились созвоны как на настоящем проекте. И т.д. Так как я попал на стажировку во время поиска работы, то возникли сложности. Пришлось одновременно готовиться к собеседованиям и вникать в процессы стажировки. Это было тяжело. Было бы лучше проходить ее во время обучения. Конечно же Сейчас я чувствую себя намного увереннее на собеседованиях. Теперь некая пустота, которая была внутри и грызла меня тем что я накрутчик, нашла чем заполниться. Так же теперь есть представления о процессах и я понимаю как приукрасить свою легенду.

пысы: мем для длофаминчика

пыпысы: подписаться на менторство по скидке https://t.me/edversitybot?start=960452529

Нейроментор это реальность?

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

Как вы знаете, мой друг Pablo, в бывшем тоже ментор, сейчас занимается вайп-кодингом и искусственным интеллектом. Очень сильно рекомендую почитать его challenge 300 000 с искусственным интеллектом или 100 000 подписчику. Я рекомендую подписаться. Я верю в Пашу, но рекомендую подписаться, мало ли что.😈

Вместе с ним мы сделали очень прикольную штуку. Я понимаю, что у некоторых ребят есть сложности с тем, чтобы пользоваться искусственным интеллектом, выбрать правильный искусственный интеллект. У нас есть очень огромный выбор. DeepSeek, Perplexity, ChatGPT, Gigachat, Алиса AI и остальные. Мы берем просто ChatGPT и на его базе сделали внутри нашего комьюнити хелпербота.

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

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

В конкретно данном случае мы просто облегчаем жизнь нашим ученикам. Здесь нет никакой подводки к продаже. Хотя менторы, можно купить у Пабло услугу, и он вам настроит. 😇


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


а в комментариях пример как эта шарманка работает