📕 Первый автотест: пишем на Java с JUnit и Selenium для QA-инженеров, начинающих автоматизаторов и всех, кто хочет уверенно настраивать проекты под автотесты

На открытом уроке 15 сентября в 20:00 мск мы погрузимся в тонкости работы реальных автотестов на Java с использованием JUnit и Selenium:

📗 На вебинаре разберём:
1. Как писать и запускать тесты на JUnit и как работает Selenium WebDriver.
2. Основы хорошего автотеста: ассерты, читаемость, стабильность.

📘 В результате вы сможете на практике создать реальный автотест на Java с JUnit и Selenium.

👉 Регистрация и подробности о курсе QA Automation Engineer: https://otus.pw/pt6K/

Все участники открытого урока получат скидку на курс "QA Automation Engineer"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2W5zFHdQCWC

🔥 Полезные ресурсы для тестировщика (источник)

1. Книга или курс Святослава Куликова. Немного академично, но очень грамотно и полно. https://svyatoslav.biz/. Также у одной из соведущих нашего подкаста и ее команды вышел курс по основам тестирования https://stepik.org/course/116387/

2. Лучшая книга, которую я рекомендую прочесть каждому QA: https://www.rulit.me/tag/other-computers/a-practitioner-s-guide-to-software-test-design-perevod-download-668733.html. По ссылке она в неофициальном переводе, но при желании вот в этом канале можно найти оригинал: https://news.1rj.ru/str/booksqa по ключевым словам "lee copeland"

3. https://ulearn.me/ — мой любимый источник уже много лет. Здесь есть курс по тестированию, но рекомендую также взглянуть на курс по комп. сетям — хотя бы модель OSI, TCP/UDP, HTTP и всякое такое. Очень пригодится

4. Основы SQL — как вариант, можно посмотреть на https://www.w3schools.com/sql/default.asp; интерактивно, просто и понятно

5. Основы того, как работает веб: протокол HTTP и его методы (отлично описано тут: https://developer.mozilla.org/ru/docs/Web/HTTP), примерно понимать, что такое клиент-серверное взаимодействие, как происходит обмен информацией в Интернете; возможно, основы сетей. Всё это есть в бесплатном курсе по сетям от Андрея Созыкина – его можно найти по ссылке выше на портале Ulearn или поискать на Youtube. Обязательно прочитайте https://datatracker.ietf.org/doc/html/rfc2616 самого HTTP протокола, особенно главу https://datatracker.ietf.org/doc/html/rfc2616#page-51 (популярный вопрос на собеседовании)

6. https://stepik.org/course/73926/promo — курс, который делали Women in tech, запись лекций. Плохо, что без практики, но для базового понимания подойдет, — многие его хвалят

7. https://stepik.org/course/61272/promo — ещё один бесплатный курс с хорошими отзывами

8. https://stepik.org/course/575/promo — курс про основы автоматизации. Это тоже полезно! Но уже после того, как будет освоено всё остальное

9. Блог Ольги Назиной http://okiseleva.blogspot.com/ и её портал для новичков: http://testbase.ru/

10. Последнее в списке, но не по значению — техники тест-дизайна! На них строится вообще всё
Вот тут отлично описано: https://sysgears.com/articles/test-design-techniques-overview/. Также нельзя не порекомендовать старый, но не теряющий актуальности доклад Артёма Быковца: https://www.youtube.com/watch?v=hBl5pV2xnQg

11. По вопросам bash для QA вот хороший тест: https://www.learnqa.ru/bash_test

🔥 Готовы стать экспертом в микросервисах?

Микросервисная архитектура — ключ к созданию масштабируемых и гибких систем. Если вы хотите освоить современные технологии, такие как Docker, Kubernetes, Apache Kafka и Prometheus — программа курса "Microservice Architecture" отлично подойдет для этого.

Пройдите вступительное тестирование, получите спеццену на курс и успейте присоединиться к группе!

🎯Возможности обучения:

🔹Практические навыки: реальная работа с популярными инструментами.
🔹Лучшие практики: освоите архитектуру, которая востребована на рынке.

👉Пройти тест

Подробности о размере предоставляемой скидки уточняйте у менеджера

https://vk.cc/cPyeV7


Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru, erid: 2W5zFHUDpHv

🔧 3 инструмента для подмены данных в вебе, которые должен знать каждый тестировщик
Источник

1️⃣ Overrides (DevTools, Chrome)
В браузере можно выбрать папку на диске. Chrome сохраняет туда копии файлов сайта — HTML, CSS, JS, картинки, статический JSON.
Если изменить эти файлы локально, браузер будет подсовывать именно вашу версию.

✅ Отлично подходит, когда нужно быстро поправить фронт, верстку или подкинуть тестовые данные.
⚠️ Но Overrides не работает с динамическими API-ответами.

2️⃣ Mokku
Простое и лёгкое расширение для Chrome.
Встраивается прямо в DevTools.
Позволяет замокать ответы API под REST-запросы: указываешь эндпоинт и JSON — и каждый запрос возвращает твой ответ.

✅ Ничего лишнего: только самое нужное для подмены респонсов.
Если вам не нужны сложные сценарии и выкрутасы — Mokku более чем отличный инструмент.

3️⃣ Requestly
Это уже целый швейцарский нож для работы с веб-трафиком.
С его помощью можно:
▫️ Подменять ответы API (JSON/XML/HTML)
▫️ Перехватывать и редиректить запросы на другой URL
▫️ Менять и добавлять заголовки (headers)
▫️ Подменять или подключать JS/CSS прямо на страницу
▫️ Создавать наборы правил и включать их по условию
▫️ Делать A/B тесты или тестировать разные окружения без деплоя
▫️ Синхронизировать правила в команде (есть облако и шаринг)

⚡️ То есть если Mokku — лёгкий минимализм, то Requestly — мощный комбайн, который может заменить связку сразу нескольких инструментов.

📕 Архитектура и написание backend тестов для разработчиков Java, QA инженеров, автоматизаторов, QA Lead и DevOps-специалистов

На открытом уроке 17 сентября в 20:00 мск мы погрузимся в тонкости построения архитектуры надежных и понятных backend-тестов:

📗 На вебинаре разберём:
1. Использование Java и RestAssured для API-тестирования, приёмы структурирования и переиспользования кода.
2. Архитектурные принципы построения надёжных тестов.

📘 В результате на практике освоите построение надежных backend-тестов, научитесь писать чистый, гибкий и поддерживаемый код на Java с RestAssured и получите архитектурные шаблоны и рабочие примеры для своих проектов.

👉 Регистрация и подробности о курсе Java QA Engineer. Professional: https://otus.pw/B2L9/

Все участники открытого урока получат скидку на курс "Java QA Engineer. Professional"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2W5zFGtMY5E

Эффективные идиоты - идеальные кандидаты.

Приглашаем на бесплатный вебинар от OTUS: “Паттерны кэширования для высокой производительности”
📅 Когда: 22 сентября, 20:00 мск

О чём?

Кэширование — ключ к быстрым и стабильным микросервисам. Узнайте, как применять паттерны кэширования, чтобы ускорить приложения, снизить нагрузку на базы данных и избежать ошибок.

На вебинаре разберём:
• Роль кэширования в микросервисах.
• Паттерны: Cache-aside, Read-through, Write-through, Write-behind.
• Инвалидация кэша и работа с Redis, Memcached.
• Практики для высоконагруженных систем.

Кому полезно:
• Backend- и FullStack-разработчикам.
• Архитекторам ПО и DevOps-инженерам.

Что получите:
• Навыки выбора паттернов кэширования.
• Советы по использованию Redis и Memcached.
• Знания для создания производительных систем.

👉 Зарегистрироваться https://vk.cc/cPzXd2

Бесплатное занятие приурочено к старту курса Microservice Architecture, обучение на котором позволит освоить микросервисы: Docker, Kafka, API и стать мастером производительных систем

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2W5zFGc9ieC

Хороших выходных!

продуктивной недели 🙌

🪄 Существует ли магия тест-дизайна для QA?

Что, если бы вам дали 1000 сценариев для проверки функционала всего за 5 минут?

На этом уроке мы раскроем магию тест-дизайна — искусство находить критические баги там, где другие видят только верхушку айсберга. Вы узнаете, как хитрые техники like pairwise и граничные значения позволяют тестировщику обыгрывать даже самого дотошного пользователя, предугадывая его действия. Это не про тупой перебор вариантов, а про то, как умная стратегия превращает рутину в интеллектуальную охоту на ошибки.

Готовы узнать, как находить 90% багов, используя всего 20% тестов?

Что рассмотрим на уроке:
- Базовые техники тест-дизайна для ручного тестировщика
- Pairwise и анализ граничных значений на практике
- Как покрыть максимум сценариев минимальным числом тестов
- Ошибки новичков при проектировании тестов

👉🏻 Регистрация и подробности о курсе: https://vk.cc/cPCsfr

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2W5zFGKZ4YG

🧩 Шпаргалка для QA инженеров: Как тестировать интеграцию одной системы в другую
Источник: Владлен Цыганенко

🔎 1. Анализ требований
— Определите, какие системы интегрируются (API, SDK, база данных, внешние сервисы).
— Уточните цели интеграции: передача данных, авторизация, аналитика, платежи и т.д.
— Разберитесь, какие данные/события должны передаваться, в каком формате и с какой частотой.

💠 2. Проверка базовой интеграции
— Данные передаются из системы А в систему Б без ошибок.
— Формат и структура данных соответствуют спецификации (JSON/XML/CSV и т.п.).
— Обязательные поля присутствуют и корректны.

🔐 3. Валидация безопасности
— Проверить авторизацию/аутентификацию (OAuth, API key, токены).
— Проверить доступ только у разрешённых пользователей/сервисов.
— Негативные проверки: неверный токен, истёкший токен, отсутствие прав.

🌐 4. Сценарии с сетью и окружением
— Что будет при медленном интернете, потере соединения?
— Поведение при повторной отправке одного и того же запроса (идемпотентность).
— Проверка работы в разных окружениях: dev, staging, production.

🔄 5. Обработка ошибок
— Если система А отправила некорректные данные, то система Б возвращает понятный ответ?
— Ошибки логируются и доступны для анализа?
— Пользователь видит корректное сообщение об ошибке (а не «500 internal error»).

📊 6. Нагрузочное тестирование
— Как система реагирует на большой поток запросов?
— Есть ли задержки при обмене данными?
— Нет ли потери или дублирования данных?

🧪 7. Негативные кейсы
— Отправка пустых значений.
— Использование устаревших версий SDK/API.
— Несовпадение версий протоколов (например, HTTP/1.1 vs HTTP/2).

📝 8. Документация и регрессия
— Вся интеграция должна быть задокументирована.
— Проверяйте совместимость при обновлениях (новая версия SDK, новая версия API).
— Ведите чек-листы/тест-кейсы для будущих регрессий.

Инструменты
▫️Postman / Insomnia - API
▫️Charles / Fiddler - трафик
▫️Kibana / Grafana - логи и метрики
▫️Burp Suite / OWASP ZAP - безопасность
▫️Selenium / Playwright / Cypress - e2e
▫️JMeter / k6 / Locust - нагрузка
▫️Android Studio / Xcode - SDK, мобильные
▫️Firebase Test Lab / BrowserStack - устройства

ИТОГ:
QA проверяет обмен данными, учитывает краевые сценарии, оценивает безопасность, стабильность и совместимость систем.

🧪 Тестируем стул, карандаш и чайник: шпаргалка для QA-инженеров
Источник: Владлен Цыганенко

На собеседованиях QA частая «ловушка» когда просят протестировать не сайт и не приложение, а бытовой предмет: карандаш, стул, кружку и т. д. Цель: проверить не технические знания, а мышление, структурность и умение задавать вопросы.

Как отвечать правильно

▫️Не теряйтесь
Это задание не про реальные баги, а про то, как вы рассуждаете.

▫️Начинайте с уточнений
— Для кого предмет? (дети, взрослые, офис, школа)
— В каких условиях используется? (дом, улица, экстремальные условия)
— Цель использования? (стул для сидения, карандаш для письма/рисунка)
Такие вопросы показывают, что вы умеете собирать требования.

▫️Думайте категориями тестирования
— Функциональность - выполняет ли предмет свою основную задачу?
— Юзабилити - удобно ли им пользоваться?
— Надежность - выдерживает ли нагрузки, не ломается ли слишком быстро?
— Безопасность - не причиняет ли вреда (например, у стула острые углы)?
— Совместимость/условия эксплуатации - работает ли в разных средах (карандаш пишет на бумаге, картоне, стене).

▫️Примеры подхода
— Стул: проверю устойчивость, прочность, удобство спинки, высоту, материалы, безопасность (нет ли заноз).
— Карандаш: пишет ли, ломается ли грифель, стирается ли резинка, удобно ли держать, оставляет ли след на разных поверхностях.
— Кружка: выдерживает ли кипяток, удобно ли держать ручку, можно ли мыть, не трескается ли.

▫️Используйте знакомые техники тест-дизайна
— Эквивалентные классы (разные типы пользователей: ребёнок/взрослый).
— Граничные значения (макс. вес для стула, минимальная температура для кружки).
— Негативные сценарии (сидеть на стуле на одной ножке, пытаться писать карандашом на мокрой бумаге).

❓Стоит ли задавать уточняющие вопросы?

Да, обязательно. Это показывает, что вы:
— Умеете уточнять требования;
— Не тестируете «в вакууме»;
— Мыслите как QA в реальном проекте.

Как себя вести
— Будьте спокойны и структурны;
— Разбейте рассуждения на блоки (условия → категории тестов → примеры);
— Не стремитесь перечислить «все баги мира», главное, показать системность.

Итог:
Когда просят протестировать предмет, не ищут реальные дефекты, а хотят увидеть логику, структурность, внимательность и умение задавать правильные вопросы.
Хороший ответ звучит не как «сломается/не сломается», а как чек-лист из разных категорий проверки с предварительными уточнениями. Эта техника работает и с ПО: вы показываете одинаковый QA-подход в любой ситуации.

Как правильно отчитываться на дейли-митингах / стендапах / летучках?
Источник: Максим Азаров, Software Testing QA Lead в SAM Solutions

За много лет работы я заметил одну и ту же особенность в командах.

Есть категория людей, которые не любят долго распинаться, предпочитают говорить минимум и в общем предпочитают не отсвечивать. От них обычно слышно что-то типа «Я на автоматизации», или «Я баг проверяю», или «Я стори делаю» и всё. Ни рассказа о находках и преодолённых трудностях, ни эстимейтов, когда закончит, ни любых других интересных или познавательных деталей. Всю остальную информацию приходится вытягивать клещами и наводящими вопросами.

Есть другая категория людей, которые, наоборот, любят говорить долго, погружают всех окружающих в кучу технических деталей, рассказывают свои мысли, о том, как они думали, какие решения принимали, где ошиблись, а где, наоборот, придумали гениальные решения. Так минут на 10–15. Эти товарищи часто очень обижаются, если их прерывают и просят сформулировать статус в 2–3 предложениях. И тут обратная ситуация: идёт перегруз информацией, и человек вне контекста очень быстро теряет смысл происходящего, а у человека, собирающего статус и оценивающего общую ситуацию на проекте, начинает кипеть мозг от лишней информации.

Так нужен ли на самом деле алгоритм? И для кого на самом деле эти митинги? Для менеджера, чтобы собрать статус, или для членов команды, чтобы понимать, что вообще происходит и кто что делает на проекте?

Короткий ответ: Митинг этот для всей команды, но с разными целями для разных ролей.

Для команды (разработчиков, тестировщиков, дизайнеров и т.д.) это синхронизация:
а) Узнать, что сделали другие, чтобы не работать в вакууме.
б) Обнаружение блокеров: услышать, у кого возникли проблемы, и предложить помощь («Я сталкивался с такой ошибкой, посмотри вот в этот конфиг»).
в) Понимание контекста: увидеть общую картину движения к цели спринта.
г) Обмен знаниями: узнать о новых подходах, технологиях или проблемах, с которыми столкнулись коллеги.

Для менеджера / тимлида / скрам-мастера это:
а) Сбор статуса: получить общее представление о прогрессе.
б) Выявление рисков: увидеть препятствия, которые мешают команде, и оперативно их устранить.
в) Оценка нагрузки: понять, всё ли по плану или нужны корректировки.

Главная ошибка здесь - считать, что дейли - это просто отчёт менеджеру. Это время синхронизации команды, которую организует менеджер / скрам-мастер.

Предположительно правильный алгоритм отчёта должен укладываться в 3-4 предложения и длиться не более 1-2 минут. Он должен содержать ответы на три ключевых вопроса:
1. Что я сделал вчера? (По отношению к цели спринта)
2. Что я планирую сделать сегодня? (Опять же, для движения по задачам)
3. С какими трудностями столкнулся? (Блокеры, риски, вопросы)

Плохо: «Я кодил, потом тестил, потом ещё покодил».

Хорошо: «Вчера я завершил разработку API для модуля платежей и написал для него юнит-тесты. Сегодня планирую начать интеграцию с банковским шлюзом. Пока блокеров нет».

А как это работает в ваших командах ?

❓Как сформировать стратегию тестирования?

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

Результаты на выходе:

- Участники поймут, чем стратегия отличается от плана тестирования.
- Получат готовую «канву» для построения своей стратегии.
- Увидят примеры метрик, SLA и quality gates, которые можно адаптировать под свои проекты.

👉 Регистрация и подробности о курсе: https://vk.cc/cPNars

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2W5zFH62MfW

Нужно было в своё время начинать в тик-токе танцевать. Было бы ещё больше тысяч долларов на счету и здоровая спина 😁

В hh разработали пул новых заданий по оценке IT навыков и прямо сейчас собирают обратную связь от профессионального сообщества, чтобы убедиться в актуальности и корректности тестов.

Я проверил новые задания по SQL и в целом они мне понравилось - это не очередная проверка знания базового синтаксиса и основных операторов (вроде SELECT и JOIN), а комплексный тест по разным темам.Как мне объяснили, для ревью собрали задачи всех уровней: от базовых до продвинутых. В реальных же тестах для каждого уровня будут свои блоки: выбрал базовый – получаешь соответствующие задания. Есть вопросы на знание тонкостей, на которых можно задуматься даже опытным разработчикам - вроде нетривиальных моментов, где надо помнить про особенности троичной логики SQL, разницу в поведении JOIN-ов.

Чтобы вы представляли себе уровень заданий, ниже вопрос, на котором завалился я ⤵️
Рассмотрим запрос:

SELECT name FROM customers WHERE customer_id NOT IN (SELECT customer_id FROM orders WHERE status = 'canceled') Какое нетривиальное поведение будет у этого запроса, если хотя бы одна строка во вложенном подзапросе содержит значение NULL в customer_id?

На первый взгляд кажется, что он просто отберёт всех клиентов без отменённых заказов. Но как только во вложенном подзапросе появляется хотя бы один NULL в customer_id, результат ломается — запрос не вернёт вообще ничего. Это нетривиальный момент, который легко пропустить, если не помнить про особенности трёхзначной логики в SQL (TRUE, FALSE, UNKNOWN).

Как видите, есть вопросы про глубокое понимание логики SQL. В реальных проектах незнание таких моментов может привести к очень неприятным багам.
Подытоживая: хороший проект и отличный пример того, как с привлечением сообщества можно сделать инструмент точнее и полезнее.

🔥 «Яндекс» запустит новый дата-центр во Владимирской области

В начале 2026 года Yandex Cloud запустит новую зону доступности – на базе нового дата-центра во Владимирской области. Его мощность превысит 40 МВт, а задержка между соседними зонами составит менее 1 мс при пропускной способности канала 25,6 Тб/с. Такой уровень инфраструктуры позволит ускорить критичные для бизнеса процессы — от транзакций до обработки запросов в базах данных.

📈 Также компания запустила новые вычислительные платформы – производительность выросла втрое при сопоставимой стоимости, на одной виртуальной машине теперь доступно до 288 vCPU и 1,7 ТБ памяти.

Читать подробнее