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

🤩

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

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

📎 Selenium — Java Cheat Sheet

Удобная шпаргалка по Selenium для тех, кто работает с Java и автоматизацией UI-тестов. В ней собраны самые нужные вещи: локаторы, динамические XPath, операции с элементами, ожидания, работа с окнами и аннотации TestNG/JUnit.

➕ Подходит как junior-тестировщикам, так и тем, кто хочет ускорить написание автотестов.

🔹 Основы IT для непрограммистов
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

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

#артефакт

🔥 Когда job-очередь превращается в кладбище задач

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

Что обязательно проверять:

✅ таймауты и поведение при зависании API;
✅ retry-политику и максимальное время обработки задачи;
✅ наличие DLQ и алертов на его переполнение;
✅ мониторинг очередей: размер, возраст задач, время обработки;
✅ поведение при перегрузке (10×, 100× нагрузка);
✅ идемпотентность — нет ли дублей и потерянных операций.

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

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

💧 Ещё один типичный анти-паттерн: «Капля»

Это когда много E2E-тестов и юнитов, но почти нет интеграционных.

Что идёт не так 🔜

— Юниты проверяют отдельные функции — всё ок
— E2E проверяют весь флоу — тоже вроде работает
— Но никто не проверяет, как модули работают вместе
— Баги в интеграции всплывают только на E2E — когда уже поздно

🔍 Признаки:

— «Юниты зелёные, но на проде всё падает»
— Долгая отладка E2E-тестов: непонятно, где именно сломалось
— Проблемы с API, базами данных, очередями находят только пользователи
— Между «функция работает» и «система работает» — чёрная дыра

🔤 Почему так получается:

Интеграционные тесты сложнее писать: нужны моки, стабы, тестовые окружения. Проще написать ещё один юнит или E2E. Но именно на стыках модулей и живут самые коварные баги.

🔗 Ссылка на первую часть, где разобрали песочные часы ⌛️

🔹 Основы IT для непрограммистов
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

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

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

❓ k6 vs JMeter: какой инструмент выбрать

k6 ⚡️ (Grafana Labs)

 • JS-скрипты, легко подключается к CI/CD
 • Метрики в реальном времени в Grafana
 • Лёгкий, подходит для контейнеров
 • Отличен для REST/GraphQL/API Gateway

− Только HTTP/Websocket
− Нет GUI — всё через код

JMeter 🏛 (Apache)

 • Множество протоколов (HTTP, JDBC, JMS, SOAP)
 • Огромная база плагинов

− Требует тюнинг JVM
− Тяжелый, плохо масштабируется в Docker
− XML-проекты сложно ревьюить

📌 Когда брать k6: CI/CD, микросервисы, API-first проекты.
📌 Когда брать JMeter: сложные протоколы, legacy, большой QA-отдел.

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

#тест_драйв

🎭 Разработчик закрыл ваш баг как «works as intended»

Кейс:

Вы нашли странное поведение: при быстром двойном клике система списывает деньги дважды. Создали баг-репорт. Разработчик закрыл тикет:

Пользователь не должен так быстро кликать, это edge case

Но в аналитике видно — такое происходит 50 раз в день.

❓ Что вы делаете:

👍 — Реоупеню с данными из аналитики
🤩 — Иду к тимлиду разработки напрямую
🥰 — Добавляю в документацию как «известное ограничение»
❤️ — Поднимаю на ретро, обсуждаем критерии edge case

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

#стендап_qa

Как найти баг в вероятности?

Тестирование AI-продуктов ломает мозг классическому QA. Здесь нет однозначного «Expected Result», есть точность, полнота и доверительные интервалы. Чтобы грамотно тестировать модели, нужно понимать статистику и теорию вероятностей.

Приходите на курс «Математика для разработки AI-моделей». Старт завтра!

Вы получите инструменты для анализа качества ML-систем всего за 28 200 ₽.

Не упустите шанс прокачать скиллы:

👉 Подробнее о курсе

🎁 Бесплатный тест: @proglib_academy_webinar_bot

🧰 Полезная Linux-шпаргалка

Короткий набор команд, который выручает при работе с логами, файлами и сервером.

🎈 Удобно сохранить, чтобы быстро проверять состояние системы и искать нужные данные во время тестирования.

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

#артефакт #linux

🌎 Тёмная сторона работы QA за рубежом

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

♾ В карточках: 4 ключевых аспекта, которые влияют на нагрузку, стабильность и карьерный рост тестировщика.

🔹 Основы IT для непрограммистов
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

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

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

🎯 npoint — мокинг API за 2 минуты

Простой инструмент для создания публичных mock API-эндпоинтов. Без серверов, без кода.

Как работает:

1. Вставляете JSON
2. Получаете постоянный URL
3. Используете в тестах

Когда пригодится:

✅ Фронтенд готов, бэкенд нет
✅ Нужны стабильные данные для автотестов
✅ Быстрое прототипирование
✅ Воспроизведение специфичных сценариев

Ограничения:

⚠️ Данные публичны (не для секретов)
⚠️ Нет логики и авторизации
⚠️ Только GET-запросы

Для сложных сценариев лучше WireMock или Mockoon, но для быстрых экспериментов npoint — идеален.

📎 Ссылка на GitHub

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

#тест_драйв

📌 Дублирующиеся ID после миграции

После перехода на новую базу всё казалось стабильным… пока не начали появляться странности:

— статусы то обновляются, то откатываются назад,
— операции «пропадают»,
— два сервиса показывают разный результат на один и тот же запрос.

Первой версией было «что-то с очередью». Потом — «кэш обновляется не вовремя».
Но настоящая проблема оказалась глубже.

🔍 Что случилось:

Два независимых сервиса после миграции начали генерировать идентификаторы по одному и тому же алгоритму.
ID стали пересекаться → и часть событий система просто отбрасывала как «дубликаты».

Для пользователя — хаос.
Для аналитики — мусор.
Для поддержки — магия чёрного ящика.

👀 Почему так произошло:

— Нет централизованного механизма генерации ID

— Не было нагрузочных тестов, которые проверяют коллизии при параллельной работе

— Миграция прошла формально: архитектурные предположения не пересмотрели

Идеальная демонстрация того, как маленькая деталь ломает целую цепочку сервисов 📌

❓ А вы проверяете уникальность ID под нагрузкой:

👍 — Да, есть dedicated тесты
❤️ — Иногда, только в критичных потоках
😁 — Хм… теперь задумался

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

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

📌 Песочные часы» в тестировании

Это ситуация, когда в проекте мало юнит-тестов, почти нет среднего слоя,
но при этом много тяжёлых E2E.

Структура получается перевёрнутой: тонкое основание и тяжёлая верхушка.

🔴 Как понять проблему «на пальцах»:

Представьте дом, у которого
— снизу тонкая опора,
— сверху огромная тяжёлая конструкция.
Стоит это, конечно, но шатается от любого прикосновения.

🔴 Почему это опасно:

— E2E медленные и дорогие.
— Любой сбой трудно отлаживать: непонятно, где именно ошибка.
— Любой PR может уронить половину тестов.
— Время выполнения растёт, команда буксует.

🔍 Признаки в проекте:

— Пайплайн запускается минутами или часами.
— От изменения одной кнопки падают десятки сценариев.
— Юнит-тестов мало или нет вовсе.

🔹 Основы IT для непрограммистов
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

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

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