📣 Подборка материалов на выходные

Если хотите освоить тестирование API — небольшая подборка для быстрого старта.

1️⃣ Как тестировать API

Базовое видео, объясняющее, что такое API и как его тестировать.

2️⃣ API Testing in 8 Minutes in Simple Terms

Быстрое и понятное видео о том, зачем тестировать API и с чего начать.

3️⃣ Про API, REST API для начинающего тестировщика

Статья с объяснением типов запросов, методов и примеров тестирования.

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

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

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

🧑‍💻 TestRail vs Jira

Когда команда QA выбирает инструмент — рождается холивар между удобством и интеграцией.

➡️ TestRail

— Специализированный для управления тестами

— Подробные отчёты и метрики

— Легко интегрируется с CI/CD

➡️ Jira

— Расширение для Jira

— Тесная интеграция с задачами и баг-трекером

— Ограниченная аналитика в сравнении с TestRail

Голосуем реакциями:

👍 — TestRail
❤️ — Jira Test Management

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

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

#тест_драйв

🧩 Что такое State Transition Testing

Это метод тест-дизайна, который помогает проверять, как система ведёт себя при переходе из одного состояния в другое.

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

Пример:

Допустим, у нас есть простая онлайн-форма подписки с тремя состояниями:

🟢 Не подписан

🟡 Подписка в обработке

🔵 Подписан

События: «Оформить подписку», «Подтвердить email», «Отменить подписку».

Тестируем переходы:

— Не подписан → Оформить подписку → Подписка в обработке

— Подписка в обработке → Подтвердить email → Подписан

— Подписан → Отменить подписку → Не подписан

➡️ Зачем нужно:

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

— выявляет баги при неожиданных последовательностях действий

— делает тесты системными и понятными

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

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

💳 Шпаргалка по REST API

Все основы внутри:

— методы GET/POST/PUT/PATCH/DELETE,
— коды ответов 200–500,
— параметры, заголовки и JSON-примеры.

Полезно для подготовки к интервью.

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

#артефакт

🧨 Релиз без багов — миф или цель

Прод-релиз всегда как квест: всё готово, тесты зелёные, но чувство тревоги остаётся. А если баг всё-таки вылез — виноват тестировщик или процесс?

❓ Что чаще ломает релиз:

👍 — Недостаток времени на тестирование

❤️ — Плохая коммуникация в команде

Сейчас на курсы Proglib действует −40%🥰

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

#стендап_qa

🔆 Когда баг не ловится

Клиент сообщает, что у него ошибка, но вы не можете её повторить. Ваши шаги?

Классическая ситуация для QA: баг «живёт» у пользователя, но у вас всё работает идеально.

🔜 Как действовать:

🔘 Собрать контекст: версия браузера, устройство, ОС, время, скрин/видео, логи.

🔘 Сравнить окружения: проверить конфигурацию продакшна, теста и staging.

🔘 Поиграть с данными: возможно, баг зависит от конкретного пользователя, роли или состояния кэша.

🔘 Записать наблюдения: даже если не воспроизводится — оформить отчёт с гипотезами и шагами.

💡 Хороший ответ звучит не как «не смог повторить», а как «исследовал, собрал данные и сузил возможные причины».

Таких специалистов ищут — не тех, кто ищет баги, а тех, кто ищет истину.

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

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

🛎 Верификация vs Валидация

Два термина, которые звучат почти одинаково, но означают разное:

ℹ️ Верификация — делаем по требованиям. Проверяем, что система работает как описано в ТЗ.

Мы сделали правильно.

ℹ️ Валидация — делаем для пользователя. Проверяем, что система решает нужную задачу.

Мы сделали то, что нужно.

📎 На картинке выше — лучший способ запомнить разницу: коротко, смешно и по делу.

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

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

💾 Бэкап был… но не тот

История, которая случается чаще, чем кажется.

После обновления сервис лег — стандартная процедура: откат, восстановление базы из последнего бэкапа.
Через пару минут — всё работает. Все выдохнули.

А потом начали писать пользователи:
— «Почему пропали заказы за вчера?»
— «А где новые пользователи?»

Выяснилось, что «последний бэкап» — не совсем последний.
Скрипт резервного копирования упал ещё неделю назад, но CI продолжал показывать «успешно».
Файл бэкапа был, просто не тот.

В итоге — минус неделя данных, ночная ручная реконструкция заказов и один очень печальный lesson learned.

📌 Что в итоге:

— Не доверяйте надписям «Backup OK» — тестируйте восстановление реально.

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

— Раз в квартал проводите disaster recovery drill — симуляцию аварии.

— И главное: не думайте, что беда случается только у других 🙂

❓ А вы когда-нибудь проверяли, что ваш бэкап реально восстанавливается?

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

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

🔥 Гайд по UI-автотестам, часть 2

Ранее мы выкладывали часть 1, где рассматривали основы настройки стека и структуры тестов.

🆖 Теперь давайте перейдём к локаторам, тестовым данным и борьбе с нестабильными тестами.

1️⃣ Локаторы:

– Используйте data-testid или data-qa, не //div[3].

– Не ставьте sleep(). Только встроенные waitForSelector() или locator.waitFor().

2️⃣ Тестовые данные:

– Не кликайте UI ради подготовки. Поднимайте данные через API или SQL.

– Каждый тест должен быть независим — без состояния от предыдущих.

– Если нужно авторизоваться — делай фикстуру для логина.

3️⃣ Устраняйте «флейки»:

– Если тест падает нестабильно, не добавляйте ретрай, найди причину.

– Тесты, которые часто ломаются, пометь @flaky и заведи задачу.

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

#тест_драйв

💰 Сколько стоит ноутбук тестировщика

Видели тут спор: одни говорят, что для тестирования хватит любого ноута за 50к, другие настаивают на топовых конфигурациях за 200k+.

🔜 Давайте соберем реальную картину — напишите:

— Что у вас сейчас (модель + конфиг)

— Сколько стоил

— Хватает ли для ваших задач

Может, наконец выясним, какое железо реально нужно QA, а где просто маркетинг? 🤔

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