📎 5 принципов тестирования «чёрного ящика»

🔤 Опираться на требования, а не на код

Вы проверяете только внешний результат: что обещано в спецификации — то и должно происходить. Если функция «должна» отказывать при неверном вводе — проверяете именно отказ.

🔤 Не учитывать внутреннюю реализацию

Метод намеренно отрезает доступ к архитектуре. Это помогает смотреть на продукт как реальный пользователь.


🔤 Проверять систему через входы и выходы

Черный ящик — это всегда игра «что подам → что получу». Используйте классы эквивалентности, граничные значения, позитивные/негативные сценарии.

🔤 Оценивать поведение в реальных сценариях

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

🔤 Приоритезировать по рискам

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

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

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

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

🪅 Топ-3 отечественных TMS

Где вести тесты, когда привычные инструменты больше недоступны.

🪅 Интеграция OpenSearch

На реальном примере интеграции OpenSearch в LMS iSpring Learn автор расскажет, как протестировать полнотекстовый поиск, сохранив баланс между качеством и трудозатратами.

🪅 Джун, который видит

Ошибки, которые может заметить только начинающий.

🪅 Убрать рутину из регресса или как автоматизировать, не зная кода

Какие инструменты можно использовать для «автоматизации», какие есть альтернативы данным инструментам и о том, насколько всё это влияет на качество регресса и скорость его прохождения.

🪅 k6: как мы тестируем сервисы под нагрузкой

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

#release_notes

🔖 Интерактивный учебник по тестированию

Обновлённое издание — это полностью переписанный учебник, усиленный практикой и AI-инструментами.

🟣 Что изменили:

— Полная переработка материала: яснее для новичков, глубже для продвинутых.

— Учебное приложение FTB: единая платформа для всех практических задач (UI, API, backend, DB).

— AI-симулятор собеседований: сотни практических QA-задач с гибкой проверкой.

— Шпаргалки и улучшенные иллюстрации в каждой главе.

🟣 Формат обучения:

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

📎 Первая часть учебника

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

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

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

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

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

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

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

• один и тот же объект используется в разных модулях;
• общие кэши и настройки;
• переиспользуемые 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-взаимодействие
✅ Работа сервисов и ОС

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

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

#артефакт

🎲 Баг, который исчезает при дебаге

Гейзенбаг во плоти: ловишь — он пропадает, отпускаешь — возвращается. Квантовая механика в тестировании.

Как вы с ним боретесь 😳

Отвечайте реакцией:

👍 — Записываю гифку/видео и кидаю в баг-трекер

🤩 — Танцы с бубном: меняю окружение, таймауты, фазы луны

🥰 — «Не воспроизводится стабильно» → Won't fix

❤️ — Пишу баг с описанием на 3 страницы (50 скриншотов, логи, видео с разных углов, молитва)

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

#стендап_qa

🥛 Rate Limiting — что это такое

Система ограничивает количество запросов от одного пользователя за определённое время. Это защита от перегрузки, DDoS-атак и злоупотреблений.

🔴 Пример из жизни

С Rate Limiting:

Банкомат

• 3 неправильных PIN-кода → карта заблокирована
• Защита от перебора

Без Rate Limiting:

Форма входа

• Бот перебирает пароли
• 10 000 попыток в минуту
• Рано или поздно угадает

🔴 Где проверять:

— API endpoints (есть ли лимит запросов)
— Формы входа (блокировка после N попыток)
— Отправка SMS/Email (защита от флуда)
— Кнопки создания заказов, платежей

🔤 Типичные баги

1. Ограничение только на фронте

Кнопка заблокирована в UI
Но через Postman запросы проходят

2. Блокировка всего офиса

Все за одним IP
Один превысил лимит → все заблокированы

3. Нет информации о лимитах

HTTP 429
Когда можно повторить? Неизвестно

🈁 Правильная реализация

GET /api/users
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 234
X-RateLimit-Reset: 1699999999

При превышении:
HTTP 429 Too Many Requests
Retry-After: 60

🧪 Как тестировать:

— Быстро кликать кнопку 10+ раз
— Написать скрипт на 150 запросов подряд
— Проверить HTTP 429 и заголовки ответа
— Убедиться, что счётчик сбрасывается

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

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

😁 ИИ наконец-то пишет полезные тесты: готовый промпт

Большинство моделей генерируют только базовые сценарии и пропускают критичные проверки, которые видны опытному QA.

Чтобы заставить ИИ мыслить как реальный пользователь, используется промпт, ориентированный на мотивы и риски — а не на учебники по тестированию.

🔤 Что это даёт:

— Сценарии, которые обычно появляются только после инцидентов в проде

— Полезные негативные проверки, о которых ИИ раньше «не думал»

— Видимость пробелов в ТЗ

— Повторяемый, контролируемый результат даже у джуна

Промпт оставили ниже ⬇️

🔗 Источник

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

#артефакт