Библиотека тестировщика | QA, тестирование, quality assurance, manual testing, autotesting, ручное тестирование, автотесты

🪲 Правда о багрепортах

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

«Не работает»,
«Иногда падает»,
«Тут что-то странное»

— классика жанра.

А потом разработчик сидит и вызывает дух предков, чтобы воспроизвести «вот это самое странное» 😺

Как вы реально пишете багрепорты? ⬇️

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

#стендап_qa

🚀 Шпаргалка для автотестировщика

Устали каждый раз гуглить синтаксис Selenium?

Держите полную шпаргалку по WebDriver на Java — все самое нужное на одной странице:

➡️ Локаторы и работа с элементами
➡️ Ожидания и JavaScript
➡️ Алерты, фреймы, переключение между окнами
➡️ Настройки браузеров и прокси
➡️ Скриншоты и drag-and-drop

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

#артефакт

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

#прод_в_пятницу

🧩 Файл прошёл валидацию… потому что проверяли только расширение

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

🎥 Платформа позволяла загружать PDF-файлы с договорами. Валидация была простой:
— разрешить .pdf
— запретить всё остальное.

Проблема вскрылась случайно: один клиент загрузил видео, переименовав его в contract.pdf.

И система спокойно приняла файл.

🎥 Что пошло не так:

— Проверяли только расширение.

— MIME-тип определялся по тому же расширению.

— На серверной стороне отсутствовала проверка сигнатур файла.

— В логах ошибка декодирования PDF подавлялась и отмечалась как «не критичная».

В итоге backend получал битые данные, а фронт показывал «Документ принят».

📌 Чтобы такие ситуации не повторялись, сохраните себе небольшой чек-лист валидации файлов — он на картинке 🎀

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#тест_драйв

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

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

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

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

#артефакт

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

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

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

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

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

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

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

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

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

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

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

#стендап_qa

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

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

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

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

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

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

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

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

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

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

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

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

🚶‍♂️ 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% мужчин — дальтоники. Находите реальные баги.

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

#тест_драйв

☝️ Эти 5 фраз — ваш лучший детектор багов

Услышали одну из этих фраз на созвоне? Включайте радар — цель найдена. Эти фразы — не вредность. Это когнитивные ловушки, в которые попадает каждый:

🅰️ Проклятие знания

Разработчик видит код изнутри. Тестирует как программист, а не как пользователь.

🅰️ Селективное восприятие

Проверил один сценарий → "работает". Edge cases? А что это?

🅰️ Ложная уверенность

«Одна строка кода — что может пойти не так?» (Narrator: многое пошло не так)

📉 Реальный случай:

“Быстрый фикс, не тестируй”

Меняли формат даты DD.MM.YYYY → DD/MM/YYYY

Сломали импорт CSV, фильтры и API-интеграции.

10 мин теста против 6 ч hotfix’а и отката 🤦‍♂️

✅ Мини-чек-лист:

• Работает на моей машине → проверьте окружение

• Я проверял → уточните сценарии

• Быстрый фикс → smoke-тест минимум

• Legacy → спросите у саппорта, кто юзает

• Очевидно → если нет спеки, ничего не очевидно

Какая фраза вам встречается чаще всего ❓

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

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

🛒 Black Friday от Proglib.academy!

Только до 30 ноября — скидка 40% на ВСЕ курсы.

Пора добавить в корзину не носки, а новые скиллы: Python, математика для Data Science, AI, алгоритмы и структуры данных, ML.

🎓 Выбирай курс, который реально двинет тебя в карьере, и учись со скидкой.

👉 Учиться со скидкой

🔄 Idempotent — что это такое

Если система получает одинаковый запрос несколько раз, а результат не меняется — операция идемпотентна. Это важно, когда возможен дубль клика или повтор запроса из-за таймаута.

🔴 Пример из жизни

✅ Идемпотентно:

Выключатель света

• Нажал 1 раз → свет выключен
• Нажал ещё 10 раз → свет всё равно выключен

❌ Неидемпотентно:

Кнопка «добавить в корзину»

• Нажал 1 раз → 1 товар
• Нажал 5 раз → 5 товаров

🔴 Где проверять:

— API-методы (особенно PUT, DELETE)
— Кнопки, которые можно нажать дважды
— Повтор запросов при таймаутах или нестабильной сети

🔴 Типичный баг

POST /create-payment
Клик → 100₽ списано
Двойной клик → 200₽ списано ❌

🔴 Правильная реализация

PUT /payment/123
1 запрос → платёж создан
10 запросов → платёж всё равно один ✅

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

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

💻 Хочешь MacBook Pro? Просто начни учиться!

Да-да, вы не ослышались: Proglib.academy дарит макбук за учёбу!

Всё просто:

— купи любой курс Академии до 15 ноября;
— пройди 2 недели обучения (можно за два дня);
— напиши куратору в чате курса хэштег #розыгрыш.

📚 Выбирай свой курс:

▫️ «Математика для DS» — для тех, кто хочет уверенно работать с данными;
▫️ «Основы Python» — чтобы начать писать код с нуля;
▫️ «Алгоритмы и структуры данных» — для будущих инженеров;
▫️ «AI-агенты» или «Машинное обучение» — для тех, кто хочет прокачаться в ИИ.

👉 Участвовать в розыгрыше

💡 Что нужно знать про приоритет и серьёзность багов

В прошлом посте мы говорили о классификации багов — не по определениям, а по тому, как вы объясняете реальные кейсы из продакшена.

Теперь следующий шаг: баг найден — что чинить первым, а что подождёт? 🤔 На собесе не важно, знаете ли вы формулировку из ISTQB. Важно — умеете ли расставить приоритеты, когда всё горит.

Эти карточки помогут:

➡️ отличать срочность от важности;
➡️ видеть разницу между бизнес-критичными и техническими багами;
➡️ звучать уверенно без зубрёжки.

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

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