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

Каким мы хотим сделать обучение по автоматизации? Вы уже знаете, насколько серьёзно я отношусь к обучению и его результатам. Мне недостаточно просто давать теоретические знания. Я хочу, чтобы все мои ученики обязательно проходили через практику. Об этом я подробнее рассказывал здесь и здесь. Для меня конечный результат обучения заключается не только в полученном оффере. Важно, чтобы у человека были реальные навыки для работы, чтобы после трудоустройства он мог стать полноценной боевой единицей в команде, не боялся новых задач и не переживал, что с чем-то не справится или не сможет пройти испытательный срок. Поэтому в основном менторстве у нас есть домашние задания, регулярная практика, индивидуальные созвоны между модулями в формате собеседований, отдельное мок-собеседование перед выходом на рынок, стажировка и полноценная работа уже на этапе поиска работы. Всё это нужно для того, чтобы человек не просто понимал в теории, как работают определённые процессы и инструменты, а действительно умел применять их руками в реальных задачах. Такой же подход я хочу перенести и в направление по автоматизации тестирования. Мне точно не хочется делать ещё один курс, после которого человек может повторить код из урока, но не может самостоятельно написать тест или объяснить, как он работает. Поэтому для меня принципиально, чтобы в обучении было: • много задач по Python; • постепенный переход к UI-, API- и DB-автотестам; • работа с полноценным тестовым проектом, а не только с отдельными атомарными задачами; • понимание архитектуры проекта, работы с тестовыми данными и очистки после выполнения тестов; • автоматический запуск тестов и работа с отчётами; • итоговый проект, который ученик сможет собрать самостоятельно, а затем защитить; • подготовка к техническим вопросам, защите проекта и объяснению собственных решений на собеседовании. Сейчас мы как раз проектируем программу и формат обучения, дорабатываем их каждый день. Мне важно не просто добавить в программу как можно больше технологий, а выстроить понятный и последовательный маршрут: от первого кода на Python до уровня, на котором человек может самостоятельно собрать проект автоматизации, защитить свои решения на собеседовании и быть готовым к трудоустройству на позицию автоматизатора тестирования на Python. На следующей неделе я покажу, к какой структуре мы пришли, и открою предварительную запись. А пока хочу уточнить последний важный момент:

ух бля. на 3 333 подписчика бесплатное обучение разыграть чтоли

На собеседованиях иногда задают вопрос: знакомы ли вы с shift left testing? При этом часто под ним подразумевают именно тестирование требований. В целом я с этим согласен. Обычный жизненный цикл разработки любят изображать в виде линии. Об этом я рассказывал в видео про жизненный цикл задачи. Сначала появляется идея, потом создаются требования, собираются дизайн и макеты, дальше продукт разрабатывается, тестируется, релизится, и уже после этого им начинают пользоваться реальные пользователи. Эту линию условно можно разделить на две части. Левая часть находится ближе к требованиям и разработке, а правая часть ближе к релизу и уже работающему продукту. Отсюда и появляется название shift left. Оно означает, что проверки стараются проводить как можно раньше. Сюда относятся принцип раннего тестирования, тестирование требований, анализ рисков до начала разработки и так далее. Shift right означает, что качество продолжают проверять уже после релиза, в реальной среде и с реальными пользователями. В 2020 году появился новый термин shift everywhere. А в 2025 году, благодаря нашему любимому AI, о нем стали говорить все больше и больше. Я сейчас не буду подробно уходить в обсуждение shift left или shift right. (Об этом можно почитать тут и тут) Мы будем говорить именно о shift everywhere, потому что, на мой взгляд, это гораздо ближе к тому, с чем тестировщики работают на самом деле. И, если честно, работали уже достаточно давно, просто об этом почему-то говорится слишком мало. Shift everywhere testing, по сути, объединяет shift left и shift right, потому что мы проверяем всю нашу линию. Качество проверяется до разработки, во время разработки, внутри CI/CD, на тестовом окружении, во время релиза, после релиза, во время эксплуатации, при разборе продуктовых инцидентов и так далее. То есть это уже подход к организации всей работы с качеством. Концептуально shift left testing концентрируется на раннем обнаружении проблем. Главные вопросы здесь примерно такие:

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

Shift everywhere включает все это, но не останавливается после релиза. Проще говоря, shift left пытается не допустить, чтобы проблемы ушли дальше по процессу. Сам подход появился как раз из-за того, что ошибки и инциденты, найденные на финальной стадии разработки или уже после релиза, обходятся компании очень дорого. А shift everywhere контролирует качество на протяжении всего процесса и всей жизни продукта. На мой взгляд, работа тестировщика и то, чему мы учим на своем курсе, концептуально намного ближе именно к shift everywhere. Потому что мы говорим об ответственности за качество на всех этапах. Но здесь важно понимать, что качество продукта не зависит только от одной роли или одной зоны ответственности. За качество отвечает вся команда, потому что каждый ее участник на это качество влияет. При этом тестировщик помогает выстроить единую систему работы с качеством и помогает команде этой системы придерживаться. Но у подхода shift everywhere есть и определенные проблемы. На практике можно просто получить больше работы и больше хаоса. Проверки вроде бы есть везде, но никто не понимает, какие из них действительно нужны. Где мы реально снижаем риски, а где просто тратим время. Нет приоритетов, нет понятных границ, нет общей системы. А фраза «мы тестируем на проде» вообще может превратиться в полный маразм, если под ней подразумевается, что нормально выпускать непроверенный продукт и разбираться уже на пользователях. Можно очень круто рассказывать, что у компании shift everywhere или shift left testing. Но при этом продолжать отдавать тестировщику готовую задачу за день до релиза со словами: «Давай как-нибудь успевай».😡 При этом границы работы и ответственности QA действительно расширяются. Я вижу это и по собеседованиям, и по общему состоянию рынка. Современному QA нужно знать немного больше, чем условно три-четыре года назад. Нужно понимать, как появляется задача и как она проходит через разраб

Как понять, что требования действительно покрыты тестами и вы ничего не пропустили? В этом видео разбираю матрицу трассировки требований, или RTM, не как сухой термин из теории, а через реальный вопрос, который могут задать на собеседовании: «Как вы понимали, что требования покрыты тестами и ничего не пропустили?» Поговорим о том: • как связывать требования с тест-кейсами и чек-листами; • чем полное покрытие отличается от частичного; • когда нужна отдельная матрица трассировки; • почему RTM не обязательно должна выглядеть как Excel-таблица; • как честно ответить на собеседовании, если отдельной RTM на проекте не было; • когда достаточно обычного чек-листа в задаче. Бот для анализа собеседований моего хорошего друга Артура Илекаева: https://t.me/offerfactorybot?start=edqa_july Хочешь попасть на обучение? Оставь анкету: https://t.me/edversitybot?start=960452529 Мой Telegram-канал: https://t.me/edzi_qa Мой YouTube-канал: https://youtube.com/@youtubeeda

Зачем платить за обучение? Это действительно хороший вопрос, ведь в интернете можно найти много бесплатной информации. Однако её нужно сначала найти, отфильтровать и структурировать, чтобы понять, что конкретно нужно учить, а что можно пропустить или уделить меньше внимания. Я тоже учился самостоятельно, потому что не верил в курсы и не имел на них денег. Брать рассрочку очень не хотелось, поэтому я собирал информацию из разных источников, часто углубляясь в дебри с мыслью: «А вот эту статью прочту, вот это видео посмотрю, а ещё и этот курс пройду». Так я искусственно увеличивал время подготовки. Собственно, для этого и нужен ментор: чтобы оградить от лишней работы/учёбы, структурировать процесс и помочь отделить зерна от плевел. Но, опять же, недоверие, отсутствие денег (услуга не дешевая) и другие факторы приводят к самостоятельному изучению. Я действительно считаю, что путь самостоятельного изучения с возможностью обратиться к ментору при необходимости (без осуждения тех, кто покупает услугу «из коробки») имеет право на существование. Когда я учился сам, я собирал ссылки на внешние источники в отдельный документ и теперь хочу поделиться им с теми, кто хочет учиться самостоятельно. Конечно, в любом случае потребуется практика, и, возможно, некоторые вещи нужно будет доработать, но базу можно найти здесь: roadmap 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 на идею вкатить вообще ВСЕХ, и на выходных собирал разные источники вакансий, эх щас еще парсер собрать 😉

Продолжаем цикл о риск-ориентированном тестировании и поговорим о том, а какие риски вообще есть? Мы немножко затронули об этом в предыдущем тексте, сейчас чуть-чуть углубимся. Есть технические риски. Они связаны с тем, что в какой-то зоне выше вероятность дефекта или какого-то неправильного поведения продукта. Такие риски часто появляются там, где есть сложность, неопределенность или большое количество связей с другими частями системы. Новая сложная логика, много условий и ветвлений, интеграция с внешним сервисом, асинхронные процессы, очереди событий, статусы, расчеты, миграции данных, изменения в легаси, неполные или противоречивые требования, сложные роли и права доступа. Допустим, разработчик поменял общий компонент авторизации. Плохой подход будет в том, чтобы проверить только экран входа, потому что задача вроде бы про авторизацию. Хорошим подходом будет подумать о том, а где еще авторизация используется, потому что у нас есть личные кабинеты, оформление заказов, восстановление пароля, подтверждение email, доступ к платным функциям, админки. Технический риск здесь не только в том, что логин может не работать. Риск в том, что изменение здесь может задеть соседние сценарии, которые напрямую в задаче не описаны. Поэтому технический риск чаще всего отвечает на вопрос: что это изменение могло сломать рядом? Риск-ориентированное тестирование можно применять не только на уровне отдельных фич, но и на уровне изменений и релизов. Для каждого изменения важно смотреть, какие функции оно затрагивает, где используется и насколько сильно поменялась система. Собственно, регресс у нас вроде бы об этом и говорит, но в регрессе у нас тоже могут быть тест-кейсы, которые покрывают какие-то core-функциональности, и тест-кейсы, которые основаны на риск-ориентированном подходе. Второй пласт рисков — бизнесовые. Это не обязательно риски из-за сложного кода. По сути, это риски из-за высокой важности фичи для бизнеса. Фича может быть технически простой, но критической для денег, продаж, удержания пользователей, репутации или работы внутренних сотрудников. Как мы уже говорили ранее, пользователь не может оставить заявку, не может оплатить, не создается заказ, не применяется скидка, не работает регистрация, ломается онбординг пользователя, менеджер не видит новую заявку в CRM и так далее. В этих случаях проблема важна не только потому, что есть баг технический. Она важна потому, что она напрямую влияет на бизнес. Пользователь не оставил заявку — значит, бизнес потерял потенциального клиента. Пользователь не смог оплатить — значит, бизнес потерял деньги. Заявка не попала в CRM — значит, менеджер ее не обработал. И так далее. Нужно помнить о том, что QA приносит бизнесу пользу не только тем, что находит баги, но и помогает защищать ключевые сценарии: удерживать пользователей, скорость релизов и доверие к продукту. Потому что у нас есть очень важные три метрики для работы команды, в том числе и которыми являются тестировщики: качество продукта, скорость релизов и понимание пользователей. давайте так: 40 реакций и закину вторую часть этого поста о пользовательских рисках (у меня лапки и она не поместилась)

Риск-ориентированное тестирование. Как понять, что проверять в первую очередь? Так, начинаем цикл постов чтобы так сказать "ШАРИТЬ В ЭТОЙ ТЕМЕ" Когда мы говорим о тестировании, часто хочется сказать, что вообще мы можем проверить всё. По сути, это правильно, особенно когда человек только начинает учиться и боится что-то пропустить, и при собеседовании ему кажется, что это хороший и правильный ответ. Но в реальной работе проверить всё почти никогда не получается, потому что есть различные ограничения: скорый релиз, много задач, требований не хватает, окружение может иногда лежать, или оно занято другими командами, разработчики ждут обратную связь, аналитик уже работает с другой задачей, бизнесу нужно выкатить фичу не когда-нибудь, а ещё вчера, и ограничение по времени. Поэтому работа тестировщика не сводится к тому, чтобы просто пройтись по всем пунктам подряд с одинаковой глубиной. Хороший QA должен понимать, где ошибка или недостаточность проверки будет стоить дороже всего, если мы говорим именно о QA, а не о тестировщиках. Вот здесь, на самом деле, и появляется риск-ориентированное тестирование. Важно сразу убрать одно частое заблуждение. Риск в тестировании — это не только то, что может что-то сломаться. Да, технические риски тоже есть. Сложная логика, интеграции, статусы, асинхронные процессы, миграции, права доступа, легаси, неполные требования — всё это в действительности повышает вероятность риска. Но есть еще и второй пласт — это бизнесовые риски. Это ситуации, когда фича может быть технически простой, но очень важной для бизнеса. Например, форма заявки может быть обычной формой из нескольких полей и кнопки, но если через нее компания получает лиды, то ее нельзя проверять поверхностно. Если форма не отправляет заявки, бизнес теряет деньги. Если заявки не попадают в CRM, менеджеры не связываются с клиентами, бизнес теряет деньги. Если не сохраняется источник заявки, маркетинг не понимает, какая реклама работает. Бизнес теряет деньги. Технически это может выглядеть несложно, но бизнесово это критическая зона. Поэтому риск-ориентированное тестирование — это не про то, чтобы тестировать меньше, это про то, чтобы тестировать более осознанно. Мы не просто спрашиваем, типа, где может быть баг, мы спрашиваем шире: где баг может стоить дороже всего? Риск-ориентированный подход как раз предполагает, что мы не применяем одинаковую глубину проверки ко всем частям приложения, а приоритизируем тестирование по вероятности проблемы и по силе ее потенциального влияния. Что такое риск в тестировании? Если объяснять просто, риск в тестировании — это причина уделить какой-то части продукта больше внимания. Обычно риски оцениваются через две вещи. Первая вещь — вероятность. Насколько вероятно, что здесь появится проблема. Вторая вещь — влияние. Насколько больно будет пользователю, бизнесу или команде, если проблема попадет в прод. (более подробно мы поговорим о них позже) Но для практики можно держать в голове еще более простой вопрос: что будет, если мы хуево проверим эту часть? Если ответ такой: ну, максимум, текст будет некрасиво отображаться, скорее всего, очевидно, здесь риск низкий. Если ответ: пользователь не сможет оплатить заказ — высокий. Бизнес перестанет получать заявки — высокий. Пользователь увидит чужие данные — высокий. Если после релиза команда неделю будет тушить пожары последствий, риск тоже высокий. То есть риск не всегда равен сложности задачи. Сложная задача не всегда самая важная. Простая задача не всегда самая безопасная. Например, можно переделывать сложную анимацию на главной странице: там может быть много фронтовой логики, адаптива, состояний, браузеров. Но если эта анимация декоративная и не влияет на основной сценарий пользователя, ее бизнесовый риск может быть ниже. А можно добавить простую форму заявки на консультацию. Технически там, опять-таки, несколько полей, кнопка «Отправить». Но если через эту форму бизнес получает клиентов, то риск, соответственно, высокий. это первый пост из цикла, следующий через пару дней выложу как вдохновение придет😡

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

Что такое WebSocket и зачем он появился WebSocket — это протокол, который позволяет установить постоянное соединение между клиентом и сервером и обмениваться данными в обе стороны в реальном времени. В отличие от классического HTTP, где всегда есть схема «запрос → ответ», (например если ты решил записаться на обучение ко мне и отправил анкету перейдя по ссылке со скидкой https://t.me/edversitybot?start=960452529 и ждешь ответ - это классика HTTP) здесь соединение остаётся открытым и данные могут приходить без нового запроса со стороны клиента. Появился он из-за ограничений HTTP. Раньше, если нужно было обновлять данные в реальном времени (чаты, онлайн-игры, лайв-обновления, биржи), приходилось использовать костыли вроде polling или long polling. Это создавало лишнюю нагрузку на сервер и задержки, потому что клиент постоянно дёргал сервер, даже когда данных не было. WebSocket решил эту проблему за счёт постоянного соединения и двусторонней передачи данных. Где используется WebSocket? Вообще WebSocket нужен везде, где важен реалтайм, где нельзя ждать, пока клиент сам пойдёт за данными. Это в первую очередь чаты и поддержка, когда сообщение должно прилетать сразу, без обновления страницы. Онлайн-игры — там вообще без этого никак, потому что всё должно происходить мгновенно. Любые лайв-обновления интерфейса, типа уведомлений или изменения статусов. Биржи, где цены постоянно меняются и нужно это сразу показывать пользователю. Ну и всякая аналитика, трекинг действий, когда система в фоне отправляет события на сервер. Платформы видео-созвонов, мессенджеры и так даллее. По сути, практически ежедневно мы, как пользователи взаимодействуем с помошью сокета. А что тестировать в WebSocket? Первое — это подключение. Ты смотришь, что соединение вообще устанавливается нормально, без ошибок, без странных падений. Дальше — сообщения. Проверяешь, что сервер корректно их принимает, нормально парсит и не разваливается на кривых данных. Потом реакция системы. То есть не просто отправили сообщение, а что дальше? Дошло ли оно, правильно ли отобразилось, всё ли работает как ожидается. Отдельно смотришь ошибки. Например, невалидный JSON, слишком большие сообщения, обрывы соединения — и как система на это реагирует. Если есть подписки на события или каналы, обязательно проверяешь, что подписка и отписка работают как надо, без утечек и багов. Дальше — сессии и токены. Классическая история: токен протух, и важно, чтобы соединение корректно закрылось, а не начало бесконечно переподключаться. Ну и безопасность. В проде это должен быть wss, а не ws, потому что данные всё-таки могут быть чувствительные. Эд, это все круто, но где потрогать вебсокет? Самый простой способ понять, как он работает — открыть любой сайт, где есть реалтайм. Например, онлайн-чат. Можно взять тот же Wink (или платформу видеозвонков например) и открыть чат поддержки. Дальше заходишь в DevTools → вкладка Network → фильтр WS (или Socket). Что здесь важно посмотреть: - как соединение сначала устанавливается как HTTP, а потом апгрейдится до WebSocket - какие заголовки приходят (Connection: Upgrade, Upgrade: websocket) - как выглядит сам обмен сообщениями - какие события отправляет клиент и что отвечает сервер По сути ты наблюдаешь весь реалтайм «под капотом» — как сообщения уходят, приходят и как поддерживается соединение. Написано в соавторстве: @mashaqasha