Все думают UUID нельзя подобрать. Ага как бы не так 😄 /api/order/a1b2c3d4-e5f6-7890-abcd-ef1234567890 - ну как ты угадаешь? Никак. Но тебе и не надо угадывать. Вчера смотрю как QA на проекте у себя тестит (я его курирую). Открывает свой заказ. В ответе приходит: { "my_order" "a1b2c3d4...", "other_orders" [ "b2c3d4e5...", "c3d4e5f6..." ] } Бекендер для удобства отдал список всех последних заказов в том же ответе. С UUID. QA увидел и прошел мимо. "Ну это же просто список, UUID же не угадаешь". А это уже IDOR. Критический. Тебе отдали чужие UUID. Дальше просто подставляешь. Тот же баг что и с 1024 -> 1025 или 10-11. Только в 2026 так делают чаще, потому что думают UUID = защита. QA бы завел как "лишние данные в ответе" - low. AppSec заведет как "IDOR + Information Disclosure, утечка PII" - critical + премия. Бекенд не защищает UUID. Защищает проверка "твой ли это заказ". Сколько раз вы видели в ответе чужие id и не обращали внимания? Вы можете верить можете нет я такие проблемы вижу постоянно, ок не постоянно вру, но оооочеь часто Наверное не зря да IDOR на первом месте стоит?? Мораль поста! Есть UUID? Не переберешь особенно v4, v7 Но что если получить UUID где-то в другом месте? Вот и думайте

Хорошее время для QA-инженеров. Часто слышу тезисы в духе:

AI-coding убил QA

Это не так. Точнее – не совсем так. Если мы внедряем AI-инструменты в процессы разработки, то написание кода достаточно сильно ускоряется. В зависимости от дисциплины и ответственности конкретного разработчика, это ускорение может в большей или меньшей степени влиять на качество производимого кода. Уже на первых этапах внедрения AI-инструментов в процессы разработки, мы получаем "затор" на стадиях ревью и тестирования. Этот затор кому-то придётся разгребать... Желательно – тоже с использованием AI в качестве инструмента. Здесь и появляется QA-инженер. Учитывая, что качество кода – одна из основных претензий к AI-generated-коду, роль грамотного QA (и грамотного QA внутри каждого разработчика) сильно повышается. QA-инженер отвечает за выстраивание quality-gates на разных этапах SDLC, а также организовывает процессы тестирования. QA-инженер даёт гарантию, что код, попавший в продакшн, соответствует конкретным критериям качества. Проблема в том, что в небольших командах QA-инженеры встречаются достаточно редко. Там чаще:

Ну, сидит у нас тестировщик, за плошку риса интерфейсы тыкает, проверяет, что они тыкаются

Эти тестировщики на процесс AI-SDLC влияют, скорее, негативно. Так как, под большим напором задач от AI-accelerated-разработчиков, выбора у них два – либо накапливать себе объёмы для тестирования, либо снижать качество проверок. В первом случае мы получаем нивелирование ускорения time-to-market, как одного из преимуществ AI-SDLC, а во втором – снижение стабильности прода. На этой неделе был "День тестировщика" (9 сентября). Я чуть опоздал с пожеланиями, но всё же: Пользуйтесь теми возможностями, которые предоставляют изменения на рынке. Изучайте глубже процесс AI-SDLC и то, как вы можете повлиять на качество кода на выходе. Потребность в QA-инженерах, способных работать в цикле AI-SDLC, будет только расти. Вопрос для дискуссии: Готовы ли QA-инженеры заменить в формате Tiny-teams разработчиков, не бравших на себя ранее ответственность за то, что их задача доедет до прода?

Напоминаю о плейлистах на YouTube моего авторства, которые будут полезны как новичкам, так и опытным специалистам, аккумулировавшим более 16.000.000 просмотров и прошедшим проверку временем: Тестировщик с нуля. Профессиональный курс Также данный плейлист есть в виде курса на Stepik с тестами, заданиями и тестовым конспектом Собеседования на тестировщика. Вопросы и ответы Руководство по трудоустройству Разборы резюме подписчиков Postman для тестировщика (с обновленным курсом 2025 года) Базы данных для тестировщика bash для тестировщика git для тестировщика И еще 40+ плейлистов и 300+ видео на канале youtube.com/@rusau Если на Youtube видео не открываются, то их всегда можно смотреть в ТГ @qa_video #обучение | сайт |материалы по тестированию