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

Кейс:

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

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

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

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

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

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

#стендап_qa

❓ 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-отдел.

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

#тест_драйв

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

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

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

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

🔍 Признаки:

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

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

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

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

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

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

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

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

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

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

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

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

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

🔴 Playwright 1.57.0 — свежее обновление

Вышел новый релиз Playwright 1.57.0. Главное, что в нём стоит знать:

✅ Новые режимы обновления снапшотов:

Появилась поддержка:
• overwrite — полностью перезаписывает,
• 3-way merge — аккуратно вносит изменения.

Это уменьшает конфликты в Git и делает визуальные тесты стабильнее.

✅ Улучшения стабильности и работы с тестовыми файлами:

Чище диффы, меньше случайных перезаписей и более предсказуемые CI-прогоны.

📎 Источник

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

#release_notes

🔺 Анти-ппатерн: «Реверсивная пирамида»

Это структура, где основная масса тестов — интеграционные. Юнитов мало, E2E немного, но середина раздута и нестабильна.

В чём проблема:

— Интеграционные тесты начинают писать «на всё» — они дороже юнитов и медленнее.
— Сценарии слишком широкие: контроллер + сервис + база + кэш.
— Отладка превращается в поиск иголки в стоге — падает много, причина одна.
— Пайплайн растёт, прогоны удлиняются, а ценности меньше, чем кажется.

🔍 Признаки:

— «У нас огромный пакет API-тестов, но юнитов почти нет».
— Любая правка в схеме данных ломает десятки–сотни проверок.
— Граница ответственности размыта: тесты проверяют всё сразу.

💡 Как лечить:

— Строить нормальную пирамиду: много юнитов → умеренно интеграционных → минимум необходимого E2E.
— Чётко ограничивать ответственность каждого уровня.
— Интеграционные тесты — только для критических связей, а не для всего приложения.

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

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

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

🌐 Визуализация JSON в диаграммы

Расширение для VS Code, которое превращает JSON-файлы в интерактивные графы: объекты, массивы и значения становятся связанными узлами.

🔴 Чем полезно для QA:

• Быстро понять структуру сложных API-ответов без чтения кода
• Находить вложенности и связи между объектами визуально
• Проверять payload запросов и responses — ошибки видно сразу
• Удобно для дебага: где именно сломалась структура данных
• Работает с большими JSON — не нужно скроллить тысячи строк

Установка: открыть JSON → кликнуть иконку JSON Crack в menubar → получить граф.

Особенно полезно при тестировании REST API, анализе логов и валидации контрактов между сервисами.

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

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

#тест_драйв

🎭 PM говорит: «Это можно не тестировать, никто так не делает»

Кейс:

На продакшене форма регистрации. PM просит пропустить тестирование сценария: «Пользователь вводит email с +алиасом ([email protected])».

Аргумент:

«Обычные люди так не делают, только тестировщики»

Но RFC 5322 разрешает + в email. Gmail, Outlook, ProtonMail поддерживают. А ваша валидация — режет.

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

👍 — Тестирую всё равно, фиксирую баг
🤩 — Показываю статистику: сколько юзеров используют +alias
🥰 — Соглашаюсь, но добавляю в smoke после релиза
❤️ — Предлагаю A/B тест: смотрим реальную конверсию

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

#стендап_qa

❓ Что такое позитивное и негативное тестирование

"Positive testing — это проверка что приложение работает правильно с валидными данными. Например, если поле принимает числа от 0 до 99999, я ввожу валидное значение вроде 500 и проверяю что оно принимается.

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

Для тест-дизайна использую Boundary Value Analysis — тестирую граничные значения вроде -1, 0, 1 и 99998, 99999, 100000. И Equivalence Partitioning — делю входные данные на классы эквивалентности: валидные (0-99999) и невалидные (отрицательные, больше 99999, строки)."

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

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

🚩 JavaScript: методы массивов

Полная шпаргалка по базовым методам массивов в JavaScript — must-have для автоматизации тестирования.

Что внутри:

• push() / pop() — добавление и удаление элементов
• map() — преобразование каждого элемента
• filter() — фильтрация по условию
• find() — поиск первого элемента
• includes() — проверка наличия

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

#артефакт #js

📁 Промокод, который работал бесконечно

После запуска акции стало ясно: один и тот же одноразовый промокод используют сотни раз. Причина оказалась не в утечке — а в ошибке логики.

🔍 Суть проблемы:

Проверка «использовал ли пользователь промокод» выполнялась только через cookie.
На сервере не было ни проверки, ни учета.

Что делал пользователь:
— инкогнито → cookie нет → промокод снова активен
— другой браузер → снова работает
— чистка cookies → система «забыла» использование

Итог: бесконечные скидки → прямые убытки.

👀 Почему так бывает:

— доверие к клиенту (валидация только в браузере)
— нет проверки на уровне API: использовал ли этот user / email промокод
— отсутствие негативных сценариев в тест-плане
— привязка к сессии вместо user_id

❓ Тестируете такие кейсы:

👍 — Да, API и негативные сценарии
❤️ — Только функциональные проверки
😁 — Пару кликов руками
🔥 — Теперь точно добавлю в тест-план

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

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

⭐️ Scrum в реальной работе

Scrum-команды часто выглядят одинаково снаружи, но на практике процессы сильно отличаются от того, что описано в оригинальном руководстве.

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

🔗 Прикрепили русскоязычный перевод Scrum Guide — короткий документ, который стоит прочитать без адаптаций.

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

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

❓ Что передаём по HTTP-методам

🟡 GET — получить данные

Передаём: параметры в URL.

/api/products?category=books&page=2

🟡 POST — создать ресурс / выполнить действие

Передаём: тело запроса (JSON, формы).

🟡 PUT — полное обновление ресурса

Передаём: тело запроса (заменяет весь объект)

🟡 PATCH — частичное обновление

Передаём: тело запроса (только изменённые поля)

🟡 DELETE — удаление

Передаём: ID в URL, иногда — тело

🟡 HEAD — та же логика GET, но без тела ответа

🟡 OPTIONS — узнать, какие методы разрешены

Передаём: только URL.

🟡 CONNECT / TRACE

CONNECT — создаёт туннель (SSL).
TRACE — отладка, возвращает запрос обратно.

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

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

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

😳 Когда кеш работает… слишком хорошо

Реальный кейс:

После оптимизации сервис стал работать в 5 раз быстрее. Метрики зелёные, пользователи довольны, прод молчит — красота.

Но через неделю начинается:

💥 Один пользователь видит iPhone за 89 000₽, другой — за 102 000₽
💥 Товар «в наличии» в каталоге, но недоступен в корзине
💥 TTL кеша установлен на 5 минут, но данные не обновляются по 2 часа
💥 После изменения цены админом старое значение живёт ещё полдня

❓ Ваши действия:

👍 — Воспроизвожу: отключаю кеш, проверяю данные напрямую из БД, сравниваю с поведением на проде

🤩 — Иду к разработчику

🥰 — Завожу баг со скриншотами и шагами воспроизведения

❤️ — Поднимаю вопрос на ретро

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

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