👍 REST-вопрос, на котором ошибаются

В REST используются два направления передачи данных:

1️⃣ Клиент → сервер (Request)

Клиент отправляет данные в HTTP-запросе:

• URL (path parameters, query parameters)
• заголовки запроса
• тело запроса (POST / PUT / PATCH)

2️⃣ Сервер → клиент (Response)

Сервер возвращает результат обработки запроса:

• HTTP-статус
• заголовки ответа
• тело ответа (обычно JSON)

REST основан на модели request–response и не предполагает постоянной двусторонней связи.

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

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

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

🐳 Docker для тестировщика

Docker считают инструментом «для DevOps». А это просто способ не возиться с настройкой окружений и забыть про споры

«у меня работает».

🔢 С ним поднимаете стенд за пару минут, воспроизводите баги в том же окружении, что у разраба, сразу видите, где косяк — в коде или конфиге. Плюс уверенно чувствуете себя с CI и релизами.

🔗 Шпаргалка по ссылке

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

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

#артефакт

🎲 Задача дня: регистрация без дублей

Регистрация нового пользователя:

POST /api/register

Отправьте одинаковый запрос 5 раз одновременно (интервал 0 мс, один email).

{
  "email": "test123@example.com",
  "password": "Pass123!"
}

❓ Что должно произойти:

👍 — создан ровно 1 пользователь
🥰 — первый запрос: 201, остальные: 409
❤️ — допустимо: все ответы 200/201, но с одним и тем же userId
🔥 — в БД одна запись с этим email

Это баг, если:

💀 — создано 2+ аккаунтов
💀 — все 5 запросов вернули 201 с разными userId
💀 — ошибка 500 или зависание

Проверка в бд:

SELECT COUNT(*) FROM users WHERE email = 'test123@example.com'

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

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

#стендап_qa

❓ Что такое KISS

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

KISS (Keep It Simple, Stupid) — принцип, согласно которому решения, код и тесты должны быть максимально простыми и понятными.

➰ В QA это означает: писать тест-кейсы без лишних шагов, избегать сложных проверок там, где достаточно базовой, и не усложнять автотесты, если это не даёт дополнительной ценности.

Простые тесты легче поддерживать, они стабильнее и быстрее выявляют дефекты.

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

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

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

🌐 Что происходит, когда вы вводите адрес сайта и жмёте Enter

1️⃣ Кэш

Браузер сначала проверяет:

— DNS в кэше браузера и ОС
— сохранённые HTML/CSS/JS/картинки

Если всё есть — сайт открывается почти мгновенно.

2️⃣ DNS (если в кэше пусто)

Домен → IP-адрес

Через цепочку: локальный DNS → корневые → TLD → авторитетные.

Результат кешируется по TTL.

3️⃣ Соединение

— TCP (или QUIC)
— Для HTTPS: TLS и проверка сертификата

4️⃣ HTTP-запрос

Браузер отправляет GET / + заголовки (cookies, user-agent и т.д.).

5️⃣ Ответ сервера

— статус (200, 301, 404…)
— HTML и метаданные

6️⃣ Рендеринг

HTML → CSS → JS → подгрузка ресурсов и API-запросов.

📌 Итог:

Кэш → DNS → соединение → запрос → ответ → рендеринг

🔗 Источник

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

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

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

📂 Кейс: «Файл загружен», но его нигде нет

Прогресс-бар дошёл до 100%. Пользователь видит галочку. Переходит в список файлов — пусто.

Что происходит на самом деле ❓

🟡 Фронт показал 100% по завершению отправки
🟡 Сервер ещё обрабатывает файл (вирусы, конвертация, thumbnails)
🟡 База обновится через 5–30 секунд
🟡 Пользователь не ждёт и сразу проверяет список

Happy-path:

— пользователь ждёт несколько секунд
— файл маленький
— обработка моментальная

Реальность:

— большие файлы
— медленный процессинг
— немедленная проверка

Чеклист для тестирования прикрепили к посту 📎

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

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

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

📌 k6 — нагрузочное тестирование

k6 — современный инструмент для performance-проверок, ориентированный на автоматизацию и CI/CD, а не на ручное «кликание графиков».

🟢 Чем полезен:

— сценарии читаются как код, а не как XML-лабиринт
— легко встраивается в CI/CD (GitLab CI, GitHub Actions и т.д.)
— понятные метрики: latency, RPS, error rate
— удобно версионировать сценарии вместе с кодом

🟢 Когда брать:

— для базовой и средней нагрузки
— для регресса по производительности
— для автопроверок в CI перед релизом

✖️ Честно о минусах:

— не про сложные enterprise-сценарии на тысячи параметров
— визуализация — через внешние системы (Grafana, Cloud), а не «из коробки»

🔗 Ссылка на GitHub | Ссылка на Desktop версию

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

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

#тест_драйв

🙂 Почему автотесты не спасают плохую архитектуру

Автотесты — не магия. Если система хрупкая, они просто ломаются вместе с ней.

Узнаёте ситуацию?

→ Поправили тест на логин — упали корзина и оформление заказа

→ Разработчик сменил формат API — минус 30 тестов разом

→ Локально всё зелёное, в CI — падения без объяснений

→ Чтобы запустить один тест, нужно поднять БД, очередь, пару микросервисов и S3

❓ Почему так происходит:

— всё связано со всем, нет чётких границ
— один shared-компонент используется везде
— тестовые данные живут отдельно от реальности

Что с этим делать:

✅ Изоляция — тест логина не должен знать о корзине
✅ Контракты — изменился API → падает контракт, а не весь набор
✅ Фикстуры — данные создаются скриптами и одинаковы везде

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

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

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

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

Старший инженер по автоматизации тестирования (WMS) (от 355 000 ₽, удаленно, Беларусь)

QA Engineer (Middle) — (от 200 000 до 240 000 ₽, удаленно)

Senior QA (Load Testing) (от 250 000 до 290 000 ₽, удаленно)

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

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

🦾 Инструменты для составления чек-листов

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

⏺ TestRail / TestLink

Классические системы тест-менеджмента.

Подходит для:

— формализованных чек-листов
— связки с тест-кейсами и прогоном
— командной работы

⏺ Trello

Не QA-инструмент, но чек-листы в задачах — удобные и наглядные.

Подходит для:

— простых проверок
— регресса в рамках таски
— небольших команд

⏺ Google Sheets / Excel

Старый добрый табличный формат.

Подходит для:

— быстрых чек-листов
— совместной работы
— ситуаций «надо прямо сейчас»

⏺ Microsoft To Do

Перерождение Wunderlist. Отлично для личных чек-листов.

Подходит для:

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

⏺ Miro

Чек-листы через Mind Map и схемы.

Подходит для:

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

⏺ Jira

Чек-листы внутри задач + плагины.

Подходит для:

— команд с Jira-центричным процессом
— привязки проверок к тикетам
— кастомных сценариев

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

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

#артефакт

📋 Мини-шаблон: Тест-кейс

Назначение: обеспечить воспроизводимость проверки и контроль результата.

Структура:

 • ID
 • Название
 • Предусловия
 • Шаги
 • Ожидаемый результат
 • Тестовые данные
 • Постусловия
 • Приоритет / тип теста

Когда уместен: регрессия, критичный функционал, автоматизация, аудит.

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

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

#артефакт