❤️, если было

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

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

🔥 Вопрос с собеседования на Junior

Что такое Policy Model (PM)?

👇 Правильный ответ (нажми, чтобы прочитать):

Policy Model — это подход, при котором система принимает решение “разрешить или запретить действие” на основе правил (политик), а не жёстко прописанной логики в коде.

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

📌 Как это выглядит на практике

Политика может учитывать:
• Кто выполняет действие (роль)
• К какому ресурсу идёт доступ
• Какое действие выполняется (read / write / delete)
• Дополнительные условия (время, IP, владелец записи)

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

При тестировании нужно проверять:
• Разные роли (Admin / User / Guest)
• Доступ к “своим” и “чужим” данным
• Граничные условия (время, статус, лимиты)
• Обход логики через API

Ошибка в policy → это почти всегда IDOR, privilege escalation или логическая уязвимость.

👍 — знал/а
🔥 — не знал/а

💼 Щелкаешь такие задачи как орешки? Найди проект с достойной зарплатой тут

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

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

🔋 Как бы вы протестировали power bank

Коллеги, в #разбор_полетов мы тренируем не фантазию, а системное мышление.

Сегодня — power bank.
Устройство, которое «должно работать всегда». Особенно когда 3% и навигатор уже ругается.

➕ Как бы вы подошли к тестированию?

Подумайте в разрезе:

🟡 Условия эксплуатации
— Жара / мороз
— Использование на улице
— Зарядка в рюкзаке
— Одновременная зарядка нескольких устройств
— Использование во время собственной зарядки

🟡 Состояния
— Новый
— После 200 циклов
— Почти разряжен (1–5%)
— Повреждён кабель
— Неполный контакт в разъёме

🟡 Граничные значения
— 0% — реально ли 0?
— 100% — перезаряд возможен?
— Быстрая зарядка — перегрев?
— Нагрузка выше заявленной

🟡 Риски для пользователя
— Перегрев и возгорание
— Вздутие аккумулятора
— Поражение током
— Повреждение телефона
— Ложная индикация заряда

🟡 Нефункциональные проверки
— Насколько корректно отображается процент
— Стабильность выходного напряжения
— Время полной зарядки
— Потери энергии при хранении

❓ И главный вопрос:
в какой момент power bank перестаёт быть «резервом» и становится источником риска?

Наш вариант — в картинке под спойлером 🙂

📍 Навигация: [Вакансии]

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

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

🤨Объясняем Session как пятилетке

Session — это «карточка гостя» на стороне сервера. Браузер просто носит номерок, а вся информация хранится у сервера.

Как это работает:

🌍 Браузер → 📩 Логин
🖥 Сервер → 🗂 Создаёт сессию
🌍 Браузер → 🔢 Носит session id

Пример:

Зашли в личный кабинет → сервер создал сессию → пока она жива, вы авторизованы
Сессия истекла → нужно логиниться заново

Почему важно тестировщику:

✅ Истекает ли по таймауту
✅ Удаляется ли при logout
✅ Меняется ли session id после логина (защита от fixation)
✅ Что происходит при открытии в двух вкладках

📍 Навигация: [Вакансии]

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

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

🟥 Как тестировать авторизацию и не ограничиться «логин работает»

90% уязвимостей и прод-багов в авторизации — не в форме логина, а в управлении сессией и ролями.

Разбираем, что обязан проверить тестировщик:

1️⃣ Роли и доступы

Проверяем не только вход, а что доступно после входа:

— пользователь
— модератор
— админ
— заблокированный аккаунт

Важно:

🔜 Можно ли попасть в админку по прямой ссылке?
🔜 Меняется ли доступ при смене роли?
🔜 Есть ли IDOR (подмена ID в запросах)?

Авторизация = контроль доступа, а не просто логин.

2️⃣ Истечение сессии

Проверить:

— что происходит через 5 / 30 / 60 минут бездействия
— разлогинивает ли при истечении токена
— можно ли выполнить запрос с просроченным токеном

Опасный сценарий: UI разлогинил, а API продолжает принимать старый токен.

3️⃣ Повторный вход

Сценарии:

— логин с тем же аккаунтом в другом браузере
— логин после смены пароля
— логин после выхода

Проверить:
🔜 инвалидируется ли старая сессия
🔜 что происходит с активными вкладками

4️⃣ Параллельные сессии

Можно ли:

— быть залогиненным на 5 устройствах?
— ограничено ли количество сессий?
— что происходит при превышении лимита?

Для банковских и финтех-систем это критично.

5️⃣ Cookie и токены

Проверить:

— что будет после удаления cookie
— что будет при подмене токена
— флаги: HttpOnly, Secure, SameSite
— хранится ли JWT в localStorage (риск XSS)

Удалили cookie → система должна корректно считать вас гостем. Если нет — это уже уязвимость.

🔒 Почему это про безопасность

Ошибки в авторизации приводят к:

— захвату аккаунта
— повышению привилегий
— доступу к чужим данным
— обходу бизнес-ограничений

И именно тестировщик часто первый, кто это замечает.

📍 Навигация: [Вакансии]

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

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

❔ Где настоящая уязвимость

Пользователь вышел из аккаунта. UI показывает форму логина. Но если взять старый JWT-токен и отправить запрос напрямую в API — данные успешно возвращаются.

📍 Навигация: [Вакансии]

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

#стендап_qa

🔍 10 вопросов перед началом тестирования

Прежде чем писать тест-кейсы и открывать Postman, задайте себе эти вопросы. Они экономят часы и спасают от «почему это не проверили?».

🈂️ Что именно меняется?

Новая логика? UI? API? Без понимания масштаба оценка и тестирование будут неточными.

🈂️ Какие модули это затрагивает?

Изменения редко изолированы. Проверьте соседние функции и зависимости.

🈂️ Есть ли интеграции?

Платежи, внешние API, очереди, сторонние сервисы. Интеграции = дополнительные риски.

🈂️ Какие роли участвуют?

Admin ≠ User ≠ Guest. Проверьте права доступа и ограничения.

🈂️ Что произойдёт при некорректных данных?

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

🈂️ Нужна ли регрессия?

Если логика меняется — что ещё может сломаться? Оцените объём дополнительной проверки.

🈂️ Зависит ли задача от среды?

Стабильность билда, тестовые данные, версии API. Иногда проблема не в коде, а в окружении.

🈂️ Нужно ли обновлять автотесты или документацию?

Изменения в функционале → изменения в тестовой базе.

🈂️ Есть ли риски или неопределённость?

Нет финального дизайна? API ещё меняется? Это влияет на эстимацию.

🈂️ Что будет, если пользователь сделает «не так»?

Закроет вкладку. Обновит страницу. Нажмёт дважды. Попробует обойти логику.

📍 Навигация: [Вакансии]

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

#артефакт

⏳ Что такое эстимация в тестировании

Эстимация — это ответ на вопрос:

«Сколько времени нужно на тестирование задачи?»

Это не угадывание и не «на глаз». Это прогноз объёма работы с учётом:

— количества сценариев
— регрессии
— интеграций
— рисков и нестабильности среды

🔤 Если проще, то вы оцениваете не время, а сложность. Время — это уже следствие.

📍 Навигация: [Вакансии]

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

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

🐱 SQL на котиках

JOIN — это способ соединить данные из разных таблиц по общему полю.

В видео разбирают:
— разницу между INNER и LEFT JOIN
— почему строки могут «пропадать»
— как формируется итоговый результат
Подойдёт новичкам, тем, кто путается в JOIN, и всем, кто хочет перестать писать запросы вслепую.

📍 Навигация: [Вакансии]

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

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

🔥 Топ-вакансий недели для тестировщиков

Middle QA-engineer — ~ 100 000 ₽, удаленно

Middle QA-разработчик — 190 000 ₽, удаленно

QA инженер — 80 000 - 120 000 ₽, офис, Санкт-Петербург

➡️ Больше офферов в канале: @testerrjob

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

📌 Чек-лист доступности для QA

Краткий список проверок, которые стоит проходить перед релизом:

🔢 контраст, клавиатурная навигация, alt-тексты, структура заголовков, формы и масштабирование.

Без теории — только практические пункты для ручной проверки.

С вас ❤️, если полезно

📍 Навигация: [Вакансии]

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

#артефакт

🧩 FitNesse — когда требования становятся тестами

FitNesse — open-source инструмент для приёмочного тестирования. Позволяет описывать поведение системы в виде таблиц на Wiki-страницах и сразу исполнять их как автотесты.

Суть простая:
вы пишете таблицу → связываете её с кодом → получаете исполняемую спецификацию.

🔴 Подходит, если:

— важна прозрачность требований
— нужно приёмочное тестирование
— команда работает в enterprise (часто Java/.NET)

Интерфейс устаревший, инструмент не модный. Но в правильном контексте — может быть полезнее, чем кажется.

💬 Используете исполняемые спецификации или требования живут отдельно от тестов?

📍 Навигация: [Вакансии]

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

#тест_драйв

🔥 Вопрос с собеседования на Junior

В чём разница между RBAC и ABAC? Когда RBAC уже недостаточно?

👇 Правильный ответ (нажми, чтобы прочитать):

RBAC (Role-Based Access Control) — доступ строится на ролях.
ABAC (Attribute-Based Access Control) — доступ определяется набором атрибутов: пользователь, ресурс, действие, контекст.

RBAC ломается, когда:

— ролей становится слишком много
— появляются временные ограничения
— правила зависят от владельца ресурса или динамических условий

ABAC гибче, но сложнее в поддержке и тестировании.

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

— проверить комбинации атрибутов
— протестировать конфликтующие правила
— проверить fallback-поведение

👍 — знал/а
🔥 — стало понятнее

💼 Щелкаешь такие задачи как орешки? Найди проект с достойной зарплатой тут

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

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

🧪 Обновления Postman

На этой неделе Postman выкатил несколько изменений, которые напрямую затрагивают API-тестирование и аналитику.

❇️ Postman 11.85.0

Обновлён Reports (Enterprise):

— расширенная аналитика по командам и рабочим областям

— новые метрики по API-взаимодействиям

— добавлены API-эндпоинты для выгрузки данных отчётов

➕ Полезно для QA-лидов и команд, которые строят метрики качества и автоматизации.

❇️ Postman 11.85.1

Добавлены AI request blocks в Postman Notebooks:

— можно вставлять AI-блоки прямо в ноутбуки

— анализировать ответы API с помощью моделей

— строить логику поверх результатов

➕ Это шаг к AI-поддержке тестирования прямо внутри документации и сценариев.

📊 Интересно ли вам больше таких дайджестов обновлений QA-инструментов?

👍 — да, делайте регулярно
🔥 — давайте ещё и по Playwright / Cypress
❤️ — интереснее практические кейсы применения

📍 Навигация: [Вакансии]

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

#release_notes #postman