🚨 Кейс: массовый логаут в Slack

Миллионы пользователей внезапно вылетели из аккаунтов. Люди не могли войти обратно без сброса пароля.

Причина:

— Ошибка при выпуске обновления клиента.
— Slack некорректно помечал cookies как недействительные → система решила, что все пользователи «неавторизованы».

Чем обернулось:

— Массовая паника в рабочих чатах.
— Рост нагрузки на поддержку (тикеты о «взломе аккаунта»).
— Временные простои в работе команд.

Выводы для QA:

➡️ Проверка обновлений не должна ограничиваться юнит-тестами — критичны e2e сценарии.

➡️ Автотесты должны учитывать работу с cookies/session management.

➡️ На стейджинге важно эмулировать сценарий «массового обновления» и нагрузку.

➡️ План реагирования (incident response) нужен даже у SaaS-гигантов.

💡 Иногда «простой баг» в cookies превращается в глобальный инцидент.

— А у вас бывало, что баги с авторизацией рушили прод?

🐸 Библиотека тестировщика

#разбор_полетов

🎯 QA-коллеги, этот митап YADRO в Нижнем Новгороде точно для вас!

Обсудим тестирование телеком-систем: как фиксируем результаты, какие инструменты используем, зачем нужен автомобиль-лаборатория и как проходить сертификацию по 3GPP.

В программе:
— Приветственное слово: как YADRO с нуля создаёт телеком-решения и базовые станции GSM/LTE (Анатолий Зубашев, YADRO).
— «Тестирование в телекоме: взгляд изнутри»: фиксация результатов, инструменты и автомобиль-лаборатория; уровни и виды тестов, этапы жизненного цикла и команды (Алексей Нелюбов, YADRO).
— «Как мы проверяем приёмник и передатчик на соответствие 3GPP и российскому законодательству»: conformance-тестирование и путь к сертификации, со снимками экрана спектроанализатора (Анна Курина, YADRO).
— Секретный доклад.

📅 Дата: 9 октября 2025 года
📍 Место: Нижний Новгород, Кремль, корпус 6, «Арсенал», левое крыло
🕕 Время: сбор гостей с 18:00, начало в 19:00
🎟 Формат: онлайн и офлайн. Участие бесплатное, по предварительной регистрации.

Офлайн-участников ждут: демозона, квесты, подарки, угощения и общение на afterparty.

💙 Регистрация открыта. Количество мест ограничено.

🧪 5 скрытых фишек Playwright

➡️ Tracing

Playwright может записывать все шаги теста (с скриншотами, сетевыми запросами и логами). Потом открываете trace viewer и разбираете баг, как «черный ящик».

➡️ network.route()

Позволяет перехватывать и подменять сетевые запросы прямо в тестах. Удобно для эмуляции ошибок API или проверки офлайн-сценариев.

➡️ test.step()

Даёт красивую группировку шагов в отчётах. Можно структурировать сценарий и сразу видеть, на каком шаге упал тест.

➡️ Fixtures с авто-setup/teardown

Через test.use() можно объявлять окружение один раз, а Playwright сам будет поднимать/гасить браузеры, логины и мок-сервисы. Экономит тонны кода.

➡️ Web-first assertions

Вместо «жёстких» ожиданий — встроенные проверки, которые сами ждут появление элемента или изменения состояния. Тесты становятся стабильнее и короче.

🐸 Библиотека тестировщика

#тест_драйв

👍 Как выделиться джуну, даже без проектов

Все пишут про «сделай пет-проект» — но что ещё реально поможет?

1️⃣ Reverse QA

Возьмите готовое приложение и составь не только баги, но и гипотезы улучшений (UX, производительность, безопасность). Это покажет широту мышления.

2️⃣ Публичный след

Ведите Telegram/LinkedIn/Notion-блог про то, как вы учишься тестированию. Даже 5 статей «разбор багов недели» = демонстрация навыков.

3️⃣ Анализ чужих баг-репортов

Разберите публичные баги из Jira open-source проектов и покажи, как бы вы их переписали чётче. Это уже ваш кейс.

4️⃣ Нетворкинг-кейсы

Участвуйте в QA-челленджах, митапах или онлайн-хакатонах. Да, это не работа, но звучит солиднее, чем «учусь дома».

5️⃣ Английский = плюс 50% ценности

Даже если у вас мало опыта, но вы способны писать баги и общаться с командой на английском — для работодателя это почти опыт +1 уровень.

📌 Рекрутер ищет не только опыт, а доказательство, что вы умеете работать как QA.

🐸 Библиотека тестировщика

#карьерный_трек

🐈‍⬛️ Playwright vs Cypress: что выберете вы

Два инструмента для end-to-end тестирования, два подхода — и вечный спор в комьюнити QA.

➡️ Playwright

— Поддержка всех современных браузеров из коробки
— Быстрее и стабильнее на параллельных тестах
— Хорошо дружит с TypeScript и API-тестами

➡️ Cypress

— Простота и низкий порог входа
— Отличная визуализация тестов в реальном времени
— Большая база готовых рецептов и плагинов

Голосуем реакциями:

👍 — Playwright
❤️ — Cypress

🐸 Библиотека тестировщика

#стендап_qa

📂 Шпаргалка по Web UI

Собраны самые полезные приёмы и команды: от основ интерфейса до продвинутых трюков.

📌 Отличный быстрый помощник для работы и повторения.

🐸 Библиотека тестировщика

#артефакт

🔒 Как обезличить данные для разработки и не потерять их смысл?

Платформа «Сфера» и Anti-Malware.ru приглашают на бесплатный вебинар «Маскирование данных в СУБД: как безопасно передавать персональные данные разработчикам?».

Разберемся, как готовить для тестовых сред реалистичные данные, полностью соответствующие требованиям законодательства.

Что полезного вы узнаете на вебинаре:
🔘Чем обезличивание отличается от маскирования и псевдонимизации.
🔘Как выполнить требования закона и и минимизировать риски получения оборотных штрафов.
🔘По каким критериям выбирать инструмент для обезличивания данных.
🔘Как ML-модели помогают автоматически находить и классифицировать данные для маскирования.
🔘Разберем реальный опыт и кейсы от ВТБ и Росгосстрах.
🔘Покажем вживую, как работает решение «Сфера.Обезличивание данных».

И самое главное — в конце эфира все участники получат практическое руководство по обезличиванию ПДн для использования в работе.

📍Спикеры: Илья Шабанов (Anti-Malware.ru), эксперты из Сферы, ВТБ, Росгосстраха.

📆 8 октября в 11:00 мск

📍Онлайн, бесплатно

Регистрируйтесь, чтобы получить работающие практики и готовые решения!

Информация о рекламодателе.

🧩 Тестовые данные

Что самое безумное вы использовали в качестве тестовых данных, чтобы сломать систему ❓
(эмодзи, библейский текст, «капибара» на 1000 строк…)

Расскажите в комментах ⌨️

🐸 Библиотека тестировщика

#стендап_qa

🐛 Жизненный цикл бага

Баг — это не просто запись в трекере, а объект с «жизнью». У него есть статусы, которые помогают команде понимать, на каком он этапе.

На схеме 👆 показан один из классических вариантов:

Новый — только завели, ещё не распределён.

Назначен — передан конкретному разработчику.

Открыт — принят в работу.

Исправлен — есть фикс, ждёт проверки.

Ожидает повторного / Повторно тестируется — QA проверяет, решена ли проблема.

Проверен → Закрыт — баг подтверждён как устранён.

Отклонён / Отложен — команда решила баг не чинить сейчас.

Повторно открыт — если после фикса проблема вернулась.

⚡️ Зачем всё это:

— Прозрачность: команда всегда понимает, что происходит с багом.

— Управляемость: можно приоритизировать и отслеживать прогресс.

— Минимум хаоса: баги не теряются и не висят «в воздухе».

🐸 Библиотека тестировщика

#теория_на_пальцах