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

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

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

Пользователь обновил страницу во время отправки формы. Что может пойти не так?

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

— Повторная отправка запроса
— Дублирование записи
— Нарушение целостности данных
— Потеря состояния

Junior должен понимать, что HTTP — stateless, а кнопка «обновить» ломает логику, если нет защиты (idempotency, токены, блокировка кнопки).

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

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

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

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

И длился этот созвон 3 часа 😓

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

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

🔥 Параллельное тестирование: как ускорить релизы без потери качества

Последовательный прогон — надёжен, но медленный. Когда нужно проверять продукт на десятках браузеров и конфигураций, он становится узким горлышком.

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

🔵 В материале разбираем:

— Что такое параллельный запуск и когда он оправдан
— Как реализовать его через Selenium и Selenium Grid
— Как настраивается parallel и thread-count в TestNG
— Лучшие практики: атомарные тесты, независимость, управление данными
— Типовые риски: ресурсы, флейки, зависимости

Подойдёт тем, кто уже автоматизирует тестирование и хочет масштабировать его под CI/CD, кроссбраузерность и частые релизы.

🔗 Читать по ссылке

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

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

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

🎓 Большой бесплатный курс по QA

Если вы уже в тестировании, но чувствуете, что знания разрозненные — этот курс может быть хорошим способом собрать всё в единую картину.

4 часа плотного контента: от основ до тем, которые ждут от уверенного middle.

Что особенно полезно для действующих QA:

— Освежить базу: жизненный цикл тестирования, типы тестирования, методологии
— Прокачать теорию под собеседования: HTTP, REST, статус-коды, идемпотентность
— Повторить SQL с практическими примерами
— Разобрать DevTools, Postman, Swagger
— Осмыслить архитектуру: монолит, микросервисы, API
— Понять роль QA в CI/CD
— Kafka, логи, анализ багов на системном уровне
— Разбор реальных кейсов и типовых тестовых заданий

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

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

#release_notes

🖥 Агрегатные функции в SQL

Если вы тестируете бэкенд, отчёты или работаете с БД — без агрегатных функций никуда. Это база, которая постоянно всплывает на собеседованиях и в реальных задачах.

Разберём 4 ключевые функции:

🔢 COUNT — посчитать количество

Сколько пользователей зарегистрировано? Сколько заказов за сутки?

SELECT COUNT(*) 
FROM users;

COUNT(*) — считает все строки
COUNT(column) — не считает NULL

🔢 MAX — найти максимум

Самый дорогой заказ? Последняя дата входа?

SELECT MAX(price) 
FROM orders;

Полезно при проверке сортировок, лимитов, бизнес-правил.

🔢 MIN — найти минимум

Минимальный возраст пользователя? Самая ранняя дата регистрации?

SELECT MIN(created_at) 
FROM users;

Часто помогает выявить некорректные данные (например, дата 1970-01-01).

🔢 AVG — среднее значение

Средний чек? Средний рейтинг?

SELECT AVG(amount) 
FROM payments;

AVG игнорирует NULL.

💡 Где это применяется:

— Проверка отчётов в админке
— Сверка данных между UI и БД
— Анализ тестовых данных
— Проверка бизнес-логики (лимиты, квоты, фильтры)
— Написание автотестов с SQL-проверками

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

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

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

🐞 Шпаргалка по жизненному циклу дефекта

Чтобы говорить с командой на одном языке, важно понимать, что стоит за каждым статусом бага.

🔢 New

Дефект только что создан. Его ещё никто не анализировал.

Ответственный: QA

🔢 Open

Баг подтверждён и принят в работу. Приоритизирован, назначен разработчик.

Ответственный: Team Lead / Dev

🔢 In Progress

Разработчик работает над исправлением. Идёт анализ причины и реализация фикса.

Ответственный: Dev

🔢 Rejected (Отклонён)

Не дефект. Задумано по ТЗ / дубликат / не воспроизведён / ошибка в окружении.

Ответственный: Dev / PO

🔢 Reopened

Баг снова открыт после проверки. Фикс не сработал или проблема проявилась повторно.

Ответственный: Dev

🔢 Fixed

Исправление реализовано. Код изменён, но ещё не подтверждён тестированием.

Ответственный: Dev

🔢 Verified

QA подтвердил, что дефект устранён. Регрессия пройдена, проблема не воспроизводится.

Ответственный: QA

🔢 Closed

Дефект полностью закрыт. Все проверки завершены, возврата к багу не планируется.

Ответственный: QA / Team

Статусы могут отличаться в Jira, YouTrack, Azure DevOps — но логика жизненного цикла остаётся одинаковой.

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

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

#артефакт

❤️, если было

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

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

🔥 Вопрос с собеседования на 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