💬 Логи или 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

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

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

😠 Чему тестировщики могут научить разработчиков

Тестировщики часто кажутся теми, кто «приходит после». Но на самом деле — это те, кто смотрит вперёд. Они видят не код, а последствия.

➡️ Думать в сценариях, а не в строках кода

Разработчик пишет функцию, тестировщик видит поведение. Код может быть идеален, но пользователь нажмёт не туда — и всё рухнет. QA напоминает: мир шире happy path-а.

➡️ Сомневаться в очевидном

«А если не сработает?»

Это не скепсис, а гигиена мышления. Тестировщики учат не верить первому успешному результату — и это делает систему устойчивой.

➡️ Искать закономерности, сбои

QA видит баги не поодиночке, а как паттерны. Если что-то ломалось так раньше — сломается и снова. Это и есть системное мышление.

➡️ Говорить о проблемах без обвинений

Тестировщики каждый день приносят «плохие новости». И делают это так, чтобы команда не закрылась, а пошла решать. Они учат культуре обратной связи:

«Не ты плохой — просто система не выдержала».

➡️ Видеть продукт глазами пользователя

QA — единственные, кто по-настоящему ходит по интерфейсу как человек. Они напоминают: юзер — не дебаггер, а человек.

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

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

🧬 Тестовые данные: из жизни или из скрипта

QA-дилемма старше Jenkins.

➡️ Реальные:

— Отражают поведение настоящих пользователей
— Ловят неожиданные edge-кейсы
— Но несут риски приватности и утечек

➡️ Тестовые:

— Безопасны и под контролем
— Легко обновлять и масштабировать
— Но часто слишком «стерильные» для реального мира

👍 — Настоящие
❤️ — Сгенерю сам/а

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

#тест_драйв

🤟 QA-мемы: делимся любимыми

Каждый тестировщик хоть раз узнавал себя в меме — ошибки, баги, дедлайны и легендарное «а у меня работает» 😅

Скиньте в комменты свой любимый мем — тот, что лучше всего отражает вашу боль или иронию профессии. 🔜

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

#стендап_qa