Библиотека тестировщика | QA, тестирование, quality assurance, manual testing, autotesting, ручное тестирование, автотесты

💡 Тестирование не начинается с запуска тестов

Большая часть проблем появляется раньше — на уровне требований и логики.

Если подключаться поздно:

— дефекты находят уже в готовом коде
— сложнее понять причину
— фиксы ломают другие части системы

🔜 В карточках разобрали: статика vs динамика, уровни тестирования и что реально влияет на качество.

🔗 Ссылка на статью

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

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

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

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

Что произойдёт, если приложение в Docker пишет данные в файловую систему контейнера без использования volume?

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

Данные не гарантированы — они исчезнут при пересоздании контейнера.

🔴 Почему это критично:

— контейнеры эфемерны → удаление/пересоздание = потеря данных
— данные живут внутри слоя контейнера, а не отдельно
— при деплое (redeploy) состояние обнуляется
— масштабирование (несколько контейнеров) ломает консистентность

🔴 Где чаще всего стреляют:

— базы данных внутри контейнера
— загруженные файлы пользователей
— кэш/временные файлы, которые внезапно нужны

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

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

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

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

💡 Chrome DevTools умеет точечно тормозить сеть

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

Что это дает на практике:

— проверка поведения при медленных API
— тест загрузки тяжёлых ресурсов (картинки, скрипты)
— анализ edge-кейсов без влияния на всю страницу

🔜 Удобно ловить ситуации, где ломается не всё приложение, а отдельные части.

Например: медленный API → UI зависает или показывает некорректные данные

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

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

#тест_драйв

🤔 Что такое матрица трассируемости

Вы протестировали фичу, тесты есть, но вопрос остаётся: всё ли покрыто? RTM (Requirements Traceability Matrix) связывает: требование, тест, баг и даёт полную картину покрытия.

📌 Пример:

Есть требование: пользователь может войти по email и паролю ✅

RTM показывает:

— какие тесты это проверяют
— есть ли пробелы
— какие баги уже найдены

❗️ Если тестов нет — требование не покрыто.

🔴 Почему это важно:

— сразу видно, что пропустили
— проще понять, зачем нужен каждый тест
— при изменениях понятно, что проверять

⚡️ Если коротко:

RTM = ответ на 3 вопроса:

— что проверили
— что забыли
— почему это тестируем

🔗 Читать подробнее

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

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

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

📎 Vitest: как правильно мокать в тестах

В шпаргалке:

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

Сохраняйте — база для любых автотестов ⚡️

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

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

#артефакт

🚨 Когда один чат превращается в десятки

Разобрали баг в Le Chat by Mistral AI — и он бьёт в самую основу продукта:

Пишешь сообщение → отвечаешь → продолжаешь диалог

➡️ и каждое сообщение сохраняется как отдельный чат

Что происходит:

🔵 Cистема не сохраняет контекст диалога. Вместо одной сессии создаётся новая на каждый запрос.

Почему это критично:

— ломается логика чата (нет связности)
— история становится бесполезной
— пользователь теряет контекст
— AI не может нормально продолжать диалог

⚠️ Ошибка в управлении состоянием (chat/session), нет проверки, что сообщение относится к текущему диалогу.

👍 — заметили бы
🔥 — полезный кейс

🔗 Источник

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

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

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

❓ Spiral — почему сначала думают о рисках

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

В чём суть:

🔜 Разработка идет циклами, но каждый цикл начинается с анализа рисков. Не просто «сделать фичу», а сначала понять, где она сломается.

📌 Пример:

делают оплату

сразу разбирают риски:
— что если платёж прервётся
— что если запрос повторится
— что если внешний сервис не ответит

дальше:
— делают прототип
— проверяют критичные сценарии
— добавляют защиту (идемпотентность, ретраи, ошибки)

Только после этого идут в полноценную разработку ❗️

🔴 Если так не делать:

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

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

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

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

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

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

Senior AQA Engineer (AI-агенты, Python) — от 250 000 ₽, удаленно

QA Engineer (Manual) — 80 000 - 100 000 ₽, офис (Краснодар)

Fullstack QA Engineer (TypeScript) — от 230 000 ₽, гибрид (Санкт-Петербург)

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

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

🔍 E2E-тесты, которым можно доверять

В статье разбирают Playwright — фреймворк, который решает главную проблему E2E: нестабильность тестов из-за таймингов и состояния.

➡️ Что внутри:

— автоматические ожидания вместо ручных wait
— изоляция тестов
— локаторы, устойчивые к изменениям UI
— параллельный запуск без боли
— удобный дебаг (trace, скриншоты, видео)

🔗 Читать подробнее

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

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

#тест_драйв

💳 Процесс тестирования — шпаргалка QA

Тестирование — это система действий, которая идёт вместе с разработкой.

Сохраняйте, чтобы не путаться ✔️

1️⃣ Планирование

что тестируем и зачем

🔜 определяются:
— стратегия
— риски
— приоритеты
— критерии входа/выхода

2️⃣ Мониторинг и контроль

что происходит прямо сейчас

🔜 отслеживаем:
— прогресс
— покрытие критичных сценариев
— отклонения от плана

3️⃣ Анализ

что вообще нужно проверять

🔜 разбираем требования и задаём вопросы:
— а если ошибка?
— а если сервис недоступен?
— а если пользователь делает не так?

4️⃣ Тест-дизайн

как именно будем проверять

🔜 превращаем идеи в сценарии:
— граничные значения
— классы эквивалентности
— комбинации условий

5️⃣ Реализация тестов

чем будем проверять

🔜 готовим:
— тест-кейсы
— тестовые данные
— автотесты

6️⃣ Выполнение

что реально происходит при проверке

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

7️⃣ Завершение

что мы поняли

🔜 анализируем:
— что нашли
— что пропустили
— где были узкие места

👍 — сохранил/а

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

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

#артефакт

❓ Iterative — почему баги не копятся месяцами

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

📌 Пример:

делают интернет-магазин

6️⃣ итерация — каталог товаров

QA замечает:
фильтр по цене выдаёт неверные значения

🔜 исправляют до перехода дальше

2️⃣ итерация — корзина

QA находит:
товар можно добавить с отрицательным количеством

🔜 фикс до следующего шага

3️⃣ итерация — оплата

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

🔜 старые баги не тянут за собой новые

❗️ Если так не делать:

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

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

— исправления затрагивают уже готовые части системы

— время на стабилизацию перед релизом существенно увеличивается

🔗 в итоге команда тратит больше времени на разбор последствий, чем на развитие продукта 🔗

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

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

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

💡 Совет по Chrome DevTools

Мало кто использует DevTools на максимум а там есть очень удобная штука: можно быстро посмотреть, какие события навешаны на элемент
и какие данные они передают 🔜 клики, input, hover — всё видно прямо в браузере

🈂️ Это помогает:

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

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

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

#тест_драйв

💡 С какими стрессами сталкивается QA

В тестировании редко бывает спокойно

релиз → баги → срочные фиксы → ещё один релиз

И так по кругу... Знакомо? 👇

🆚 Постоянное переключение контекста

Утром тестируете фичу
Днём разбираете баг из прода
Вечером проверяете срочный фикс

🔜 Мозг не успевает переключаться → быстрое выгорание.

🆚 Размытая роль

В реальности QA часто делают всё подряд: тестирование, немного аналитики, немного саппорта

🔜 Нет фокуса → сложно расти и легко перегореть.

🆚 Давление дедлайнами

Надо катить сегодня, проверим потом

🔜 Высокая ответственность + мало времени.

🆚 Вклад не всегда виден

Если всё работает — это нормально, если баг в проде — сразу вопросы к QA

🔜 Постоянное ощущение давления.

🔥 Что помогает не сломаться

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

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

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

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

📎 База QA в одной картинке

— виды тестирования
— уровни и жизненный цикл бага
— STLC
— разница QA vs QC
— техники тест-дизайна

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

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

#артефакт