🚶‍♂️ Chrome для тестировщиков: фишки, о которых молчат

Забудьте базу вроде "Copy as cURL". Вот трюки, которые сэкономят часы:

🟣 Conditional Breakpoints-хак

user.role = 'admin', false

Breakpoint не сработает, но переменная изменится. Тестируем права без деплоя.

🟣 chrome://net-export/

HAR для слабаков. Экспортируйте ВСЁ сетевое взаимодействие с шифрованием и DNS. Ловит баги, которые HAR пропускает.

🟣 queryObjects(Promise)

Найдите все промисы в памяти:

queryObjects(MyComponent)

🟣 monitorEvents($0, "mouse")

Выбрали элемент → ввели команду → видите все события live. Забудьте про addEventListener для дебага.

🟣 getEventListeners($0)

Покажет все обработчики на элементе. Правый клик → в код.

🟣 copy($0)

Копирует что угодно в буфер:

copy(await (await fetch('/api')).json())

🟣 Emulate Vision Deficiencies

Rendering → дальтонизм/размытие. 8% мужчин — дальтоники. Находите реальные баги.

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

#тест_драйв

🤍 Что отличает senior-тестировщика от middle

Многие думают, что переход в senior — это про новые инструменты, фреймворки и CI/CD. На деле — это про смену мышления.

🈶 От проверки — к проектированию

Middle ищет баги. Senior — ищет причины, почему они появляются.
Он проектирует процессы так, чтобы дефекты не доходили до продакшена.
Не тестирует — обеспечивает качество.

🈶 От задач — к приоритетам

Middle закрывает тест-кейсы. Senior решает, какие проверки важнее, а какие можно отложить.
Он управляет рисками, а не списком задач.

🈶 От индивидуальности — к влиянию

Middle делает работу. Senior обучает, менторит, делится подходами, поднимает планку для всей команды.
Он не просто тестирует — он формирует культуру качества.

🈶 От автотестов — к системному мышлению

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

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

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

🤔 Что важнее в автотестах

Скорость, стабильность или покрытие? Этот вопрос делит команды автоматизации на три непримиримых лагеря.

♌️ Скорость превыше всего

— Быстрый фидбек = быстрая разработка
— Долгие тесты никто не запускает локально

♌️ Стабильность — основа доверия

— Каждый флейк = 15–30 минут расследований «это баг или тест?»
— Нестабильные тесты → отключённые тесты → дыры в покрытии

♌️ Покрытие решает

— Один критичный баг в проде дороже всех оптимизаций
— «80 % покрытия» — а что покрыто: логика или геттеры?

❓ А что выбираете вы:

👍 — Скорость (быстро узнать о багах)
❤️ — Стабильность (доверие к результатам)
🔥 — Покрытие (защита от регрессии)

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

#стендап_qa

📌 Шпаргалка по написанию тест-кейсов

Как оформить тест-кейс так, чтобы его поняли и разработчики, и аналитики:

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

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

#артефакт

🧪 Логи: читать вручную или собирать автоматически

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

➡️ Ручной просмотр

— даёт ощущение продукта «изнутри»

— помогает замечать необычные последовательности и поведенческие аномалии

— но съедает часы и требует высокой концентрации

➡️ Парсеры и алерты

— быстро подсвечивают ошибки, пики, повторяющиеся паттерны

— помогают масштабировать контроль качества без ручной рутины

— но легко превратить анализ логов в «жду оповещение» вместо активного исследования

👍 — Логи руками
❤️ — Пусть машины ищут аномалии

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

#тест_драйв