Коллеги, привет! 👋🏻
8 февраля приглашаю вас на бесплатный онлайн воркшоп 🎓 "Построение фреймворка автоматизации на Java с нуля".
📅 Когда: 8 февраля
⏰ Во сколько: 14:00 (МСК)
⏳ Длительность: 3 часа
🌍 Язык: Русский
🏢 Где: Онлайн (MS Teams) 🔗 Присоединиться
🎤 Спикер: Геннадий Чурсов
О чем воркшоп? 🤔
Разберем с нуля создание фреймворка для UI и API тестирования на Java. Будет много практики, а на каждый шаг — теория и примеры кода, которые можно будет пошагово повторить после мастер-класса.
🚀 Что будем делать?
✅ Создадим проект и опубликуем его в GitHub
✅ Подключим зависимости и настроим окружение
✅ Напишем и запустим первый API тест
✅ Разберем параметризацию тестов и сериализацию объектов в JSON
✅ Напишем и запустим первый UI тест (Selenium)
✅ Добавим Page Object Model (POM), ожидания и property-файлы
✅ Настроим запуск тестов через командную строку
✅ Внедрим Allure-отчеты
✅ Настроим CI/CD в GitHub Actions
📌 Как подготовиться?
Перед воркшопом установите IntelliJ IDEA (Community или Ultimate) и создайте профиль в GitHub.
📹 Запись будет, но приходите вживую – так интереснее и полезнее!
📆 Воркшоп будет проходить в рамках Serbian QA Hub, чтобы не пропустить мастер-класс подпишитесь на мероприятия Serbian QA Hub в Google календаре.
❓ Вопросы – пишите Геннадию Чурсову.
Ставьте 💻 если придете на воркшоп! До встречи! 🚀
8 февраля приглашаю вас на бесплатный онлайн воркшоп 🎓 "Построение фреймворка автоматизации на Java с нуля".
📅 Когда: 8 февраля
⏰ Во сколько: 14:00 (МСК)
⏳ Длительность: 3 часа
🌍 Язык: Русский
🏢 Где: Онлайн (MS Teams) 🔗 Присоединиться
🎤 Спикер: Геннадий Чурсов
О чем воркшоп? 🤔
Разберем с нуля создание фреймворка для UI и API тестирования на Java. Будет много практики, а на каждый шаг — теория и примеры кода, которые можно будет пошагово повторить после мастер-класса.
🚀 Что будем делать?
✅ Создадим проект и опубликуем его в GitHub
✅ Подключим зависимости и настроим окружение
✅ Напишем и запустим первый API тест
✅ Разберем параметризацию тестов и сериализацию объектов в JSON
✅ Напишем и запустим первый UI тест (Selenium)
✅ Добавим Page Object Model (POM), ожидания и property-файлы
✅ Настроим запуск тестов через командную строку
✅ Внедрим Allure-отчеты
✅ Настроим CI/CD в GitHub Actions
📌 Как подготовиться?
Перед воркшопом установите IntelliJ IDEA (Community или Ultimate) и создайте профиль в GitHub.
📹 Запись будет, но приходите вживую – так интереснее и полезнее!
📆 Воркшоп будет проходить в рамках Serbian QA Hub, чтобы не пропустить мастер-класс подпишитесь на мероприятия Serbian QA Hub в Google календаре.
❓ Вопросы – пишите Геннадию Чурсову.
Ставьте 💻 если придете на воркшоп! До встречи! 🚀
👨💻62🔥47👍11❤1⚡1
Forwarded from Serbian QA Hub (Organizer)
📢 8 февраля Serbian QA Hub провели первый онлайн мастер-класс по теме "Построение фреймворка автоматизации на Java с нуля".
🎤 Спасибо спикеру Геннадию Чурсову за проведение мастер-класса! И Екатерине за помощь с организацией.
В рамках МК были:
✅ Теория и разбор реальных кейсов
✅ Много практики с пошаговым объяснением
📄 Полезные материалы:
Пошаговый план с примерами кода
Готовый фреймворк на GitHub (разбит на ветки по шагам)
👥 На мастер-класс пришло более 90 участников! Если вы не смогли присоединиться, запись доступна на YouTube.
📢 Просим участников пройти небольшой опрос — он поможет нам сделать будущие мероприятия еще лучше. Также можно указать данные для именного сертификата. Будем рады, если поделитесь им и отзывами в соцсетях, отметив Serbian QA Hub и спикера.
📅 Следите за новыми мастер-классами!
Подписывайтесь на Google Календарь мероприятий и соцсети, чтобы не пропустить их.
До встречи на следующих событиях нашего сообщества Serbian QA Hub!
🎤 Спасибо спикеру Геннадию Чурсову за проведение мастер-класса! И Екатерине за помощь с организацией.
В рамках МК были:
✅ Теория и разбор реальных кейсов
✅ Много практики с пошаговым объяснением
📄 Полезные материалы:
Пошаговый план с примерами кода
Готовый фреймворк на GitHub (разбит на ветки по шагам)
👥 На мастер-класс пришло более 90 участников! Если вы не смогли присоединиться, запись доступна на YouTube.
📢 Просим участников пройти небольшой опрос — он поможет нам сделать будущие мероприятия еще лучше. Также можно указать данные для именного сертификата. Будем рады, если поделитесь им и отзывами в соцсетях, отметив Serbian QA Hub и спикера.
📅 Следите за новыми мастер-классами!
Подписывайтесь на Google Календарь мероприятий и соцсети, чтобы не пропустить их.
До встречи на следующих событиях нашего сообщества Serbian QA Hub!
👍33🔥15⚡1❤1
Отправил сертификаты онлайн-участникам мастер-класса «Построение фреймворка на Java с нуля»
Также хочу поделиться первыми отзывами — спасибо, что пришли онлайн и так высоко оценили мастер-класс. Я вложил в него много сил и времени, и очень рад, что он оказался полезен для вас.
Если вы были на мастер-классе еще можете заполнить отзыв, чтобы получить сертификат участника.
Также хочу поделиться первыми отзывами — спасибо, что пришли онлайн и так высоко оценили мастер-класс. Я вложил в него много сил и времени, и очень рад, что он оказался полезен для вас.
Если вы были на мастер-классе еще можете заполнить отзыв, чтобы получить сертификат участника.
🔥52❤4
Завершил сразу два потока программы Women in Tech: 5-й поток Women in Tech Belarus и 6-й поток Women in Tech Russia, где выступал в роли ментора. По итогам получил сертификаты за активное участие.
Этот опыт стал для меня важной вехой: было интересно сравнить подходы разных команд Women in Tech и почувствовать выход на международный уровень. В этом году столкнулся с определёнными сложностями в работе с менти, но преодоление этих трудностей помогло мне самому выйти на новый уровень как наставника. Надеюсь, что мои советы и поддержка также были полезны моим менти. В прошлом году у меня их было трое, и этот опыт продолжает вдохновлять меня на дальнейшее развитие.
Настоятельно рекомендую всем пробовать себя в подобных программах, как в роли ментора, так и менти. Это отличный шанс прокачать свои навыки, узнать новые подходы, расширить кругозор и завести ценные знакомства.
Этот опыт стал для меня важной вехой: было интересно сравнить подходы разных команд Women in Tech и почувствовать выход на международный уровень. В этом году столкнулся с определёнными сложностями в работе с менти, но преодоление этих трудностей помогло мне самому выйти на новый уровень как наставника. Надеюсь, что мои советы и поддержка также были полезны моим менти. В прошлом году у меня их было трое, и этот опыт продолжает вдохновлять меня на дальнейшее развитие.
Настоятельно рекомендую всем пробовать себя в подобных программах, как в роли ментора, так и менти. Это отличный шанс прокачать свои навыки, узнать новые подходы, расширить кругозор и завести ценные знакомства.
🔥41👍14❤8🤪2⚡1
🔍 Лучшие Telegram-каналы про тестирование в одном месте!
С коллегами провели ревью QA-каналов и собрали в одну папку только те, где:
✅ Есть уникальный авторский контент
🚫 Нет бесконечной рекламы
📌 Реально полезно для тестировщиков
📢 Подписывайтесь и экономьте время на поиск качественных каналов:
👉 Добавить подборку
С коллегами провели ревью QA-каналов и собрали в одну папку только те, где:
✅ Есть уникальный авторский контент
🚫 Нет бесконечной рекламы
📌 Реально полезно для тестировщиков
📢 Подписывайтесь и экономьте время на поиск качественных каналов:
👉 Добавить подборку
🔥24💊2
Что посмотреть на выходных? Конечно же запись выступлений с митапа Serbian QA Hub
Forwarded from Serbian QA Hub (Organizer)
Всем привет!
Sergey Salyk и Gennadii Chursov подготовили записи докладов с митапа Serbian QA Hub х JetBrains 14 февраля. Давайте посмотрим, как это было! 🎥
🎤 Артем Чугуев - “Автоматизация тестирования IDE на примере JetBrains Rider”
🎤 Игорь Плавуцкий - "QA в робототехнике или незнакомая сторона тестирования"
🎤 Данил Бирюков-Романов - в тандеме с супругой Анной - "Проблемы роста QA или кукуха улетает первой".
Если хотите выступить на следующих митапах на русском или английском языке, оставляйте заявку [здесь]
Будем рады, если поделитесь отзывами о митапе и докладах в LinkedIn, отметив Serbian QA Hub и спикеров.
До новых встреч на митапах! 🚀
Sergey Salyk и Gennadii Chursov подготовили записи докладов с митапа Serbian QA Hub х JetBrains 14 февраля. Давайте посмотрим, как это было! 🎥
🎤 Артем Чугуев - “Автоматизация тестирования IDE на примере JetBrains Rider”
🎤 Игорь Плавуцкий - "QA в робототехнике или незнакомая сторона тестирования"
🎤 Данил Бирюков-Романов - в тандеме с супругой Анной - "Проблемы роста QA или кукуха улетает первой".
Если хотите выступить на следующих митапах на русском или английском языке, оставляйте заявку [здесь]
Будем рады, если поделитесь отзывами о митапе и докладах в LinkedIn, отметив Serbian QA Hub и спикеров.
До новых встреч на митапах! 🚀
❤26👍4🤔2⚡1
💡 Недавно наткнулся на на пост в LinkedIn про стратегию тестирования REST API от Bas Dijkstra.
Согласен с основными подходами и хочу выделить ключевые чек-листы, которые стоит учитывать при тестировании REST API на основе поста Баса и моего опыта.
🔥 Smoke-тесты (базовая проверка работоспособности API)
✅ Отправка корректного запроса с валидными данными → API возвращает ожидаемый HTTP статус (201, 200)
✅ Данные успешно сохраняются и доступны через GET-запрос
✅ Запрос без обязательного заголовка (например, Content-Type: application/json) → API корректно обрабатывает или возвращает ошибку
🚀 Позитивные тест-кейсы
🔹 Отправка запроса с минимально необходимым набором данных
🔹 Отправка запроса с максимальным набором данных (включая необязательные поля)
🔹 Ввод данных в разных поддерживаемых кодировках
🔹 Обработка граничных значений (минимальные/максимальные числа, даты)
🔹 Проверка идемпотентности, если API должно поддерживать повторные запросы без дублирования данных
💻 Обработка данных
🔹 Проверить, что отправленные данные корректно сохраняются
🔹 Убедиться, что данные можно корректно получить обратно
🔹 Убедиться, что некорректные данные фильтруются или отклоняются
🔹 Проверить обработку больших объемов данных
⚠️ Негативные тест-кейсы
🔻 Вариации данных
❌ Проверить отсутствие обязательных полей по одиночке
❌ Полностью исключить обязательные поля
❌ Передать некорректные значения (например, текст вместо числа)
❌ Использовать слишком длинные значения
❌ Добавить нестандартные символы (эмодзи, диакритика и т. д.)
🔻 Инъекции
❌ Попробовать внедрить JavaScript
❌ Попробовать SQL-инъекцию
❌ Попробовать выполнить серверные команды
🔻 Аутентификация
❌ Вызов без токена
❌ Вызов с недействительным токеном
❌ Вызов с токеном, у которого нет нужных прав
❌ Вызов с истекшим токеном
🔻 Ошибки и сообщения
❌ Убедиться, что возвращаемые HTTP-статусы логичны
❌ Проверить, что ошибки в ответах понятны
❌ Убедиться, что сообщения об ошибках не раскрывают лишнюю информацию (stack trace, подсказки, детали реализации)
📜 Контрактные тесты
🔍 Проверить соответствие API контракту (OpenAPI/Swagger)
🔍 Проверить, что API не ломает обратную совместимость при обновлениях
🔍 Убедиться, что типы данных в ответах соответствуют спецификации
🌪 Chaos-тестирование
💥 Остановить случайные сервисы, от которых зависит API, и проверить корректность обработки ошибок
💥 Использовать инструменты типа Chaos Monkey для моделирования отказов инфраструктуры
💥 Проверить, как API реагирует на отказ базы данных (например, недоступность PostgreSQL/MySQL)
⚡️ Нагрузочное тестирование
📌 Load Testing – проверка производительности API под прогнозируемой нагрузкой
📌 Stress Testing – работа API в экстремальных условиях и предельных нагрузках
📌 Performance Testing – замер скорости отклика и производительности при различных условиях
Также по теме нашел еще несколько чек-листов от других авторов:
1️⃣ Чек-лист API тестов от Parviz Khavari
2️⃣ Как тестировать методы REST API от Ольга Назина
3️⃣ Google таблица API тест-кейсы и чек-лист на примере petstore от Надежды Дудник
Такой список поможет сделать тестирование API более структурированным и эффективным. А какие чек-листы используете вы? 🚀
Согласен с основными подходами и хочу выделить ключевые чек-листы, которые стоит учитывать при тестировании REST API на основе поста Баса и моего опыта.
🔥 Smoke-тесты (базовая проверка работоспособности API)
✅ Отправка корректного запроса с валидными данными → API возвращает ожидаемый HTTP статус (201, 200)
✅ Данные успешно сохраняются и доступны через GET-запрос
✅ Запрос без обязательного заголовка (например, Content-Type: application/json) → API корректно обрабатывает или возвращает ошибку
🚀 Позитивные тест-кейсы
🔹 Отправка запроса с минимально необходимым набором данных
🔹 Отправка запроса с максимальным набором данных (включая необязательные поля)
🔹 Ввод данных в разных поддерживаемых кодировках
🔹 Обработка граничных значений (минимальные/максимальные числа, даты)
🔹 Проверка идемпотентности, если API должно поддерживать повторные запросы без дублирования данных
💻 Обработка данных
🔹 Проверить, что отправленные данные корректно сохраняются
🔹 Убедиться, что данные можно корректно получить обратно
🔹 Убедиться, что некорректные данные фильтруются или отклоняются
🔹 Проверить обработку больших объемов данных
⚠️ Негативные тест-кейсы
🔻 Вариации данных
❌ Проверить отсутствие обязательных полей по одиночке
❌ Полностью исключить обязательные поля
❌ Передать некорректные значения (например, текст вместо числа)
❌ Использовать слишком длинные значения
❌ Добавить нестандартные символы (эмодзи, диакритика и т. д.)
🔻 Инъекции
❌ Попробовать внедрить JavaScript
❌ Попробовать SQL-инъекцию
❌ Попробовать выполнить серверные команды
🔻 Аутентификация
❌ Вызов без токена
❌ Вызов с недействительным токеном
❌ Вызов с токеном, у которого нет нужных прав
❌ Вызов с истекшим токеном
🔻 Ошибки и сообщения
❌ Убедиться, что возвращаемые HTTP-статусы логичны
❌ Проверить, что ошибки в ответах понятны
❌ Убедиться, что сообщения об ошибках не раскрывают лишнюю информацию (stack trace, подсказки, детали реализации)
📜 Контрактные тесты
🔍 Проверить соответствие API контракту (OpenAPI/Swagger)
🔍 Проверить, что API не ломает обратную совместимость при обновлениях
🔍 Убедиться, что типы данных в ответах соответствуют спецификации
🌪 Chaos-тестирование
💥 Остановить случайные сервисы, от которых зависит API, и проверить корректность обработки ошибок
💥 Использовать инструменты типа Chaos Monkey для моделирования отказов инфраструктуры
💥 Проверить, как API реагирует на отказ базы данных (например, недоступность PostgreSQL/MySQL)
⚡️ Нагрузочное тестирование
📌 Load Testing – проверка производительности API под прогнозируемой нагрузкой
📌 Stress Testing – работа API в экстремальных условиях и предельных нагрузках
📌 Performance Testing – замер скорости отклика и производительности при различных условиях
Также по теме нашел еще несколько чек-листов от других авторов:
Такой список поможет сделать тестирование API более структурированным и эффективным. А какие чек-листы используете вы? 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍36🔥21❤8
Почему на первое апреля у QA инженеров не принято вместо у тебя спина белая использовать вариант "у тебя тесты красные"? 😅
😁38💯6🔥5
В LinkedIn спросили про курсы автоматизации на Java. В комментариях поделились советами, в основном упоминали RedRover.school, но был также комментарий и про мой курс! ❤️ Спасибо!
По самой Java как обычно упоминают Java Rush курс, а также Основы Java от Хекслета
Среди авторов выделили:
1️⃣ Дмитрий Тучс - курс Java на QA Guru, а также советую его публичные выступления: JUnit Extensions и gRPC
2️⃣ Олег Пендрак - ютуб канал про автоматизацию на Java, а еще недавно у него стартовал курс по автоматизации тестирования iOS
3️⃣ Авторы по чисто Java: Тагир Валеев (курс Computer Science Center) и Сергей Немчинский
Также напомню, что уже делал два поста с рекомендациями:
Часть 1 с моими рекомендациями 👈🏻
Часть 2 с рекомендациями от участников канала 👈🏻
По самой Java как обычно упоминают Java Rush курс, а также Основы Java от Хекслета
Среди авторов выделили:
Также напомню, что уже делал два поста с рекомендациями:
Часть 1 с моими рекомендациями 👈🏻
Часть 2 с рекомендациями от участников канала 👈🏻
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥42❤5👍5
У 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.
• Через RestAssured можно и схему сравнить:
• В AssertJ есть возможность сравнить 2 объекта с указанием, какие поля нужно игнорировать:
Больше примеров можно найти в одном из моих проектов с курса по автоматизации: SimpleAPITests и ExtendedAPITests
В прошлый раз мы обсуждали стратегию тестирования 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
👍9🔥5
Доклад "Менторство как ключ к профессиональному успеху"
Ровно год назад прошёл первый митап сообщества Serbian QA Hub — событие, которое мы готовили с нуля, и которое стало отправной точкой для целой серии крутых встреч. Я тогда участвовал сразу в двух ролях: со-организатора и спикера.
🎤 На митапе я рассказывал о менторстве как ключе к профессиональному росту.
С 2018 года я менторю начинающих и опытных инженеров, а с 2021 года — делаю это и как профессиональную деятельность.
📈 Именно менторство стало одной из причин, почему я так быстро вырос в Grid Dynamics — от Junior до Staff QA и инженерного менеджера. Оно помогло мне прокачаться и в хард скиллах, и в софт скиллах, научило лучше слушать, объяснять и вдохновлять.
👀 Если тебе, как и мне тогда, тесно в рамках должности QA-инженера / разработчика / лида и ты хочешь делиться опытом и развивать других — обязательно глянь мой доклад.
В нём:
1️⃣ кто такой ментор;
2️⃣ как начать менторить;
3️⃣ зачем тебе это нужно;
4️⃣ сколько зарабатывают менторы (да, и про деньги тоже поговорим);
5️⃣ немного статистики по рынку.
📽 Посмотреть доклад можно тут: Youtube и GoogleDrive
P.S. Напиши, если узнал менторов, про которых я сделал тот самый слайд с Траволтой в замешательстве 😅
Ровно год назад прошёл первый митап сообщества Serbian QA Hub — событие, которое мы готовили с нуля, и которое стало отправной точкой для целой серии крутых встреч. Я тогда участвовал сразу в двух ролях: со-организатора и спикера.
🎤 На митапе я рассказывал о менторстве как ключе к профессиональному росту.
С 2018 года я менторю начинающих и опытных инженеров, а с 2021 года — делаю это и как профессиональную деятельность.
📈 Именно менторство стало одной из причин, почему я так быстро вырос в Grid Dynamics — от Junior до Staff QA и инженерного менеджера. Оно помогло мне прокачаться и в хард скиллах, и в софт скиллах, научило лучше слушать, объяснять и вдохновлять.
👀 Если тебе, как и мне тогда, тесно в рамках должности QA-инженера / разработчика / лида и ты хочешь делиться опытом и развивать других — обязательно глянь мой доклад.
В нём:
📽 Посмотреть доклад можно тут: Youtube и GoogleDrive
P.S. Напиши, если узнал менторов, про которых я сделал тот самый слайд с Траволтой в замешательстве 😅
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21❤4👍3
Мой недельный пет-проект подошёл к концу 🐾
Кто не знал — моя настоящая профессия, конечно же, пет-ситтер! А тестирование у меня это так, для души.
На этот раз была неделя с очаровательным котом Оскаром.
Если вы в Белграде и ищете того, кто посидит с кошкой или собакой — пишите!
Дополнительные услуги:
📷 профессиональная котосессия
🎨 стикерпак и мемы с вашим питомцем
А у вас какие хобби вне работы?
Кто не знал — моя настоящая профессия, конечно же, пет-ситтер! А тестирование у меня это так, для души.
На этот раз была неделя с очаровательным котом Оскаром.
Если вы в Белграде и ищете того, кто посидит с кошкой или собакой — пишите!
Дополнительные услуги:
📷 профессиональная котосессия
🎨 стикерпак и мемы с вашим питомцем
А у вас какие хобби вне работы?
🔥41❤25😁19👍7
Зарегистрировался на ProQuality Conference 2025 — это бесплатная онлайн-конференция про тестирование, автоматизацию и применение AI.
Я сам недавно готовил доклад про генерацию автотестов для Heisenbug. Доклад в итоге так и остался в резерве конференции, так что пишите если интересно про это почитать. А теперь хочу посмотреть как еще применяют AI в тестировании, а тут аж 6 докладов про это! Про классическое тестирование и автоматизацию пока еще тоже есть доклады 😅 но тренд на 50% докладов про AI о многом говорит.
📅 Конференция проходит с 2 по 6 июня, каждый день по 2 слота: утром и вечером. Всего — 5 дней, 12 докладов. Все доклады будут на английском.
👉 Вот ссылка на регистрацию
После конференции можно обсудить доклады в чате, поделимся инсайтами!
Я сам недавно готовил доклад про генерацию автотестов для Heisenbug. Доклад в итоге так и остался в резерве конференции, так что пишите если интересно про это почитать. А теперь хочу посмотреть как еще применяют AI в тестировании, а тут аж 6 докладов про это! Про классическое тестирование и автоматизацию пока еще тоже есть доклады 😅 но тренд на 50% докладов про AI о многом говорит.
📅 Конференция проходит с 2 по 6 июня, каждый день по 2 слота: утром и вечером. Всего — 5 дней, 12 докладов. Все доклады будут на английском.
👉 Вот ссылка на регистрацию
После конференции можно обсудить доклады в чате, поделимся инсайтами!
🔥22❤5👍3