🔧 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 — мощный комбайн, который может заменить связку сразу нескольких инструментов.

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

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

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

🧩 Шпаргалка для 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 для модуля платежей и написал для него юнит-тесты. Сегодня планирую начать интеграцию с банковским шлюзом. Пока блокеров нет».

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

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

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

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

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

🔥 Большая подборка ресурсов для работы с 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

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

Мобильным тестировщикам посвящается.

Надо было загадывать яхту 😁

Шпаргалка для QA инженеров: как получить оффер, используя поиск работы как запуск теста?

Начинаем, конечно, с изучения требований – смотрим, какие вакансии есть на рынке, что хотят от кандидата и что ему предлагают. Дальше настраиваем тестовую среду – готовим резюме и себя к предстоящему собеседованию. Непосредственное выполнение тестов, тут и так понятно, проходим собесы и ждем ответ. Но что делать, если ответа нет? Карьерная стратегия – новая реальность, хотите вы этого или нет. И тот, кто первый это поймет сможет не только не умереть в канаве, но и повысить грейд и зарплату даже на сегодняшнем рынке работодателя.

В Карьерном Цехе сопровождают кандидатов до оффера с HR-ами и профильными экспертами, которые подбираются персонально под ваш стек.

В программу поддержки входит:

💫Стратегическая консультация с профильным HR (калибровка с рынком по компенсации, задачам и навыкам)
💫Встреча с HR и профильным экспертом для корректировки резюме, чтобы сделать его понятным для нанимающего менеджера и HR
💫Тренировочные собесы, мок-интервью с топовыми нанимающими с рынка с развернутым фидбеком
💫 Ну и конечно, постоянный HR-надзор от Леси Набоки, соосновательницы Карьерного Цеха, которая специализируется на подборе персонала со времен египетских пирамид
💫Огромное коммьюнити и рефералки по всему рынку, Карьерный цех настоящая кадровая кузница топовых российских компаний

Приходите выстраивать карьеру в КЦ по понятному плану со знакомыми этапами.

🙃 Почему вы не довольны AI в тестировании? Возможно, вы делаете одну из этих 6 ошибок.

Источник

Я сам проходил через них все, внедряя AI-решения в тестировании - от первых экспериментов до пилотов в продакшене.

И часто вижу, как мои команды ловят те же ошибки.

Давайте по порядку

1. Неструктурированные промпты
- Когда AI не понимает, чего от него хотят - не потому что он тупой, а потому что промпт расплывчатый.
- Нет чётких шагов, нет сценария, нет указания формата ответа.
- На выходе: вода, пространные рассуждения, «ни рыба ни мясо».

2. Нет примеров
- Вы просите: "Сделай как надо", но не показываете, что такое "надо".
- Few-shot prompting (несколько примеров input → output) помогает AI лучше уловить формат и суть.
- Без них он будет гадать.

3. Пустая база знаний
- AI не экстрасенс, он работает с тем, что знает.
- Пара примеров - не база. Если вы не загрузили контекст, он будет лепить дубликаты или уходить в сторону.
- Нужна или ручная работа по сбору контекста, или интеграции с системами, или нормальный RAG.

4. Один промпт = много задач
- Типичная ошибка: в одном промпте попросить и ревью требований, и чеклист, и генерацию тестов.
- В итоге всё получается плохо.
- Один промпт - одна задача.
- Разбейте процесс и получите нормальный результат на каждом шаге.

5. Хотите всё и сразу
- "Сгенерируй 50 тест-кейсов на эту фичу".
- А потом удивляетесь, что они поверхностные и однообразные.
- AI ≠ волшебная палочка. Большие задачи - только итеративно. Один промпт - один кейс.
Да, дольше. Зато качественно. Даже для 50 шагов в тест-кейсе

6. Вы не используете AI, чтобы писать промпты
- Это иронично, но факт: промпты, написанные вручную, часто хуже.
- Я давно уже не пишу промпты сам.
- Я описываю, что хочу получить, даю примеры, и прошу AI сам составить промпт.
- Потом валидирую - и в бой.

🎯 Хотите качественный результат - относитесь к промптингу как к инженерной задаче.
И не забудьте: промпт - это тоже часть системы. Его можно (и нужно) тестировать.