🖥 Агрегатные функции в 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

🔍 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-тексты, структура заголовков, формы и масштабирование.

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

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

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

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

#артефакт