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

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

📌 Шпаргалка от JOIN до GROUP BY

Внутри — весь базовый цикл:

— JOIN’ы для связей между таблицами
— WHERE для фильтрации
— GROUP BY и агрегаты для анализа
— ORDER для сортировки

💡 Полезно не только для собеса, а для реальных задач: проверка БД, поиск багов, валидация данных.

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

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

#артефакт

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

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

🔥 Где начинающему QA взять реальную практику

Частая ситуация: прошли курсы, посмотрели видео, теорию понимаете, но на практике — непонятно, с чего начать. Именно из-за этого на собеседованиях возникает ступор.

📌 Ниже — бесплатные тренажёры, которые закрывают базовые навыки:

➖ Тестовый интернет-магазин

Максимально приближено к реальному проекту: заходите и просто ищете баги.

➖ DevTools — must-have для собесов

Прокачаете:

— Network (запросы)
— Elements (DOM)
— cookies / кэш

Это один из самых частых практических блоков на интервью 💡

➖ JSON тренажёр

— разбор структуры JSON
— JSONPath
— работа с API

➖ JWT тренажёр

— как работает авторизация
— access / refresh токены

➖ Упражнения по SQL

Учитесь:

— делать выборки
— проверять данные
— понимать, что происходит в БД

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

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

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

✅ Правильный ответ: запрос упадёт с ошибкой

GROUP BY группирует строки, но не определяет, какое значение брать для остальных колонок.

🈂️ Пример:

SELECT user_id, status
FROM orders
GROUP BY user_id;

если у пользователя несколько status —
СУБД не понимает, какой именно вернуть

💡 Поэтому правило:

— либо колонка в GROUP BY
— либо обёрнута в агрегат (MAX, MIN, COUNT и т.д.)

📌 Что происходит в разных СУБД:

— PostgreSQL / Oracle → сразу ошибка
— MySQL (без strict mode) → запрос выполнится

Но вернётся случайное значение из группы.

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

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

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

#cтендап_qa

🍳 Простые рецепты аутентификации в Playwright

Логин в каждом тесте → медленно
UI-авторизация → нестабильно
параллельные тесты → конфликтуют

Знакомый набор проблем для любого автотестера 😂

📌 В статье:

— как сохранить storageState и не логиниться в каждом тесте
— как запускать тесты параллельно с разными аккаунтами
— когда лучше идти через UI, а когда через API
— как тестировать роли (admin / user) без хаоса
— как использовать несколько пользователей в одном тесте

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

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

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

#тест_драйв

👍 Топ-5 расширений, которые ускоряют работу

6️⃣ ModHeader — подмена headers прямо в браузере
🔜 тест auth, гео, фичефлаги без костылей

2️⃣ JSON Viewer — превращает JSON в читаемый вид
🔜 удобно проверять ответы API

3️⃣ Cookie Editor — управление куками и сессиями
🔜 логин без UI, тест разных ролей

4️⃣ Bug Magnet — добавляет edge-case значения
🔜 ускоряет exploratory тестирование

5️⃣ Fake Filler — автозаполнение форм
🔜 экономит кучу времени на тестах

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

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

#артефакт

✅ Правильный ответ:

C. Сохранять и переиспользовать storageState

📌 Разбор:

В Playwright это базовый способ не проходить логин заново в каждом тесте.

Смысл простой:
один раз выполняете аутентификацию, сохраняете состояние браузера (cookies, localStorage, иногда sessionStorage через дополнительные приёмы), а потом используете это состояние в других тестах.

💡 Почему это считается правильным подходом:

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

2. Меньше flaky
логин через UI — одна из самых нестабильных частей E2E:
редиректы, captcha, задержки API, двухфакторка, медленная загрузка страницы

когда авторизация вынесена в отдельный setup и состояние уже готово, тест идёт сразу в нужный сценарий

3. Тесты проще поддерживать
если меняется логика входа, вы правите один setup, а не десятки тестов

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

📌 Но тут есть важный нюанс, который любят на собеседовании:

storageState — не серебряная пуля.

Если все тесты используют один и тот же аккаунт, а сценарии меняют данные пользователя, могут начаться конфликты.
Например:

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

🈶 В таком случае нужен не один общий state на всё, а либо:

— отдельные аккаунты для разных воркеров
— отдельные storage state для ролей
— изоляция данных между тестами

📌 Если ответить на собесе сильнее, можно сказать так:

Правильный подход в Playwright — вынести аутентификацию в setup, сохранить storageState и переиспользовать его в тестах. Это ускоряет прогоны, уменьшает flaky и упрощает поддержку. Но если тесты меняют пользовательский state, нужно использовать разные аккаунты или разные storage state для изоляции.

👍 — полезный разбор
🔥 — сделать ещё 5 таких вопросов по Playwright

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

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

#cтендап_qa

❓ Agile — почему требования постоянно меняются и это нормально

В классической разработке пытаются всё зафиксировать заранее: сначала требования → потом реализация → в конце тестирование. Но реальность всегда ломает этот план.

Пользователи ведут себя иначе, бизнес меняет приоритеты, появляются новые идеи и продукт начинает устаревать ещё до релиза.

💡 В чём суть Agile как модели разработки:

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

🔤 Как это выглядит на практике:

1) Делают интернет-магазин: сначала реализуют каталог, пользователи начинают им пользоваться и быстро выясняется: фильтры неудобные. Команда не откладывает это на потом, а меняет подход уже в следующем спринте.

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

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

✅ Почему это работает:

Изменения не копятся до конца проекта, ошибки не доезжают до релиза, команда постоянно сверяется с реальностью, а не с устаревшим ТЗ.

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

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

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

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

🔥 Что такое CI/CD простыми словами

Представьте конвейер на фабрике:

1. Разработчик делает коммит → сырьё попадает на линию.

2. Код собирается и проходят первые юнит-тесты → проверка деталей.

3. Интеграционные тесты → смотрим, как части работают вместе.

4. Деплой в тестовую среду → испытание прототипа.

5. Релиз в прод → запуск в массовое производство.

6. Мониторинг → отдел качества следит, чтобы всё работало.

✔️ Роль тестировщика в этом конвейере:

— добавлять smoke/регрессионные тесты прямо в pipeline;
— останавливать «линию», если баг проскочил;
— следить, чтобы сам конвейер не стал узким местом.

❗️ CI/CD автоматизирует путь кода до продакшна, а тестировщик превращает его из «быстрой доставки багов» в надёжный фильтр качества.

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

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

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