trauma-driven-development, в этом что-то есть...

p.s. Хороших выходных!

📚 Подборка для практики и изучения SQL

Источник — QA4Life

▫️ HackerRank (SQL challenges)
Огромное количество SQL-задач от easy до hard. Отличная тренировка в стиле "coding interview".

▫️ Codewars
Крупное комьюнити и тысячи "ката" — задач разного уровня. Можно практиковаться в SQL и сравнивать решения с другими.

▫️ W3Resource SQL Tutorial & Tasks
Пошаговые SQL-уроки + более 700 задач от простых до продвинутых.

▫️ StrataScratch
Тренажёр с реальными SQL‑задачами из FAANG-компаний. Отлично подходит к подготовке к собеседованиям.

▫️ LeetCode (SQL section)
SQL‑раздел на легендарной платформе. "База" для подготовки к самым жёстким интервью.

▫️ DataLemur
Подборка SQL‑кейсов в стиле собеседований: аналитика, агрегаты, оконные функции.

▫️ SQL-ex
Легендарный русскоязычный тренажёр с сотнями практических задач.

▫️ Online SQL Playground
Простая "песочница" для теста запросов без установки СУБД.

▫️ Stepik (SQL тренажёры):
▪️Интерактивный курс — практика с задачами по SQL.
▪️SQL Adventure – геймифицированный формат: приключение для новичков.
▪️Введение в SQL – Победитель Stepik Awards 2024 - Лучший курс по Анализу данных! Это ключ к миру баз данных. Вам доступны структурированные лекции, почти 100 тестовых и интерактивных задач
▪️Марафон данных: первое знакомство с SQL и Python Этот курс для тех, кто хочет познакомиться с профессией аналитика данных. Если вы никогда ранее не сталкивались с SQL, Python и продуктовыми метриками, то этот курс – для вас! Курс рассказывает про самые важные инструменты аналитика данных, и объясним всю суть аналитической работы максимально просто и на реальных примерах.
▪️Собеседование по SQL: Теория и практика Этот курс предназначен для тех, кто хочет успешно пройти собеседование по SQL. Рассмотрим решение практических задач и ответы на наиболее часто встречающиеся теоретические вопросы.

▫️Яндекс Практикум — основы SQL
Курс с теорией и практикой по базам данных. Полезно новичкам.

▫️SQL Academy
Онлайн SQL-тренажёр с интерактивными задачами от простого к сложному.

▫️SQLtest.online
Минималистичный тренажёр для практики SELECT, JOIN, GROUP BY и других основ.

▫️SQLBolt
Короткие уроки + интерактивные задания на английском. Отлично для быстрого старта.

▫️PostgreSQL Docs
Официальная документация PostgreSQL. Обязательный справочник для работы с БД.

▫️SQL-Translator (AI)
AI, который переводит текстовые задачи в SQL-запросы. Можно тренироваться и проверять себя.

▫️DBQuacks
Новые SQL‑челленджи в игровом стиле. Отличный способ учиться весело и нестандартно.

правильно сделал 😁

Практика по работе с API

Одна из сложных тем для будущих тестировщиков — API. Что это, как с API взаимодействовать и как его тестировать?

По этой теме команда QA Studio проведёт бесплатный двухдневный вебинар:
🔸Всем желающим откроем доступ к нашему флагманскому тренажёру «Битва покемонов» ⚪️
🔸Живые вебинары, на которых объясним, что такое REST API и как его протестировать. Спикер — Герман
🔸Будем играть в покемонов: создавать и ловить покемонов, зарабатывать ачивки и вызывать на битву соперников ⚡️
🔸Документация в Вики и Swagger. 30+ HTTP REST методов, монолит и микросервисы
🔸Практикуйтесь с API в игровой форме с интересом и азартом 🔥

Новичкам точно будет интересно — объясняем с нуля. Кто уже с опытом — приходите просто поиграть и прокачаться до тренера-чемпиона быстрее всех 😉

➡️ полная программа вебинара

Коротко:
🔸Когда: 13 и 14 сентября в 18:00 мск
🔸Регистрация: @qa_studio_webinar
🔸А запись будет? — будет!
🔸Бесплатно

erid: 2W5zFK13gXi

у кого так же? 😁

Можно ли говорить и обсуждать свою ЗП?

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

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://t.me/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

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

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

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