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

Обновлённое издание — это полностью переписанный учебник, усиленный практикой и 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.

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

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

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

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

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

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

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

🔗 Источник

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

#артефакт

📎📎

<!-- PROMPT SMOKE-TEST →>
<!-- GPT-5 - с рассуждениями - little →>

<описание>

Забудь все ранее изученные документы.

Ты НЕ тестировщик программного обеспечения, НЕ используй материалы по тестированию.
Твоя задача изучить документ: [тз], провести анализ с помощью собственных знаний: [ии]; строго следуй Шагам инструкции. ЗАПРЕЩЕНО использовать [тз] в ШАГЕ2.
В ходе работы ты строишь вложенную структуру из выводов следующего вида:
[область] - 1 уровень
[функция] - 2 уровень
[стимул][явление] - 3 уровень
[действия][реакции] - 4 уровень
[роль] - 1 уровень

</описание>

<инструкция>

Шаг1:
Исключи из [тз] всё техническое описание; критерии проверки: документ соответствует типу "бизнес-требования".
- Определи к какой сфере деятельности реального мира относится программное обеспечение, опиши ее: [область]; если из документа не ясна сфера деятельности, сообщи об этом и продолжи работу.
2. Извлеки из документа список наименований всех пользователей: [роль].
3. Выбери названия функциональностей, сгруппируй их в крупноблочные по принципу существенной завершенной ценности для пользователя; в документе может быть лишь одна группа; озаглавь группы функциональностей 2 словами -> отглагольное существительное + объект действия: [функция]; критерии проверки: [функция] предельно точно отражает свое действие.
Вывод:[область][функция][роль]; выполни шаг2.
ШАГ2:
1. НЕ используй [тз]; Изучи список [функция]; объясни несколько мотивов пользователя [функция]: [стимул]; примеры стимулов для функции "детализировать звонки": "обнулился баланс" (пользователь смотрит детализацию, чтобы понять от чего конкретно списались деньги), "вышел новый тариф" (пользователь смотрит детализацию, чтобы оценить свой фактический профиль расходов относительно нового тарифа), "абоненту поступили угрозы по смс с разных номеров" (пользователь выгружает детализацию, чтобы представить ее в полицию); критерии проверки: [стимул] событийно предшествует действию [функция] и не связан с функцией напрямую, список [стимул] наиболее вероятен у наибольшего количества пользователей; опиши каждый [стимул] одной фразой.
2. НЕ используй [тз]; Представь каждый [стимул], как свершившийся факт; опиши этот факт, как реалистичную предельно яркую ситуацию пользователя из [область]: [явление] -> непосредественно перед [функция] + чтобы достигнуть [функция] + чтобы проверить успешность [функция]; опиши [явление] в несколько предложений.
3. НЕ используй [тз]; Добавь в список [роль] акторов, если их нет: "Злоумышленник".
4. НЕ используй [тз]; Представь каждое [явление], как последовательность действий пользователей из списка [роль] (ИСКЛЮЧИ СИСТЕМНЫЕ РОЛИ): [действия]; критерии проверки:
- список [действия] отражает ВСЕ события из описания [явление],
- последовательность [действия] в списке строго соответствует описанию [явление],
- каждое [действия] выполнено от ИНИЦИАТОРА действия в третьем лице (объект создается или изменяется субъектом),
- каждое [действия] описано в форме УСПЕШНО выполненного.
5. НЕ используй [тз]; обработай каждый список [действия]; опиши логику, как на каждое [действия] должна реагировать система, чтобы ПОЛНОСТЬЮ решить [стимул]: [реакции]; запрещено использовать технические термины; критерии проверки:
- [реакции] ПОЛНОСТЬЮ решают [стимул] пользователя, если нет добавь дополнительные реакции системы.
- каждая [реакции] описана предельно внятно, как это увидеть.
Вывод: [стимул][явление][действия][реакции]; выполни Шаг3.
Шаг3:
Изучи [тз] построчно.
1. Пометь [действия][реакции], не отраженные в [тз] меткой __НЕУЧТЕНО__; критерии проверки:
- [действия][реакции] в списках дополнены меткой, где это валидно.
2. Переформулируй все УЧТЕННЫЕ [действия] и [реакции] на языке [тз], НЕУЧТЕННЫЕ оставь в том же виде.

</инструкция>

<итог>

Оформи полученные результаты в заданном формате:
__Предметная область__: [область]
|№|Название|Ситуация|Действие|Результаты|
|порядковый номер|[функция].[стимул]|[явление]|[действия] маркированный список|[результаты] маркированный список|

</итог>

Ставь ❤️, если было полезно

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

#артефакт

📎 jq — 10 команд, которые экономят часы тестировщика

🔜 Форматировать JSON:

jq .

🔜 Вытянуть поле:

jq '.id'
jq '.user.email’

🔜 Элементы массива:

jq '.items[]'
jq '.items[].id’

🔜 Фильтрация:

jq '.items[] | select(.status=="active»)'

🔜 Проверка, что поле есть:

jq 'has("token»)’

🔜 Найти все error-поля:

jq '.. | .error? // empty’

🔜 Количество элементов:

jq '.items | length’

🔜 Сравнение двух JSON:

diff <(jq -S . a.json) <(jq -S . b.json)

🔜 Уникальные значения:

jq '.items[].type' | sort -u

🔜 Вывести несколько полей:

jq -r '.users[] | "\(.id) \(.email)"'

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

#тест_драйв

👨‍🦳 Профессиональная деформация тестировщика

Хотите просто проверить баланс — а через минуту уже проверяете валидации, ловите визуальные артефакты и в голове составляете баг-репорт.

➡️ Почему так:

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

➡️ Последствия, о которых обычно не говорят

1. Постоянная усталость

Фоновая проверка всего вокруг незаметно забирает энергию. К вечеру усталость выше, чем должна быть.

2. Конфликты с окружением

Человек показывает новое приложение, а вы первым замечаете съехавшую кнопку или кривую валидацию. Не специально — мозг просто делает свою работу.

3. Потеря удовольствия

Любая игра или сервис автоматически проходят проверку на дефекты. Использовать продукт «как пользователь», без анализа, становится сложно.

➡️ Как переключаться:

Перед использованием личных сервисов проговаривайте:

«Сейчас я не тестирую. Я обычный пользователь».

Это простой способ дать мозгу сигнал «тут работа не нужна».

❓ А у вас получается отключать QA-режим? Или радар работает всегда?

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

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

🔥 Выучи математику за 60 дней!

Чем важна математика расскажет Мария Тихонова - кандидат компьютерных наук, руководитель исследовательского направления SberAI, доцент факультета компьютерных наук и преподаватель НИУ ВШЭ на курсе «Математика для Data Science» от Proglib Academy.

👀 Мария - человек, который реально работает с LLM и делает так, чтобы модели понимали человеческую речь, а не делали вид.

Что еще внутри курса:

- живые вебинары, на которых можно задать вопросы спикерам
- доступ к материалам в записи, если не успели на лекцию и чат
- 3 задания с практикой на Python и финальный проект с подробной обратной связью от экспертов курса
- актуальные знания: программа разработана в ноябре 2025г.
- программа без воды - 2 месяца только самого нужного для старта
- для старта нужны всего лишь знания школьной математики и основы Python
- скидка 40% до 30 ноября
- если оплатить до конца ноября, получите курс «Базовая математика» в подарок

👇👇👇
Записаться на курс