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

В этом видео мы с Женей поговорили про нагрузочное тестирование, направление, которое почему-то до сих пор сильно недооценено среди тестировщиков Хочешь разобраться в нагрузочном тестировании на практике? Запись на обучение: @edverseperfomance_bot Разобрали: • почему в нагрузке конкуренция может быть ниже, чем в автоматизации • насколько этот навык повышает ценность обычного Manual QA или AQA • K6, JMeter, Locust и сколько вообще нужно уметь кодить • как на самом деле строится нагрузочный тест от задачи до анализа результатов • какие метрики смотреть и как искать причины проблем • реальные кейсы Жени из банков, Mastercard, Mercedes и SRE • сможет ли AI просто написать все скрипты за нас • с чего начать изучение нагрузочного тестирования Короче, если вы сейчас думаете, куда расти дальше после ручного тестирования, я бы как минимум посмотрел в эту сторону.

Не иметь рублей, а иметь друзей. Недавно узнал о себе немного нового. Оказывается, я обычный воздухан, который рисует опыт и придумывает легенды своим ученикам, а 99% отзывов накручены друзьями и знакомыми. (это если вам лень фото открывать) Честно говоря, немного обидно только за одно: почему мои друзья ограничились только отзывами и ещё не накрутили мне хотя бы 10 тысяч подписчиков? Алло? Но раз уж речь зашла о выдуманных результатах, то я хотел бы поделиться небольшим итогом июля. За июль ученики получили 18 офферов. Средняя сумма оффера составила примерно 153 500 рублей. Самый большой оффер месяца — 210 тысяч рублей gross, примерно 180 тысяч рублей на руки. Самый маленький оффер — 92 тысячи рублей. Мы всё-таки за честность и открытость, поэтому показываем не только самые красивые цифры. Всего офферы получили 11 разных человек. Очевидно, что количество офферов больше, просто некоторые ребята за один месяц успели получить несколько предложений. Один человек получил три оффера, ещё несколько человек получили по два оффера. То есть ребята могут в целом выбирать между компаниями и условиями, а не соглашаться на первый попавшийся вариант. Конечно, я бы хотел, чтобы офферов было ещё больше, и чтобы каждый человек, который сейчас находится в поиске, как можно быстрее закончил этот довольно неприятный этап. Но 18 офферов за месяц на текущем рынке, да ещё и в июле, месяце, который считается мёртвым из-за количества отпусков, я считаю просто охуенным результатом. В июне было в два раза меньше. Хотя, чё, возможно, это тоже всё придумали мои друзья. Круто иметь друзей. Особенно если они умеют устраиваться в IT по два-три раза за месяц. Вот би еще все платили по % от оффера, да? 800к на пассиве тут мог быть прогрев на обучение по скидке но мне не хоч сегодня

Пока мы начинаем связываться с теми, кто оставил анкеты на курс по автотестам, я решил чуть подробнее рассказать о новом методе HTTP, о котором писал в этом посте Но по одному посту нормально разобрать тему всё равно сложно: там и ограничения GET, и странное использование POST для поиска, и safe/idempotent, и отдельные нюансы для тестирования. Поэтому сел и записал полноценный разбор: https://youtu.be/Oiqhd1H865A?si=ykao8Sedf9De5gcm Видеоконтента в последнее время снимается очень много, жаль что оно идет в другие проекты🚬 вот бы похудеть к своему прайму

У нас дома сейчас два человека постоянно что-то записывают, переписывают и готовят выступления. Только я рассказываю про тестирование и готовлю несколько новых направлений, а Катя про то, как сделать так, чтобы после этого тестирования не отвалились жопа спина. Периодически мы сидим каждый за своим рабочим местом: я собираю очередной урок, Катя готовит презентацию про здоровье спины. Выглядит это особенно иронично, потому что свой доклад она буквально готовит в тех же условиях, от последствий которых пытается предостеречь других. Скоро Катя выступит на конференции «Профсоюзная 2.0». Она расскажет, почему после рабочего дня болят спина и шея, существует ли вообще правильная поза за компьютером и что делать, если работа всё равно требует проводить большую часть дня сидя. И мне особенно нравится, потому что презентацию я уже видел, что это будет не выступление в духе: «Сидите ровно, купите дорогое кресло, каждые 15 минут вставайте на зарядку. С вас пять тысяч». Катя много лет работает с людьми, у которых уже что-то болит, поэтому будет разбирать не идеальные условия, а реальную жизнь. Когда у тебя созвоны, дедлайны, работа, дети, усталость, ипотека и нет никакого желания превращать заботу о спине во второй полноценный проект. В общем, я обычно рассказываю, как попасть в IT и развиваться внутри профессии. А Катя расскажет, как сделать так, чтобы твой организм не пожалел об этом решении. Приходите послушать. Я, разумеется, тоже буду там. В первом ряду, с максимально прямой спиной. Как видите, сейчас у меня это получается не особо. Конференция: https://unionconf.ru/ пысы: говорят скоро повышение цен, так что если покупать то сейчас, прошлая конфа прошла ахуенно

Открываем предварительную запись на обучение по автоматизации тестирования На прошлой неделе я рассказал, каким мы хотим сделать обучение по автоматизации и какие принципы для меня в нём важны. Сейчас мы собрали предварительную структуру программы и готовы открыть предзапись на первый поток. Это обучение для ручных тестировщиков, которые хотят перейти в автоматизацию на Python, но не хотят собирать знания по отдельным роликам, бесплатным курсам и случайным задачам. Начать можно будет с нуля. Уметь программировать или писать автотесты заранее не нужно. Но опыт в ручном - нужен, если вы хотите пройти путь фулстека от ручного до авто - заполняйте анкету тоже! Мы хотим провести человека по полноценному маршруту: Python с нуля для QA → практика Python → первый вход в UI-автотесты → API и backend для QA Automation → базы данных → комбинированные UI-, API- и DB-сценарии → архитектура фреймворка → Allure и анализ падений → CI/CD → подготовка к собеседованиям → итоговый проект. В первом блоке разберём синтаксис Python, типы данных, функции, коллекции, работу с файлами, обработку ошибок и базовое ООП. После этого будет много практики. Не просто посмотреть, как преподаватель решает задачу, а научиться самостоятельно работать со строками, списками, словарями, функциями и классами. Дальше перейдём к браузерным сценариям: локаторам, ожиданиям и проверкам. Затем разберём HTTP, REST, JSON, авторизацию и подготовку данных через API. Отдельный блок посвятим базам данных и SQL, чтобы ученик понимал, где хранится результат действий пользователя и как его проверить. После этого начнём связывать UI, API и базу данных в единые тестовые сценарии, которые будут ближе к реальной работе автоматизатора. Затем перейдём к архитектуре тестового проекта: Page Object, слоям проекта, фикстурам, конфигурации, тестовым данным и очистке после выполнения тестов. Научимся формировать понятные Allure-отчёты, добавлять шаги, вложения и скриншоты, а также разбирать причины падения тестов. Разберём автоматический запуск тестов в CI/CD, работу с окружениями, артефактами и стабильностью прогонов. Отдельно подготовимся к вопросам по Python, API, базам данных, pytest, архитектуре проекта, отчётам и CI/CD, которые могут встретиться на собеседованиях. Финальным результатом станет полноценный проект автоматизации по учебному продукту, который ученик соберёт самостоятельно и сможет использовать для подготовки к собеседованиям. Для нас принципиально, чтобы внутри обучения были не только записанные уроки, но и: • домашние задания и регулярная практика; • проверка выполненных работ; • возможность задавать вопросы и разбирать ошибки; • созвоны для проверки знаний; • итоговый проект и его защита; • подготовка к техническим вопросам и объяснению своих решений на собеседовании. Результатом должен стать не просто просмотренный курс и набор скопированных автотестов. Ученик должен научиться самостоятельно писать код на Python, создавать UI-, API- и DB-проверки, собирать поддерживаемый тестовый проект, работать с отчётами, понимать автоматический запуск тестов и объяснять свои решения. Сейчас мы открываем предварительную запись на первый поток. (по классике КОЛ-ВО МЕСТ ОГРАНИЧЕНО))) Предзапись ни к чему не обязывает. После заполнения анкеты вы первыми получите полную программу, информацию о формате и продолжительности обучения, даты запуска, стоимость и условия участия. Если вы уже оставляли заявку на обучение по автоматизации после предыдущего анонса, повторно заполнять анкету не нужно. Ваша заявка у нас уже есть. Оставить заявку на предварительную запись: https://forms.yandex.ru/cloud/6a4f5f73e010db53b5a7987d

Мы привыкли, что собеседование в IT делится на несколько этапов: HR-скрининг, техническое собеседование и, возможно, финальное собеседование или знакомство с командой. Но иногда еще бывает стресс-собеседование. Что такое вообще стресс-собеседование? Это формат собеседования, при котором для кандидата искусственно создается напряженная и некомфортная атмосфера. По сути, цель достаточно прозрачна: вывести человека из равновесия и посмотреть, как он ведет себя в каких-то агрессивных условиях. Тем, кто попадет на такое собеседование, я рекомендую сохранять хладнокровие, не воспринимать каждый вопрос как нападение на себя, не отождествлять себя с этими вопросами и понимать, что угадать ответ, который хочет услышать работодатель, получится не всегда. Мой совет, наверное, быть достаточно честным и открытым, но при этом рациональным и не быть мудаком. Недавно мы с учениками разбирали несколько вопросов со стресс-собеседований. Некоторые из них мне хотелось бы привести в пример и, возможно, показать, как можно на них отвечать. Понятное дело, что я сам совсем не самый идеальный и рациональный человек, но тем не менее. Первый вопрос был: «Что самое демотивирующее в вашей работе?» И тут нужно понимать, что каждый вопрос с подвохом. Но, на мой взгляд, идеальный вариант ответа заключается в том, чтобы показать: да, какие-то вещи действительно мне не нравятся, демотивируют или смущают. Но я не просто страдаю из-за этого, не обижаюсь где-то там у себя дома и не продолжаю все это хавать, потому что у меня нет выбора, а все-таки пытаюсь на ситуацию влиять. Например, для меня одним из самых демотивирующих моментов в работе было то, что часть работы либо не доходила до результата, либо требования и приоритеты задач менялись уже в процессе спринта. В итоге все время, которое мы тратили на планирование, шло коту под хвост. Еще меня демотивировали очень длинные встречи, когда каждый понедельник мы созванивались командой из 20 человек и обсуждали, кто чем занимался на выходных. Зачем? Еще был вопрос: «Какое у тебя определение токсичного человека и как бы ты справлялся с токсичным человеком, если бы он оказался в твоей команде?» Ремарка: я не понимаю, почему такие вопросы задавали именно на стресс-собеседовании, но тем не менее. Понятное дело, что границы токсичности у каждого свои, как и границы дозволенного в общении с разными людьми. Но в работе есть какой-то более-менее определенный портрет. Для меня токсичный человек — это человек, который системно разрушает рабочую коммуникацию, обесценивает других, перекладывает ответственность и провоцирует конфликты. И здесь для меня важно разделять личное впечатление о человеке и конкретные рабочие ситуации. Если человек резко общается или мешает работе, я бы сначала спокойно поговорил с ним один на один и попробовал понять, в чем причина. Может быть, действительно существует какая-то рабочая проблема. В целом нужно понимать, что иногда проблема не столько в токсичности, сколько в личном перегрузе, внутренних конфликтах, проблемах дома или на работе. Человек может из-за этого срываться на других. Я осуждаю такое поведение, оно неприемлемо, но тем не менее оно бывает. Если это поведение повторяется и влияет на работу, я бы перевел коммуникацию в письменный формат. Фиксировал бы договоренности, сроки и решения, чтобы не было никаких разночтений. Если это не помогает, то уже с конкретными примерами можно идти к лиду. При этом важно фокусироваться не на личности и не говорить: «Петя долбоеб», а объяснять, как именно его поведение влияет на команду и рабочий процесс. Еще один вопрос был: «От какой роли в команде ты бы избавилась и почему?» Это тоже вопрос с подвохом. Я уверен, что многие из вас ответили бы: от HR или скрам-мастера. Но мне кажется, что это достаточно опасный ответ. В целом любой ответ на такой вопрос может оказаться опасным, если не лавировать в своих суждениях достаточно дипломатично. Я бы ответил так: я бы не стал избавляться от какой-либо роли просто ради того, чтобы от нее избавиться, потому что очень многое зависит от конкретной команды. Если команда способна распределить между собой функции какой-то роли, то ее действительно можно убрать. Но если команда не может нормально закрывать эти функции, то, наверное, такого человека все же стоит оставить. Как круто я налил воды и при этом ничего не ответил.🚬 Еще один вопрос, который мне хотелось бы обсудить и на этом, наверное, закончить. Разработчик не идет на контакт и игнорирует вопросы. Мы ему написали, он игнорирует. Написали еще раз, он снова игнорирует. В целом такие ситуации действительно бывают. Возможно, у него просто две работы. Но так мы, конечно, на собеседовании не говорим. На самом деле сначала нужно понять, насколько срочный у нас вопрос. Если он не блокирует мою работу и мне есть чем заниматься, я просто оставлю сообщение и пойду заниматься своими делами. Если мне нужно дать по задаче какой-то ответ, я могу написать тимлиду, что жду информацию и поэтому задача сейчас заблокирована. Либо могу написать в общий чат. Если же у нас горят сроки задачи или приближается релиз, тогда, конечно, можно написать в общий чат, тегнуть нужного человека или подключить кого-то еще. Но делать это нужно не в формате претензии, а примерно так: «Привет. Есть проблема, нужен ответ по такой-то задаче. Кто может помочь и дать информацию?» И на этом, собственно, все. Хочется подытожить тем, что на таком формате собеседований проверяют не столько знания, сколько то, как ты говоришь о конфликтах, как работаешь с токсичностью, как эскалируешь проблемы, общаешься в команде и относишься к рабочим процессам. Здесь не нужно заучивать готовые ответы, хотя подготовиться к подобным вопросам, конечно, можно. Важно отвечать грамотно и оставаться человеком, который не терпит вообще все подряд, но при этом и сам не превращается в того самого токсичного человека.

Каким мы хотим сделать обучение по автоматизации? Вы уже знаете, насколько серьёзно я отношусь к обучению и его результатам. Мне недостаточно просто давать теоретические знания. Я хочу, чтобы все мои ученики обязательно проходили через практику. Об этом я подробнее рассказывал здесь и здесь. Для меня конечный результат обучения заключается не только в полученном оффере. Важно, чтобы у человека были реальные навыки для работы, чтобы после трудоустройства он мог стать полноценной боевой единицей в команде, не боялся новых задач и не переживал, что с чем-то не справится или не сможет пройти испытательный срок. Поэтому в основном менторстве у нас есть домашние задания, регулярная практика, индивидуальные созвоны между модулями в формате собеседований, отдельное мок-собеседование перед выходом на рынок, стажировка и полноценная работа уже на этапе поиска работы. Всё это нужно для того, чтобы человек не просто понимал в теории, как работают определённые процессы и инструменты, а действительно умел применять их руками в реальных задачах. Такой же подход я хочу перенести и в направление по автоматизации тестирования. Мне точно не хочется делать ещё один курс, после которого человек может повторить код из урока, но не может самостоятельно написать тест или объяснить, как он работает. Поэтому для меня принципиально, чтобы в обучении было: • много задач по 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 А в ближайшее время (я думаю на след неделе) мы откроем нашу миниапу по подписке для всех желающих повторить/выучить тестирование, без определенных модулей, но с практикой, аве!

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

Я активно использую искусственный интеллект в своей работе для того, чтобы оптимизировать какие-то рутинные действия. В этом видео я рассказываю о своём опыте работы, о своём понимании использования ИИ в работе. Возможно, я делаю это не так активно, как некоторые из вас, но для тех, кто не использует искусственный интеллект, это будет на 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 СМОТРЕТЬ НА ЮТУБЕ