🔧 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 ТБ памяти.

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

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

🔥 Как находить фатальные ошибки в приложении ещё до кода?

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

Что рассмотрим на уроке:
- Основы тестирования требований для мобильных приложений
- Как находить противоречия и недочёты в ТЗ
- Приёмы задавания «правильных» вопросов
- Как раннее тестирование требований экономит время и бюджет проекта

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

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

🔥 Большая подборка ресурсов для работы с cookies для QA, разработчиков и не только

Cookies используются для:
▪️авторизации,
▪️сохранения сессий,
▪️персонализации пользователя,
▪️аналитики и рекламы.

Именно здесь часто скрываются проблемы и уязвимости: от «вечных» сессий до нарушений безопасности.

Подборка ресурсов, которые помогут прокачать навыки работы с cookies:

1. Инструменты для работы с cookies в браузере

▫️Cookie-Editor (Chrome)
https://cookie-editor.cgagnier.ca/

▫️Cookie Quick Manager (Firefox)
https://addons.mozilla.org/en-US/firefox/addon/cookie-quick-manager/

Также удобно работать с cookies через DevTools.

2. Практика безопасности и уязвимостей

▫️OWASP Juice Shop — тренажёр по веб-безопасности, где можно экспериментировать с cookies.
https://owasp.org/www-project-juice-shop/

▫️PortSwigger Web Security Academy — интерактивные лаборатории по cookies, сессиям и токенам.
https://portswigger.net/web-security

3. API и HTTP-эксперименты

▫️HTTPBin — сервис для проверки запросов и работы с cookies.
https://httpbin.org/

▫️Postman Echo — инструмент для тестирования cookies в запросах.
https://www.postman-echo.com/

4. Ресурсы для соответствия GDPR / CCPA

▫️CookieYes — генератор баннеров согласия на использование cookies.
https://www.cookieyes.com/

▫️Termly — готовые политики использования cookies.
https://termly.io/products/cookie-consent-manager/

5. Статьи и справочники для QA

▫️OWASP Cheat Sheet — Secure Cookie Practices
https://cheatsheetseries.owasp.org/cheatsheets/SecureCookieAttributes.html

▫️MDN Web Docs — Cookies (подробная документация с примерами)
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Все перечисленные материалы предназначены для обучения и практической работы.