💻 MITM: почему бесплатный Wi-Fi знает о вас больше, чем мама

На открытом уроке разберёмся, как работает классическая атака "Man-in-the-Middle" (MITM) и почему подключение к «бесплатному Wi-Fi» может стоить вам приватности.

На вебинаре вы узнаете:
- Поймёте, как злоумышленник перехватывает трафик между вами и интернетом.
- Научитесь отличать уязвимые соединения от защищённых.
- Узнаете, почему бесплатные ресурсы — это иногда хуже, чем его отсутствие.
- Получите базовые навыки безопасного поведения в открытых сетях.

Вебинар проходит в рамках курса "Автоматизированное тестирование веб-сервисов на Go"

👉 Регистрация и подробности о курсе "Автоматизированное тестирование веб-сервисов на Go" https://vk.cc/cOgfbR

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

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

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

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

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

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

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

👉 Пройти тест https://vk.cc/cOgf7N

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

и не говорите, что работы нету 😁

🗝 Docker Compose для тестировщика: легко о сложном

Хотите научиться легко и правильно настраивать сложные приложения из множества контейнеров?

На этом вебинаре мы подробно разберём один из ключевых инструментов для современных тестировщиков — Docker Compose. Он помогает запускать, настраивать и управлять распределёнными приложениями, состоящими из нескольких контейнеров, что значительно упрощает работу с тестовыми средами и ускоряет процессы автоматизации.

На вебинаре вы узнаете:
— Поймём, почему важно использовать Docker Compose для организации многоконтейнерных приложений в автоматизации
— Изучим, как настроить сетевое взаимодействие между контейнерами — чтобы ваши сервисы могли «видеть» и обмениваться данными друг с другом
— Разберёмся с промежуточным хранением данных — что это такое и как правильно сохранять состояние приложений внутри контейнеров
— Узнаем, как применять эти знания для создания надёжных и воспроизводимых тестовых сред

Вебинар проходит в рамках курса "Python QA Engineer"

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

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

❓Вопросы работодателю на собеседовании, шпаргалка для QA-инженера

Сильные кандидаты не только отвечают, но и задают вопросы. Этот список поможет быстро понять продукт, процессы и ожидания от роли. Сохраните и возьмите с собой на следующее интервью.

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

▫️Про процессы разработки и тестирования
- Какой процесс разработки (Scrum/Kanban/гибрид)? Длина спринта?
- Когда и как QA подключается к задаче: на этапе требований, дизайна, планирования?
- Есть ли Definition of Ready/Done для задач и багов?

▫️Про качество и метрики
- Какие метрики качества вы отслеживаете (defect leakage, escape rate, MTTR, флейки, покрытие)?
- Есть ли цель по снижению багов на проде и как её измеряете?
- Как анализируете регрессии и инциденты (post-mortems, RCA)?

▫️Про релизы и окружения
- Как часто релизитесь и есть ли релизный календарь?
- Сколько стендов (dev/test/stage/prod) и насколько они похожи на prod?
- Кто и как может откатить релиз? Есть ли фича-флаги/канареечные выкладки?

▫️Про автоматизацию и инструменты
- Где проходит граница между ручным и авто-тестированием?
- Какие стеки используете (Selenium/Playwright/Appium, CI/CD, отчётность, мониторинг)?
- Что считается «готовой» автотестовой задачей (стандарты, ревью, покрытие)?

▫️Про баги и приоритизацию
- Как приоритизируете дефекты (S1–S4/P0–P3)? Кто финально решает «критичность»?
- Как быстро исправляются S1/S2? Есть ли SLA/OLA по реакциям?
- Как боретесь с флейками и «битой» регрессией?

▫️Про роль, ожидания и рост
- Как выглядит успех на 30/60/90 дней для этой роли?
- С чем я приду в первый спринт? Какие 2–3 приоритеты?
- Есть ли менторство, бюджет на обучение/сертификации, путь роста (IC/Lead)?

▫️Про команду и культуру
- Как устроено взаимодействие QA с продактом, дизайном, бэком/фронтом, DevOps?
- Как дают обратную связь и как часто проходят 1:1?
- Как команда относится к долгам: техдолг, тестдолг, документация?

▫️Про оффер и условия (уместно на финальном этапе)
- Смена формата работы (офис/гибрид/удалёнка), график, овертаймы и компенсация за них.
- Испытательный срок, грейд/вилка, бонусы, ДМС/оборудование.
- Процесс онбординга и кто будет моим «buddy» в первые недели.

🚩 Красные флаги
- Нет тестовых окружений, релизы «по ночам», откаты «вручную».
- Отсутствие метрик качества и пост-мортемов («просто чиним»).
- QA подключается только «в конце», нет времени на регрессию.
- «Автотесты есть», но никто не может показать отчёты/стабильность.

🍭 Мини-скрипт в конце интервью
«Спасибо за ваше время. Есть ли что-то в моём фоне, что вызывает сомнения? Я буду рад прояснить сейчас».
Если ответ "да", то вы получили шанс закрыть гештальт сразу. Если "нет", то мягко уточните следующие шаги и сроки обратной связи.

Источник: Владлен Цыганенко

📌 Два бесплатных вебинара для системных и бизнес-аналитиков. Успейте попасть в группу!

🔹 Бизнес-аналитик и Системный аналитик: зачем нужны 2 роли?

⏰ 19 августа в 20:00 мск

💎 Вы узнаете:
1. Зоны ответственности системного и бизнес-аналитика, решаемые задачи, акценты и ключевые результаты работы.
2. Как задачи этих ролей видит отрасль и ведущие компании.
3. Кто такие fullstack-аналитики и стоит ли развиваться в эту сторону.
4. Какие навыки развивать системному и бизнес-аналитику.

🔹 Трассировка и ведение реестра требований

⏰ 25 августа в 20:00 мск

💎 Вы узнаете:
1. Важность трассировки требований между собой и на элементы решения и архитектуры
2. Методы и инструменты, которые могут быть применены аналитиком для трассировки требований

🎁 Участники вебинаров получат подарки на почту 🎁

Регистрация на вебинары ➡️ OTUS.RU

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

типичный понедельнки)

Единственная IT-школа, которая не обещает результаты, а открыто показывает их. Только Mentorpiece публикует поименные списки всех поступивших студентов и конечный результат обучения для каждого: в какой IT-компании он/она теперь работает.

🇬🇧 Обучение на английском без лекций — с решением реальных IT-задач в мини-команде, как на настоящем IT-проекте.
🇺🇸 4-месячная интернатура в американской IT-компании.
🇨🇦🇺🇸🇳🇱🇵🇱🇦🇹🇭🇺🇭🇷🇷🇸🇨🇾🇮🇱🇦🇪🇬🇪🇦🇲🇰🇿🇰🇬🇦🇺 — страны, в IT-компаниях которых работают выпускники.

Конкурс 5 человек на место.
Бесплатно пройди углубленный курс-профориентацию в IT по коду GOD

Новый сезон конференции Podlodka QA Crew пройдет с 1 по 5 сентября. В фокусе — инструменты, которые делают тестирование быстрее, качественнее и удобнее.

В программе:

💡Как раскрыть потенциал Postman и ускорить обратную связь — вместе с Ариной Ладесовой (Payler).

🪄Внедрение ИИ для генерации тестов без лишней боли — с Натальей Петровской.

📱Современные инструменты мобильного тестировщика — практические кейсы от Елены Фёдоровой (Garage Eight).

🔍 Observability автотестов и мониторинг — с Кириллом Ивлиевым (Работа.ру).

Знания, которые легко применять в работе!

🔗 Подробнее и регистрация — https://podlodka.io/qacrew

🐳 Docker для тестировщиков
Источник

📚 Что такое Docker?
Docker - это платформа для контейнеризации приложений.
Контейнер - это легковесная виртуальная «коробка», куда упакованы:
- Код приложения
- Библиотеки
- Настройки окружения

В отличие от виртуальных машин, контейнеры не эмулируют всю ОС, а используют ядро хоста, что делает их быстрыми и компактными.

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

❓Зачем Docker тестировщику?
1. Идентичное окружение на всех этапа
Проблема:
«На моём ноуте тесты проходят, а на CI/CD падают!»
Решение:
Docker гарантирует, что тесты запускаются в одинаковой среде (версии Python/Java, БД)

2. Быстрый подъем инфраструктуры
Пример:
Вместо ручной установки PostgreSQL + Redis + Kafka:
docker-compose up -d

3. Тестирование в изоляции
- Можно запускать параллельные тесты в разных контейнерах
- Тесты не влияют на основную систему (например, не засоряют БД)

4. Эмуляция продакшена
- Тестирование на точной копии продакшен-окружения
- Проверка конфигов, переменных среды, сетевых правил

👁 Ключевые концепции Docker
1. Образ (Image)
Шаблон для создания контейнеров

2. Контейнер
- Изолированная «коробка» с программой внутри (например, с вашим тестовым фреймворком или базой данных)
- Можно создать/остановить/удалить

3. Dockerfile
Инструкция для сборки образа

4. Docker Compose
Инструкция для управления несколькими сервисами (БД, кеш, API)

Почему Docker стоит освоить?
▫️Стандартизация - больше никаких «на моей машине работает»
▫️Экономия времени - окружение разворачивается за минуты
▫️Гибкость - можно тестировать разные версии ПО

Docker - не панацея, но незаменимый помощник в арсенале современного тестировщика 🛠

🔍 Postman под микроскопом: как один инструмент экономит часы работы QA

Когда речь заходит о тестировании API, многие представляют себе рутину: писать запросы, проверять ответы, копировать данные туда-сюда… Но те, кто освоил Postman «по-взрослому», знают: этот инструмент превращает тестирование в быстрый, чёткий и автоматизированный процесс.

С его помощью можно:
— за пару кликов отправить десятки запросов;
— автоматизировать проверки и сценарии;
— работать с REST и GraphQL API без лишних движений;
— собирать тестовые коллекции, которые экономят часы работы.

Проблема в том, что большинство QA-инженеров используют лишь 10–15% возможностей Postman. Не знают, как правильно настроить переменные, как быстро формировать тестовые сценарии, как связывать его с другими инструментами.

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

Доступ к ним простой: достаточно пройти тестирование — оно занимает около 30 минут и помогает оценить уровень ваших знаний в тестировании.

А уже после теста вы узнаете о программе курса «Автоматизированное тестирование веб-сервисов на Go». В нём мы учим автоматизировать тестирование веб-сервисов с нуля, работаем с Go, Postman, SQL, UI- и API-тестами, создаём портфолио и готовим к позициям QA Automation Engineer.

📌 Проверьте свой уровень, заберите материалы по Postman и узнайте, как прокачать навыки автоматизации на Go -
https://vk.cc/cOGmG2

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

🔥 SQL для тестировщиков: 5 полезных запросов
Источник

SQL - это язык для работы с реляционными базами данных (например, MySQL, PostgreSQL, Oracle). SQL является отличным инструментом для проверки целостности данных, анализа связей между таблицами и поиска скрытых багов.

1. Возвращаем набор данных из базы (SELECT)
Когда использовать: После регистрации, создания заказа и т.д. - проверяем, что пользователь/заказ создался, смотрим на корректность и полноту данных

Найти пользователя по email:

SELECT * (Выбираем все поля записи)
FROM users (Из таблицы users)
WHERE email = 'test@example.com'; (Где email равен указанному значению)

Проверить последний заказ:

SELECT * (Выбираем все поля записи)
FROM orders (Из таблицы orders)
ORDER BY created_at DESC (Сортируем по дате создания (новые сначала))
LIMIT 1; (Ограничиваем результат одной записью)

2. Фильтрация данных по условиям (WHERE)
Когда использовать: для поиска и анализа ошибочных записей, для выборочной проверки данных по определённым критериям

Найти неоплаченные заказы старше 3 дней:

SELECT * (Выбираем все поля заказов)
FROM orders (Из таблицы orders)
WHERE status = 'unpaid' (Где статус "неоплачен")
AND created_at < NOW() - INTERVAL 3 DAY; (И дата создания старше 3 дней от текущего момента)

Найти пользователей без подтвержденного email’a:

SELECT id, email (Выбираем только ID и email)
FROM users (Из таблицы users)
WHERE email_verified = false; (Где email не подтверждён)

3. Проверка количества записей (COUNT)
Когда использовать: для проверки массовых операций

Сколько пользователей зарегистрировалось сегодня:

SELECT COUNT(*) (Считаем общее количество записей)
FROM users (В таблице users)
WHERE DATE(created_at) = CURRENT_DATE; (Где дата регистрации = текущий день)

4. Обновление тестовых данных (UPDATE)
Важно! Используйте только в тестовых базах и всегда делайте резервную копию перед массовыми изменениями

Сбросить пароль тестового пользователя:

UPDATE users (Обновляем таблицу users)
SET password = 'test123' (Задаём новое значение для поля password)
WHERE email = 'test@example.com'; (Условие: только для пользователя с этим email)

Изменить статус заказа:

UPDATE orders (Обновляем таблицу orders)
SET status = 'completed' (Меняем статус на "completed")
WHERE id = 12345; (Условие: только заказ с ID 12345)

5. Удаление тестовых данных (DELETE)
Осторожно! Используйте только в тестовых базах и всегда делайте резервную копию перед массовыми изменениями. Всегда сначала делайте SELECT с тем же условием

Удаление тестовых заказов:

DELETE FROM orders (Удаляем записи из таблицы orders)
WHERE user_id IN ( (Где user_id соответствует…)
 SELECT id FROM users (…ID из таблицы users)
 WHERE email LIKE '%test%' (…для email с подстрокой "test»)
);

🔧 Как тренироваться?
На помощь приходят бесплатные тренажеры, например:
▫️https://sqlbolt.com/
▫️https://sqlzoo.net/
▫️https://sql-academy.org/ru/trainer

📕 Maven + Gradle: история успешного тестирования для QA-инженеров, начинающих автоматизаторов и всех, кто хочет уверенно настраивать проекты под автотесты

На открытом уроке 26 августа в 20:00 мск мы погрузимся в тонкости создания и настройки проектов для автотестов:

📗 На вебинаре разберём:
1. Создание проекта для автотестов с Maven и Gradle.
2. Как подключать библиотеки: JUnit, Selenium, Allure.

📘 В результате на практике сравните Maven и Gradle, разберетесь в их плюсах и минусах и выберете подходящий инструмент под свои задачи.

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

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

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

👁‍🗨 Agile vs Waterfall
Источник

Всем привет! Давайте разберёмся, в чём разница между Agile (Scrum/Kanban) и Waterfall, и как это влияет на нашу работу.

🌊 Waterfall («Водопад»)

Как работает:
1. Этапы идут строго друг за другом (как вода в водопаде):
Требования → Дизайн → Разработка → Тестирование → Внедрение → Поддержка
2. Тестирование - в самом конце (когда весь продукт уже готов)

Плюсы для QA:
▫️Чёткий план (знаем все требования заранее)
▫️Участники проекта, не задействованные на определенной фазе, могут переключаться на другие проекты
▫️Подходит для госпроектов, систем, где нельзя менять требования и для модернизации уже существующих проектов

Минусы:
▫️Если баг найден поздно - исправлять дорого
▫️Нет гибкости

🔄 Agile (Scrum, Kanban)

Как работает:
1. Разбиваем проект на маленькие кусочки (итерации по 2-4 недели)
2. Тестируем каждую фичу сразу (не ждём конца разработки)

Scrum
- Есть спринты (обычно 2 недели)
- Каждый день daily (короткая ежедневная встреча команды разработки, которая проходит в одно и то же время. На ней каждый участник команды отвечает на вопросы «Что было сделано вчера? Что буду делать сегодня? Есть ли что-то, что может помешать работе над задачами спринта?»)
- Тестировщик встроен в команду (не отдельный «отдел»)

Kanban
- Нет спринтов - гибкий поток задач
- Задачи висят на доске, их прогресс наглядно виден по колонкам статусов (To do → In Progress…)

Плюсы для QA:
▫️Быстрая обратная связь
▫️Раннее вовлечение в процесс
▫️Постепенное тестирование

Минусы:
▫️Нужно быстро адаптироваться (требования могут меняться)
▫️Много рутины (ежедневные митинги, ретроспективы)

⚖️ Что лучше для тестировщика?

- Скорость: Waterfall - медленно, Agile - быстро
- Гибкость: Waterfall - нет, Agile - да
- Риски: Waterfall - баги находятся поздно, Agile - ловим баги в процессе разработки
- Документация: Waterfall - много, Agile - минимум

отличная идея)