🚬 Три степени боли продакшена

В продакшене что-то сломалось. Как понять, на каком уровне разбираться?

🟣 Incident (инцидент)

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

Пример: кнопка «Купить» не работает. Пользователи жалуются.

🟣 Problem (проблема)

Причина, стоящая за одним или несколькими инцидентами. Если её не устранить, инциденты будут повторяться.

Пример: форма не обрабатывает спецсимволы в имени товара → падает несколько страниц.

🟣 Error (ошибка)

Конкретная ошибка в коде, конфигурации или данных, которая вызвала проблему.

Пример: регулярка валидации имени товара не учитывает юникод.

Суть процесса:

🔤 Инциденты фиксируем быстро, чтобы пользователи не страдали.

🔤 Проблему исследуем глубже, ищем повторяющиеся паттерны.

🔤 Ошибку исправляем на уровне кода/инфраструктуры.

🔗 Видео по терминам для закрепления

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

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

💥 Мок ≠ Прод

Наш подписчик пишет:

Все автотесты были зелёные, CI светился зелёным, локально всё работало идеально… а на проде корзина пустая. Абсолютно пустая. Пользователи начали писать, что товары «исчезли» после добавления.

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

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

Итог: ночь отката, несколько часов расследования и крепкий урок: моки — это хорошо, но интеграционные тесты на проде никто не отменял.

📌 Всегда проверяйте реальные интеграции, особенно если речь о критичных флоу, вроде корзины или платежей.

🎓 Если хотите разобраться, как правильно проектировать тесты и API, загляните на курсы Proglib — сейчас скидка −40 %, пока не ушла в прод 🙂

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

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

🔥 Гайд по UI-автотестам, часть 3: отчёты и метрики

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

💡 1. Артефакты при падении

Сохраняйте всё, что поможет быстро разобраться:

– скриншот страницы
– видео прогона
– network-лог
– trace (пошаговое выполнение)

Так отладка займёт минуты, а не часы.

📂 2. Документация

README.md должен быть понятным:

– как установить зависимости
– как запускать smoke и регресс
– как добавить новый тест

Добавь пару примерных тестов как шаблон, чтобы новичку было проще стартовать.

📈 3. Метрики стабильности

Следите за реальными показателями работы автотестов:

– сколько тестов проходит стабильно
– сколько занимает полный прогон
– сколько багов нашли до релиза

Эти данные помогают понять, где тесты слабые и где нужен приоритет улучшений.

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

#тест_драйв

💬 Логи или UI — где искать истину

🐞 Баг воспроизводится только на проде. QA говорит: «у меня всё видно на экране!» Дев отвечает: «в логах всё чисто!»

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

❓ Как вы считаете:

❤️ — Интерфейсу, ведь он ближе к пользователю

👍 — Логам, ведь они не врут (если пишутся правильно)

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

#стендап_qa

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

Коротко о том, какие бывают требования и как их проверять:

— бизнес (зачем),
— пользовательские (что),
— функциональные (как),
— нефункциональные (насколько хорошо).

🔗 Ссылка на шпаргалку

🎓 На курсах Proglib можно разобраться, как устроены API, архитектура и тест-дизайн; сейчас −40 %

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

#артефакт

🦾 Low-code инструмент для автоматизации тестирования

Katalon Studio — единое решение для тестирования Web, API, Mobile и Desktop-приложений.

Что умеет:

➕ Работает поверх Selenium, Appium и RestAssured

➕ Запись действий (Record & Playback)

➕ Шаблоны тестов и сценариев без кода

➕ Поддержка CI/CD, Jenkins и отчётов

Подходит тем, кто хочет автоматизацию без сложного кода — удобно для QA, аналитиков и начинающих в авто-тестах.

🔗 Ссылка на инструмент

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

#тест_драйв

🐚 «А можно ещё раз протестить?»

Девы пофиксили — отлично. Но теперь не работает то, что раньше работало. Regression снова в деле.

Классика: фиксы решают проблему в одном месте и случайно ломают другое. Поэтому тесты — это не только «нашёл баг», но и «не сломали ли что-то ещё».

❓ Вы как:

👍 — Тщательно проверяю: регрессы, смежные фичи, smoke и быстрый ретест критичных путей

❤️ — Верю в фиксы: вернулся к следующему таску, если релиз в норме

Совет: при фиксе добавляйте минимальный регресc-тест — так меньше «еще раз протестировать» в будущем.

🔤 Если хочется автоматизировать — гляньте курс по Python, сейчас −40%

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

#стендап_qa

❓ Почему баг возвращается

Баг закрыли, релизнули, выдохнули — и вот он снова в проде. Да-да, это déjà vu для QA.

Причины всего две 🔜

🈶 Reopened — баг реально не исправили.

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

🈶 Flaky — баг то есть, то нет.

Он зависит от окружения, времени, случайности.
Сегодня тест прошёл — завтра упал.
→ Настоящий фантом, любимец CI/CD.

🧩 Как отличить:

— Reopened повторяется стабильно.
— Flaky живёт своей жизнью.

💡 Советы:

— Всегда фиксируйте окружение и логи.

— Если дефект «пляшет» — проверь асинхронность, тайминги, race conditions.

— Не бойтесь написать: «баг не детерминированный». Это не слабость, это диагноз.

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

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

💬 Шпаргалка по Git-коммитам

Коротко о том, как писать понятные и единообразные сообщения в стиле Conventional Commits.

ℹ️ Поможет QA и разработчикам быстро ориентироваться в истории проекта и поддерживать чистоту репозитория.

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

#cheat_sheet

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

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

🦉 Подборка материалов: BVA и EP

Если вы до сих пор проверяете «на глаз» или «по интуиции», пора системно подойти к тест-дизайну. BVA и EP — два базовых, но мощных метода, которые экономят время и находят баги там, где не ждёшь.

Что изучить:

➡️ Что такое Equivalence Partitioning (EP)

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

➡️ Boundary Value Analysis (BVA)

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

➡️ Практика на реальных кейсах

➡️ Обзор техник и кейсов

➡️ Автоматизация EP/BVA

➡️ Советы по pytest

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

#release_notes

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

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