👀 Почему регрессия появляется там, где её не ждут

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

🔤 Что такое скрытая зависимость:

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

Причины простые:

• один и тот же объект используется в разных модулях;
• общие кэши и настройки;
• переиспользуемые UI-компоненты;
• сервисы читают одни и те же данные с разной логикой.

💥 Почему это и рождает регрессию:

Сломать можно не то, что правил разработчик, а то, что зависит от его правки.

Пример:

Фикс в авторизации → изменилась структура токена → отвалился модуль корзины, который тоже его читает.

Визуально модули не связаны. Архитектурно — очень даже.

🔤 Как находить такие зависимости:

Перед регрессией стоит ответить на один вопрос:
какие сущности затронуло изменение?

Дальше — простая последовательность:

1️⃣ Определить сущность: пользователь, заказ, корзина, документ, настройки профиля и т.д.

2️⃣ Проверить, где она ещё используется:
• другие экраны, отчёты, API, фоновые задачи;

3️⃣ Понять, что может поехать рядом:
• валидации;
• статусы;
• пересчёты;
• общее состояние.

4️⃣ Прогнать тесты по этим зонам, а не только по месту правки.

Это и есть работа со скрытыми зависимостями: мы ищем не «что сломали», а что могло пострадать архитектурно.

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

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

🧹 «Фича сломала старую фичу»

Катнули новую функциональность — всё зелёное, автотесты прошли, ручные тоже. Через пару минут в чат сыплются сообщения от саппорта:

«У клиентов пропала часть данных»,
«Форма не сохраняется»,
«Импорт перестал работать».

Дев пишет: «Но мы же ничего в этом модуле не трогали…».
Да, не трогали. Просто косвенно убили зависимость, о которой никто не вспомнил.

❓ Вы как:

👍 — Идёте искать, что сломал PR: зависимости, связанные таблицы, старые флаги, побочные эффекты

❤️ — Открываете старый флов и проверяете всё по шагам, даже если кажется, что связи быть не должно

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

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

#стендап_qa

🧰 Апдейты инструментов

🈁 testRigor (no-code UI-автотесты)

Что обновили: рефакторинг шагов в переиспользуемые правила + настройка отключения email-нотификаций по умолчанию для новых suites.

🈁 Panaya (enterprise тест-менеджмент)

Что обновили: Automation Readiness Score на базе ИИ — оценивает ручные тест-кейсы и подсказывает, какие лучше всего подходят для no-code автоматизации.

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

#release_notes

🔍 Чек-лист по тестированию мобильных приложений

150+ пунктов проверки UX/UI — всё в одном файле.

Что проверяем:

✅ Визуальный дизайн и гайдлайны
✅ Типографика и локализация
✅ Информационная архитектура
✅ UX-взаимодействие
✅ Работа сервисов и ОС

Сохраняйте и используйте! ❤️

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

#артефакт