Channel: Геннадий Чурсов | QA++
🔍 Лучшие 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👍3🤔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
👍35🔥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
🔥41❤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❤24😁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
Привет! В компании Orion Innovation, где я сейчас работаю, открылись вакансии для QA и SDET-инженеров. Локация — Сербия, возможна релокация.
Описание вакансий:
Если интересно — пиши мне в личку: @topsycreed
Описание вакансий:
🔹 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
❤20👍1🤯1
🔥 Нагрузочное и перфоманс-тестирование становятся всё более актуальными — вот уже на двух моих последних проектах автоматизатора эти задачи входили в мою зону ответственности.
⚙️ 9 сентября пройдёт PerfConf 2025 — крупнейшая российская оффлайн/онлайн конференция по нагрузочному тестированию и не только. В этом году она состоится уже в 11-й раз, и я рад быть инфопартнёром события.
Темы конференции:
🔸 нагрузочное тестирование
🔸 хаос-инжиниринг
🔸 оптимизация и тюнинг
🔸 DevOps, CI/CD, SRE
🔸 мониторинг и надёжность
🔸 ИИ в анализе и прогнозировании
🔸 управление командами
🔸 реальные кейсы и тренды
🎤 И да, вы ещё успеваете податься в спикеры — отличная возможность прокачать профессиональный бренд!
📺 А если хочется уже сейчас погрузиться в тему — на канале Serbian QA Hub вышел воркшоп по JMeter, а прямо сейчас проходит оффлайн курс в Белграде.
📎 Подробнее о конференции: https://perfconf.ru
⚙️ 9 сентября пройдёт PerfConf 2025 — крупнейшая российская оффлайн/онлайн конференция по нагрузочному тестированию и не только. В этом году она состоится уже в 11-й раз, и я рад быть инфопартнёром события.
Темы конференции:
🔸 нагрузочное тестирование
🔸 хаос-инжиниринг
🔸 оптимизация и тюнинг
🔸 DevOps, CI/CD, SRE
🔸 мониторинг и надёжность
🔸 ИИ в анализе и прогнозировании
🔸 управление командами
🔸 реальные кейсы и тренды
🎤 И да, вы ещё успеваете податься в спикеры — отличная возможность прокачать профессиональный бренд!
📺 А если хочется уже сейчас погрузиться в тему — на канале Serbian QA Hub вышел воркшоп по JMeter, а прямо сейчас проходит оффлайн курс в Белграде.
📎 Подробнее о конференции: https://perfconf.ru
👍16❤4
Регистрация на оффлайн 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. В этот раз планирую сделать и онлайн трансляцию докладов📱
У нас 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. В этот раз планирую сделать и онлайн трансляцию докладов
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8
Как учиться новому и стартовать новые продукты на примере шашлыка? 😋
В свои 34 годика я не умел готовить шашлык. Только есть. Причём на уровне Senior Eater, не меньше.
И вдруг мне захотелось попробовать новый формат общения: собираемся в парке, приносим еду, готовим мясо. Но как развить в себе этот навык?
🔍 Первое исследование
Первое, что я сделал — это сходил на день рождения своей коллеги, где записал весь процесс приготовления шашлыка: задал нужные вопросы и даже немного поучаствовал — махал над углями, раздувая пламя.
🧪 CustDev и бета-тест
Дальше я провёл небольшой custdev, чтобы понять — интересно ли вообще кому-то такое?
Оказалось, что да. Я даже нашёл несколько человек, готовых записаться на бета-тест шашлыка.
🛒 Подготовка и логистика
Предстояло сделать ещё несколько шагов:
1) съездить на место и разведать локацию,
2) составить список покупок,
3) изучить магазины около дома и рядом с местом жарки.
Сразу стало ясно: в одиночку хорошая посиделка не выйдет — нужно раскидать ответственность между участниками. Тут пригодились и лидерские качества, и инициативность.
⚠️ Неожиданные риски
И, конечно, не обошлось без сюрпризов:
Один из бета-тестеров не ест лук — пришлось мариновать мясо на киви.
В магазинах закончились решетки для жарки мяса — такие вещи в сезон улетают как творог в Белграде.
☔️ День Х
Всё было готово. В день Х я отправился на точку, чтобы занять место.
И тут новая проблема — я не взял наличку, а за въезд в парк нужно платить. Полезный инсайт на будущее.
А ещё пошёл лёгкий дождь, которого не было в прогнозе. Как будто сама природа не хотела, чтобы Гена научился делать шашлык.
Злой рок мешал мне, как герою Джеймса Франко в 11.22.63. Но дождь прошёл, и всё получилось! И свиной, и куриный шашлыки удались.
✅ Завершение спринта
Оставалось:
1) закончить тестирование приготовленного мяса,
2) собрать обратную связь от участников,
3) порефлексировать над проведённым экспериментом.
Теперь можно готовиться к внедрению шашлыка на прод 😄
🤰 Постэффект
Что было дальше?
Я сходил ещё на два шашлыка за выходные, объелся… и как будто бы мне уже шашлыков больше не надо 😅
📝 Вывод
Надеюсь, моя история была поучительной.
Учиться новому, валидировать идеи, планировать, учитывать риски, внедрять и дорабатывать — навыки, которые полезны не только в IT 😉
В свои 34 годика я не умел готовить шашлык. Только есть. Причём на уровне Senior Eater, не меньше.
И вдруг мне захотелось попробовать новый формат общения: собираемся в парке, приносим еду, готовим мясо. Но как развить в себе этот навык?
🔍 Первое исследование
Первое, что я сделал — это сходил на день рождения своей коллеги, где записал весь процесс приготовления шашлыка: задал нужные вопросы и даже немного поучаствовал — махал над углями, раздувая пламя.
🧪 CustDev и бета-тест
Дальше я провёл небольшой custdev, чтобы понять — интересно ли вообще кому-то такое?
Оказалось, что да. Я даже нашёл несколько человек, готовых записаться на бета-тест шашлыка.
🛒 Подготовка и логистика
Предстояло сделать ещё несколько шагов:
1) съездить на место и разведать локацию,
2) составить список покупок,
3) изучить магазины около дома и рядом с местом жарки.
Сразу стало ясно: в одиночку хорошая посиделка не выйдет — нужно раскидать ответственность между участниками. Тут пригодились и лидерские качества, и инициативность.
⚠️ Неожиданные риски
И, конечно, не обошлось без сюрпризов:
Один из бета-тестеров не ест лук — пришлось мариновать мясо на киви.
В магазинах закончились решетки для жарки мяса — такие вещи в сезон улетают как творог в Белграде.
☔️ День Х
Всё было готово. В день Х я отправился на точку, чтобы занять место.
И тут новая проблема — я не взял наличку, а за въезд в парк нужно платить. Полезный инсайт на будущее.
А ещё пошёл лёгкий дождь, которого не было в прогнозе. Как будто сама природа не хотела, чтобы Гена научился делать шашлык.
Злой рок мешал мне, как герою Джеймса Франко в 11.22.63. Но дождь прошёл, и всё получилось! И свиной, и куриный шашлыки удались.
✅ Завершение спринта
Оставалось:
1) закончить тестирование приготовленного мяса,
2) собрать обратную связь от участников,
3) порефлексировать над проведённым экспериментом.
Теперь можно готовиться к внедрению шашлыка на прод 😄
🤰 Постэффект
Что было дальше?
Я сходил ещё на два шашлыка за выходные, объелся… и как будто бы мне уже шашлыков больше не надо 😅
📝 Вывод
Надеюсь, моя история была поучительной.
Учиться новому, валидировать идеи, планировать, учитывать риски, внедрять и дорабатывать — навыки, которые полезны не только в IT 😉
🔥30😁17👍6❤1🥰1
Коллега из соседнего канала организовывает курс по CI/CD с настоящим DevOps. Тоже планирую участвовать, хотя бы в записи
#рекомендация
#рекомендация
👍1
Вчера прошел первый день бесплатной онлайн конференции 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 лет назад на этот митап бы смогла прийти только половина из нас, так как вторая половина умерла бы из-за чумы 😅 Ну и еще цитата:
— страшно🙃 вырубайте свои GPT пока мы еще не все потеряли.
Остальные трансляции доступны здесь, можно прислать уведомление, когда она начнется.
Видео с выступлениями уже есть на канале:
Успел пока посмотреть только первый доклад Марии. Понравится заход спикера разбавить напряженность в самом начале. Она начала доклад с того, что 200 лет назад на этот митап бы смогла прийти только половина из нас, так как вторая половина умерла бы из-за чумы 😅 Ну и еще цитата:
"We may end up in the world where there is no place for diversity, for care, for equity"
— страшно
Остальные трансляции доступны здесь, можно прислать уведомление, когда она начнется.
Please open Telegram to view this post
VIEW IN TELEGRAM
wearecommunity.io
ProQuality Conference 2025
ProQuality Conference 2025. "June 2, 2025" | Community platform | Register for the event and learn more on the main communities platform.
❤16🔥9👍2
HTML Embed Code: