Геннадий Чурсов | QA++

Как и обещал в прошлом посте выкладываю свое решение задания:

Задание:

🧪 В проекте с автотестами на Rest Assured:

— Прокиньте токен из @BeforeAll во все тесты.
— Сделайте это без статики.
— Сохраните архитектурную чистоту (SOLID, KISS).

🐈 GitHub: https://github.com/topsycreed/rest-assured-token
В решении используется Java, Gradle, JUnit 5, AssertJ, Rest Assured, Jackson, Allure, Lombok и Owner для чтения properties.

Тестировал решил API сценарий добавления товара в корзину для сайта https://www.ae.com/us/en — этот же сайт и его API используем на моем бесплатном курсе по автоматизации на Java в рамках курсового пет проекта.

Что было сделано:
1️⃣ Создан TokenManager - Хранит токены по ролям (GUEST, AUTH) в ThreadLocal<EnumMap<>>
Использует ленивую инициализацию computeIfAbsent Позволяет получить токен через TokenManager.getToken() или .getToken(UserRole)

2️⃣ Создано JUnit-расширение - GuestTokenExtension и заготовка для будущего AuthTokenExtension
В beforeAll() устанавливает роль (TokenManager.setCurrentRole(...)) И иницилизируется токен (TokenManager.getToken())

3️⃣ Контроллер (BagController) не знает о ролях
Просто вызывает TokenManager.getToken() — и получает нужный токен Роль уже была установлена расширением → нет дублирования

4️⃣ Отдельный контроллер для токенов (TokenClient)
Передаем авторизационный хедер из свойств, если нужно можно даже сделать секретными данными, для Guest общедоступная информация.

Почему решение архитектурно чистое:
• KISS - Простой TokenManager, один вызов в контроллере
• Single Responsibility Principle - TokenManager отвечает только за токены, контроллер — за API
• Open/Closed Principle - Добавить новую роль — легко (новое расширение)
• Dependency Inversion Principle - Контроллер не зависит напрямую от способа получения токена
• Без static в тестах - всё управление токеном — через @ExtendWith(...)

Пишите свои идеи как еще можно было бы решить такую задачку.

🔴 Вы попрыгунчик или засиделись на одном месте? ❌

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

Короткий ответ: не очень.
⏳ Меньше одного года в компании — уже red flag.

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

Проблема в том, что:
📌 Если вам не понравилась компания,
📌 Вы не растёте, не приносите пользу,
📌 Но и уйти "рано" — плохо, то ощущение, будто нужно отсидеть 2+ года как на каторге.

🤷‍♂️ Хотя это невыгодно ни вам, ни компании, но важно нанимающему, который должен доверить вам долгосрочный проект.

Как с этим борются компании:
💰 Премии с "отсидкой" — чтобы отработать хотя бы год или полтора.
📈 Опционы — часто вестятся до 4 лет, иначе полностью не продать.
✈️ Релокационные пакеты — требуют год работы, иначе платишь обратно.

А что с засидельцами?
🧓 10 лет в одной компании — тоже часто минус.
🤯 Часто тяжело адаптироваться, сложно принять новые процессы, и привычка всё сравнивать с «как было у нас» мешает расти.

💡 Что делать?
Почитайте обсуждение сами.
Используйте аргументы и примеры, чтобы быть готовым к каверзным вопросам на собеседовании.

Сколько работают айтишники на самом деле? 🤔

Замечали, что про продолжительность работы айтишников иногда думают совершенно противоположное? Кто-то уверен, что они работают по 2 часа, а остальное время чилят. Кто-то считает, что они из-за компьютера вообще не выходят и постоянно перерабатывают. А последнее время есть тенденция считать, что половина из них просто работает на 2-х и более работах и лутают много денег. Что же на самом деле?

NewHR уже опубликовали 5 серий с результатами своего большого исследования overemployment — работы на несколько компаний одновременно. Я, как инфопартнёр, уже рассказывал про запуск этого опроса, а теперь делюсь с вами результатом!

📊 Ключевые результаты:
— 9% IT-специалистов практикуют фултайм overemployment на двух местах одновременно с сокрытием от работодателей.
— чаще всего вторую работу берут как раз таки мидлы и сеньоры тестировщики
— на вторую работу тратят 3-4 часа в день и часто делают это в рабочее время первой работы
— хоть основная цель - это и заработать больше денег, но часто это также способ профессионального развития
— большинство overemployment - это парттайм, пет-проекты, менторинг, то есть активности, которые легче совмещать с основной работой и можно даже делать это публично

👀 В самом исследовании — реальные кейсы, цифры по ролям, и даже советы, как вести двойную игру или вычислить такого сотрудника

📎 Первые пять серий исследования — по ссылке: https://newhr.org/data/overemployment-2024-2025

Идущий к офферу

Я в своей работе в QA настолько преисполнился, что как будто бы уже сто миллиардов проектов автотестами покрыл, прожил миллионы лет на тысячах таких же продуктовых и аутсорс-команд, где всё уже было: и микросервисы, и монолиты, и "вот тут чуть подфиксить".

Мне такие проекты абсолютно понятны, я здесь ищу только одного — покоя, умиротворения, стабильной зарплаты, открытого контура для регрессии и пулл-реквестов без конфликтов.

Я уже был во всём: в Jira, Confluence, Jenkins, Allure, GitHub Actions и Xray, я деплоил тесты в тьму серверов, проживал боль от flaky-тестов и "забыл прогреть окружение".

Где-то был QA-лидом, где-то сеньором, где-то просто моки писал на WireMock, а где-то тестили только прямо на проде, понимаешь?

Ты мне опять про "а какие у вас там технологии?", иди, суетись, ищи "динамичные команды и амбициозные задачи".
Это твой путь.
А мой — сидеть в тишине, в зуме с 5 людьми, где каждый знает, зачем он пришёл, и тест-кейсы не нужно каждый раз переписывать под очередную "экстренную фичу".

Я всё.
Я как бессмертный QA, прикоснувшийся к вечному @BeforeEach, увидевший смысл @Step("Проверяем, что оно не упало") и обретший просветление в "assertThat(actual).isEqualTo(expected)".

Так что давай, суетись, если хочется, а я пойду — запускать regression по крону и наслаждаться тишиной green-сборки на CI.

🔥 СРОЧНО! ЗАРАБОТОК МЕЧТЫ + СОЦИАЛЬНЫЙ ЛИФТ 💰💻
Осталось всего 2 МЕСТА! 😱

Работа из дома 🏠
До 200€ в день 💸 за всего 2–3 часа "работы" 🕒
Никаких вложений! 💯 Нужно только знать Java, SQL, автоматизацию Selenium, JUnit/TestNG, Linux, Docker, Kafka, BDD, AWS.

Ты устал:
😔 от начальника, который орёт?
😔 от жизни от ЗП до ЗП?
😔 от того, что мама не верит в твой успех?

✨ Прямо сейчас ты можешь:
✅ Наконец-то поесть
✅ Купить себе iPhone
✅ Написать своему начальнику на заводе что ты увольняешься

🚀 Ставь лайк на сообщение и пиши "ХОЧУ БАБЛО"
Поторопись! Осталось всего 2 места — потом лифт уедет без тебя!

А если серьезно, то AQA/SDET вакансии из моего прошлого поста все еще актуальны, если интересно — пиши мне в личку: @topsycreed

Увидел тут кодинг челлендж от QA Guru

Задание:

🧪 В проекте с автотестами на Rest Assured:

— Прокиньте токен из @BeforeAll во все тесты.
— Сделайте это без статики.
— Сохраните архитектурную чистоту (SOLID, KISS).

Накидал решение за часик, его успешно приняли — значит все еще достоин! 😅

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

Прошел сертификацию на госуслугах 😄

Читали новости про сертификацию айтишников? Теперь на госуслугах можно получить сертификаты от Минцифры, если пройти тесты на теорию и иногда и практику на платформе от hh.ru.

Для нас, инженеров по тестированию, есть курсы по знанию языков программирования: C#, Python, SQL, Java, PHP, JavaScript и другие.
А также 2 курса чисто для тестировщиков: Функциональное тестирование и Регрессионное тестирование

Я уже прошел Java на средний уровень, (для продвинутого было слишком много специфичной теории для разработчиков и тест я завалил). Также я прошел и кодинг часть, решил 3 из 4 задач за 25 минут. Задачки неплохие, как раз похожие дают на собеседованиях.

Как вам идея сертификации? Будете что-то проходить? Верите ли что эта бумажка что-то будет значить?

Вчера прошел первый день бесплатной онлайн конференции ProQuality Conference 2025, осталось еще четыре!

Видео с выступлениями уже есть на канале:
1️⃣ Maryia Tuleika: Surviving and Thriving with AI in QA
2️⃣ Alisa Petivotova: How to Start Testing from Scratch + Oleksandr Halichenko: Integrate Playwright and Cucumber with no Trade-offs

Успел пока посмотреть только первый доклад Марии. Понравится заход спикера разбавить напряженность в самом начале. Она начала доклад с того, что 200 лет назад на этот митап бы смогла прийти только половина из нас, так как вторая половина умерла бы из-за чумы 😅 Ну и еще цитата:

"We may end up in the world where there is no place for diversity, for care, for equity"

— страшно 🙃 вырубайте свои GPT пока мы еще не все потеряли.

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

Как учиться новому и стартовать новые продукты на примере шашлыка? 😋

В свои 34 годика я не умел готовить шашлык. Только есть. Причём на уровне Senior Eater, не меньше.
И вдруг мне захотелось попробовать новый формат общения: собираемся в парке, приносим еду, готовим мясо. Но как развить в себе этот навык?

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

🧪 CustDev и бета-тест
Дальше я провёл небольшой custdev, чтобы понять — интересно ли вообще кому-то такое?
Оказалось, что да. Я даже нашёл несколько человек, готовых записаться на бета-тест шашлыка.

🛒 Подготовка и логистика
Предстояло сделать ещё несколько шагов:
1) съездить на место и разведать локацию,
2) составить список покупок,
3) изучить магазины около дома и рядом с местом жарки.

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

⚠️ Неожиданные риски
И, конечно, не обошлось без сюрпризов:

Один из бета-тестеров не ест лук — пришлось мариновать мясо на киви.

В магазинах закончились решетки для жарки мяса — такие вещи в сезон улетают как творог в Белграде.

☔️ День Х
Всё было готово. В день Х я отправился на точку, чтобы занять место.
И тут новая проблема — я не взял наличку, а за въезд в парк нужно платить. Полезный инсайт на будущее.

А ещё пошёл лёгкий дождь, которого не было в прогнозе. Как будто сама природа не хотела, чтобы Гена научился делать шашлык.
Злой рок мешал мне, как герою Джеймса Франко в 11.22.63. Но дождь прошёл, и всё получилось! И свиной, и куриный шашлыки удались.

✅ Завершение спринта
Оставалось:
1) закончить тестирование приготовленного мяса,
2) собрать обратную связь от участников,
3) порефлексировать над проведённым экспериментом.

Теперь можно готовиться к внедрению шашлыка на прод 😄

🤰 Постэффект
Что было дальше?
Я сходил ещё на два шашлыка за выходные, объелся… и как будто бы мне уже шашлыков больше не надо 😅

📝 Вывод
Надеюсь, моя история была поучительной.
Учиться новому, валидировать идеи, планировать, учитывать риски, внедрять и дорабатывать — навыки, которые полезны не только в IT 😉

Регистрация на оффлайн QA Meetup в Белграде открыта! 🎉

У нас 23 мая — новый QA митап в Белграде от Serbian QA Hub (на английском языке), и это отличный повод стать частью комьюнити — или вернуться в него!

🪪 На бейджике мы оставили место для твоего имени — приходи и впиши его!
Тебя ждут живые выступления, интересные знакомства и конечно же 🍕

📅 Когда: 23 мая, 18:00 – 21:00
🌍 Язык: английский
🚪 Вход: по регистрации, бесплатно (донаты приветствуются)
📩 Подтверждение придёт на почту 19 мая

🤝 Митап проходит при поддержке QA Guru, и лично к нам приедет его основатель — Станислав Васенков!

Спикеры митапа:
🌟 Slavica Mastilović Sulica — "Authentication testing: Make sure only the right people can enter, stay, and act safely inside the system!"
🌟 Sergei Faliuta — "Small Steps, Big Impact: How QA Can Improve Processes"
🌟 Stanislav Vasenkov — "Manual ♥️ Auto: A QA Love Story"

📍 Нас снова принимает CDT HUB — спасибо им за это ❤️‍🔥
После докладов — время для нетворкинга и общения!

📌 Регистрация уже открыта:
👉 Заполнить форму

📬 Вопросы? Пиши в личку @serbian_qa

P.S. В этот раз планирую сделать и онлайн трансляцию докладов 📱

🔥 Нагрузочное и перфоманс-тестирование становятся всё более актуальными — вот уже на двух моих последних проектах автоматизатора эти задачи входили в мою зону ответственности.

⚙️ 9 сентября пройдёт PerfConf 2025 — крупнейшая российская оффлайн/онлайн конференция по нагрузочному тестированию и не только. В этом году она состоится уже в 11-й раз, и я рад быть инфопартнёром события.

Темы конференции:
🔸 нагрузочное тестирование
🔸 хаос-инжиниринг
🔸 оптимизация и тюнинг
🔸 DevOps, CI/CD, SRE
🔸 мониторинг и надёжность
🔸 ИИ в анализе и прогнозировании
🔸 управление командами
🔸 реальные кейсы и тренды

🎤 И да, вы ещё успеваете податься в спикеры — отличная возможность прокачать профессиональный бренд!

📺 А если хочется уже сейчас погрузиться в тему — на канале Serbian QA Hub вышел воркшоп по JMeter, а прямо сейчас проходит оффлайн курс в Белграде.

📎 Подробнее о конференции: https://perfconf.ru

Привет! В компании Orion Innovation, где я сейчас работаю, открылись вакансии для QA и SDET-инженеров. Локация — Сербия, возможна релокация.

Описание вакансий:

🔹 SDET (Software Development Engineer in Test)
Looking for someone strong in Java, API testing, front-end automation (Selenium, JUnit/TestNG), with experience in building and supporting automation frameworks. You’ll be working closely with devs, helping drive quality across the pipeline, and promoting continuous testing practices.

📌 Must-have: 3+ years in automation, confident in Linux, SQL, and testing tools.
Bonus if you’ve worked with Gatling, or enjoy building tools from scratch.

🔹 SQE (Software Quality Engineer)
This one’s for a team working on cutting-edge genetic products. A mix of manual + automation testing, plus building frameworks, analyzing complex systems, and being deeply involved across the SDLC.

📌 Ideal profile: 5+ years of QA experience, automation background, solid with Selenium, SQL, scripting, Linux, and understanding of both frontend/backend testing.

Если интересно — пиши мне в личку: @topsycreed

Зарегистрировался на ProQuality Conference 2025 — это бесплатная онлайн-конференция про тестирование, автоматизацию и применение AI.

Я сам недавно готовил доклад про генерацию автотестов для Heisenbug. Доклад в итоге так и остался в резерве конференции, так что пишите если интересно про это почитать. А теперь хочу посмотреть как еще применяют AI в тестировании, а тут аж 6 докладов про это! Про классическое тестирование и автоматизацию пока еще тоже есть доклады 😅 но тренд на 50% докладов про AI о многом говорит.

📅 Конференция проходит с 2 по 6 июня, каждый день по 2 слота: утром и вечером. Всего — 5 дней, 12 докладов. Все доклады будут на английском.

👉 Вот ссылка на регистрацию

После конференции можно обсудить доклады в чате, поделимся инсайтами!

Мой недельный пет-проект подошёл к концу 🐾

Кто не знал — моя настоящая профессия, конечно же, пет-ситтер! А тестирование у меня это так, для души.
На этот раз была неделя с очаровательным котом Оскаром.

Если вы в Белграде и ищете того, кто посидит с кошкой или собакой — пишите!
Дополнительные услуги:
📷 профессиональная котосессия
🎨 стикерпак и мемы с вашим питомцем

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

Доклад "Менторство как ключ к профессиональному успеху"

Ровно год назад прошёл первый митап сообщества Serbian QA Hub — событие, которое мы готовили с нуля, и которое стало отправной точкой для целой серии крутых встреч. Я тогда участвовал сразу в двух ролях: со-организатора и спикера.

🎤 На митапе я рассказывал о менторстве как ключе к профессиональному росту.
С 2018 года я менторю начинающих и опытных инженеров, а с 2021 года — делаю это и как профессиональную деятельность.

📈 Именно менторство стало одной из причин, почему я так быстро вырос в Grid Dynamics — от Junior до Staff QA и инженерного менеджера. Оно помогло мне прокачаться и в хард скиллах, и в софт скиллах, научило лучше слушать, объяснять и вдохновлять.

👀 Если тебе, как и мне тогда, тесно в рамках должности QA-инженера / разработчика / лида и ты хочешь делиться опытом и развивать других — обязательно глянь мой доклад.

В нём:
1️⃣ кто такой ментор;
2️⃣ как начать менторить;
3️⃣ зачем тебе это нужно;
4️⃣ сколько зарабатывают менторы (да, и про деньги тоже поговорим);
5️⃣ немного статистики по рынку.

📽 Посмотреть доклад можно тут: Youtube и GoogleDrive

P.S. Напиши, если узнал менторов, про которых я сделал тот самый слайд с Траволтой в замешательстве 😅

У Bas Dijkstra новый пост про тестирование API: Как вы проверяете большие ответы в своих API-тестах?

В прошлый раз мы обсуждали стратегию тестирования API, почитать можно по ссылке.
Теперь давайте разбираться как проверять ответы если у вас Java, у меня есть что дополнить по этой теме!

Список подходов по мнению Баса:

🔍 Approval testing (сравнение с эталоном)
Если у вас есть заранее известный корректный ожидаемый ответ, можно сравнивать его с фактическим целиком, вместо проверки каждого отдельного элемента.
❗️Минусы: придётся как-то обрабатывать изменяющиеся поля (уникальные ID, поля с датой и т.д.). Также, если ответ содержит списки, то такая проверка может ломаться при изменении порядка элементов в списке, даже если их содержимое не менялось.
💡Мое дополнение: применял данный подход на самом старте API автоматизации, хранил expectedResponses в отдельной папке и использовал библиотеку JSONAssert, которая позволяет исключить сравнение по какому-то полю через CustomComparator (StackOverflow). Также есть режим JSONCompareMode.LENIENT, позволяющий игнорировать порядок полей и лишние поля (например, Id, даты и прочее можно не добавлять в expected json). Минус: не проверите контракт этих полей и не среагируете на новые поля.

📉 Сокращение объёма ответа
Если ответ содержит длинные списки с десятками или сотнями элементов, можно попытаться изменить тестовые данные так, чтобы возвращалось, например, всего 3 элемента.
❗️Минусы: зависит от того, насколько у вас есть контроль над данными. Кроме того, при таком подходе можно пропустить некоторые баги, которые проявляются только при большом количестве элементов.
💡 Мое дополнение: тут особо добавить нечего, все так. Обычно в пре-реквизитах и пост-шагах создаем тестовые данные, очищаем предыдущие, чтобы в самих тестах не было ничего лишнего в ответах.

📦 Десериализация
Преобразование JSON или XML-ответа в объекты может позволить реализовать более умные и структурированные ассерты.
❗️Минусы: скорее всего, придётся писать кастомные проверки или обрабатывать объекты вручную.
💡 Мое дополнение: это мой основной способ работы с API ответами. Часто эти модельки (DTO классы) пригодятся и для создания в самих запросах. Существуют сервисы, которые генерируют эти классы на основе JSON или схемы, например: jsonschema2pojo. Кастомные проверки можно делать уже средствами JUnit 5, TestNG или AssertJ. Можно использовать SoftAssertions либо даже сделать проверки в виде steps и логировать это в Allure. Есть и другие подходы, например, Fluent Interface/method chaining.

🧩 Переосмысление дизайна API
А действительно ли API должен возвращать столько полей? Может быть, стоит переосмыслить его структуру?
Большие ответы могут быть признаком не самого лучшего дизайна API и даже увеличивать риск уязвимостей вроде Broken Object Property Level Authorisation или Excessive Data Exposure.
❗️Минусы: вероятность того, что команда разработки или продуктовая команда согласятся на изменения — низкая, особенно если API уже активно используется другими системами.
💡 Мое дополнение: у меня был опыт работы в команде, которая пилила монолит на микросервисы и оптимизировала часть ответов. Для синхронизации с другими системами я внедрял контрактное тестирование. С его помощью можно было проверить, что изменения в нашем сервисе не ломают тесты другим командам.

💡 Добавлю еще варианты от себя:
• Тестирование с помощью then блока самого RestAssured. Под капотом используется Hamcrest, вариант подходит, если из большого ответа нужно проверять только часть. Например, ответ вернул всю информацию о корзине товаров на E-commerce сайте, а вам нужно проверить только количество товара с 1 на 2.

then().body("quantity", equalTo(2));

• Через RestAssured можно и схему сравнить:

then().body(matchesJsonSchemaInClasspath("jsonSchema/petSchema.json"));

• В AssertJ есть возможность сравнить 2 объекта с указанием, какие поля нужно игнорировать:

assertThat(actualUser).usingRecursiveComparison().ignoringFields("id").isEqualTo(expectedUser);

Больше примеров можно найти в одном из моих проектов с курса по автоматизации: SimpleAPITests и ExtendedAPITests