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

💬 Реальное собеседование тестировщика в крупный банк

Кандидат с опытом 3+ лет отвечает на вопросы — от SQL и REST до CI/CD и тест-кейсов.

🔤 Что внутри:

— Как кандидаты рассказывают про опыт и проекты (и где чаще всего «плывут»)

— Разбор API и статусов ответов: где путаются даже мидлы

— Практические кейсы: тестирование кнопки «Сбросить», работа с базой данных, проверка запросов

🔥 Отличный способ проверить себя перед следующей встречей с HR и техэкспертом.

📎 Смотреть видео по ссылке

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

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

📸 Скриншоты в баг-репортах

Кажется, что это мелочь. А на деле — один из самых холиварных вопросов в QA-командах.

⏯ Скрин обязателен

— «Без скрина это не баг, а болтовня»

— Скрин помогает разработчику увидеть суть сразу

— «Один скрин = минус сто слов в steps to reproduce»

💹 Разрабы сами откроют

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

— Делать, обрезать, грузить — трата времени

— Разработчик всё равно смотрит код, а не картинку

❓ А как у вас в команде:

👍 — Скрин в каждом баге обязателен
❤️ — Только если это визуальный баг
🔥 — Разрабы сами разберутся

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

#стендап_qa

🙂 Чит-лист функционального тестирования

Универсальная шпаргалка для тестировщиков — коротко обо всём, что важно проверить в любой системе.

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

— проверки тестового покрытия
— вычитки ТЗ
— быстрого старта на новом проекте

📎 Полная версия с примерами и описаниями

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

#артефакт

🐳 Как ускорить автотесты в 5 раз без новых серверов

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

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

docker-compose up --scale app=5 -d

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

🔢 Пример docker-compose.yml

services:
  app:
    image: myapp:latest
    ports:
      - "8080"
    depends_on:
      - db
  db:
    image: postgres:15

🗳 Как применить в тестах:

— Поднимите несколько инстансов через --scale

— Настройте раннер (например, pytest-xdist или robot --processes 5) для распределения

— Тесты стартуют параллельно → CI проходит в разы быстрее

🔥 Совет:

Добавьте --remove-orphans при рестарте, чтобы старые контейнеры не мешали.

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

#тест_драйв

🔥 Сбой AWS, который обрушил пол-интернета

20 октября 2025 года в регионе us-east-1 у Amazon Web Services произошёл каскадный сбой. Не работали DynamoDB, Lambda, EC2, API Gateway — тысячи приложений по всему миру встали.

🅰️ Что случилось:

Баг в системе, управляющей DNS-адресами DynamoDB, нарушил резолвинг. Сервисы не могли «достучаться» до нужных эндпоинтов и начинали бесконечно повторять запросы.

Эти массовые повторы создали нагрузочную волну, которая добила инфраструктуру. Пока Amazon восстанавливал DNS и чистил кэши, бизнесы теряли доступ к API и базам.

📌 На прикрепленной картинке — разбор, как тестировать сбои подключений, повторные запросы и отказоустойчивость систем.

📎 Источник

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

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

🐞 Что такое регрессия и почему она неизбежна

Когда код меняется, ломается не то, что правили, а то, что зависело от этого куска. Поэтому задача тестировщика — не «поймать ошибку», а предсказать, что именно сдвинется после правки.

Пример: поправил авторизацию → перестала работать корзина. Связь неочевидна, но она есть.

🔤 Автотесты не спасают от регрессии — они лишь показывают, где она случилась. Предотвращает регрессию только понимание архитектуры.

📎 Видео для закрепления темы

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

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

🖍 Что отличает хорошего тест-кейса от бесполезного

Количество тестов ≠ качество покрытия. Мидлы должны уметь оптимизировать тест-кейсы и выделять сценарии с максимальным риском.

Карточки помогут:

⏺ показывать примеры избыточных кейсов;

⏺ объяснять понятие “value-based testing”;

⏺ давать мини-чеклист для ревью кейсов.

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

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

😠 Документации нет, но вы держитесь

Требований нет. API описания нет. Но тестировать нужно сегодня 😅

❓ Ваш ход:

— Интуиция и старые скрины
— Postman и метод научного тыка
— Телепатия с бэкендером (через боль и мемы)

💬 Делитесь своими историями, когда приходилось «тестировать вслепую» 🔻

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

#стендап_qa

😎 Очередная шпаргалка по SQL

Иногда чувствуешь себя не QA, а детективом, который допрашивает базу данных:

«Ну признайся уже, где этот баг?»

ℹ️ Внутри: от LIKE до JOIN, от TRIGGER до OFFSET — всё, чтобы не гуглить на проде.

На английском, но язык SQL мы ведь все понимаем одинаково 😅

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

#артефакт

🔥 Ломаем, чтобы выжить

Chaos Engineering (инжиниринг хаоса) — это когда сознательно ломаем систему, чтобы проверить её устойчивость.

Пример: отключаем один сервис в кластере и смотрим, как система справляется с нагрузкой.

⏺ Распространённый сценарий:

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

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

🌪 QA здесь проверяет не только функциональность, но и надёжность всей системы.

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

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

🤟 QA-мемы: делимся любимыми

Каждый тестировщик хоть раз узнавал себя в меме — ошибки, баги, дедлайны и легендарное «а у меня работает» 😅

Скиньте в комменты свой любимый мем — тот, что лучше всего отражает вашу боль или иронию профессии. 🔜

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

#стендап_qa

🧬 Тестовые данные: из жизни или из скрипта

QA-дилемма старше Jenkins.

➡️ Реальные:

— Отражают поведение настоящих пользователей
— Ловят неожиданные edge-кейсы
— Но несут риски приватности и утечек

➡️ Тестовые:

— Безопасны и под контролем
— Легко обновлять и масштабировать
— Но часто слишком «стерильные» для реального мира

👍 — Настоящие
❤️ — Сгенерю сам/а

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

#тест_драйв

😠 Чему тестировщики могут научить разработчиков

Тестировщики часто кажутся теми, кто «приходит после». Но на самом деле — это те, кто смотрит вперёд. Они видят не код, а последствия.

➡️ Думать в сценариях, а не в строках кода

Разработчик пишет функцию, тестировщик видит поведение. Код может быть идеален, но пользователь нажмёт не туда — и всё рухнет. QA напоминает: мир шире happy path-а.

➡️ Сомневаться в очевидном

«А если не сработает?»

Это не скепсис, а гигиена мышления. Тестировщики учат не верить первому успешному результату — и это делает систему устойчивой.

➡️ Искать закономерности, сбои

QA видит баги не поодиночке, а как паттерны. Если что-то ломалось так раньше — сломается и снова. Это и есть системное мышление.

➡️ Говорить о проблемах без обвинений

Тестировщики каждый день приносят «плохие новости». И делают это так, чтобы команда не закрылась, а пошла решать. Они учат культуре обратной связи:

«Не ты плохой — просто система не выдержала».

➡️ Видеть продукт глазами пользователя

QA — единственные, кто по-настоящему ходит по интерфейсу как человек. Они напоминают: юзер — не дебаггер, а человек.

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

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

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

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

🦉 Подборка материалов: BVA и EP

Если вы до сих пор проверяете «на глаз» или «по интуиции», пора системно подойти к тест-дизайну. BVA и EP — два базовых, но мощных метода, которые экономят время и находят баги там, где не ждёшь.

Что изучить:

➡️ Что такое Equivalence Partitioning (EP)

Разделяем входные данные на группы, где поведение системы одинаковое.

➡️ Boundary Value Analysis (BVA)

Тестируем значения на границе допустимых диапазонов — именно там чаще всего ошибки.

➡️ Практика на реальных кейсах

➡️ Обзор техник и кейсов

➡️ Автоматизация EP/BVA

➡️ Советы по pytest

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

#release_notes

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

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