👍 Топ-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 автоматизирует путь кода до продакшна, а тестировщик превращает его из «быстрой доставки багов» в надёжный фильтр качества.

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

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

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

💡 ТОП-6 факторов, которые реально влияют на вашу зарплату

6️⃣ Наличие автоматизации — самый сильный буст

Automation QA получает на 20–40% больше, потому что уже частично конкурирует с разработчиками.

2️⃣ Грейд (но не только он) — Junior → Middle → Senior → Lead

Рост есть, но: мидл с автоматизацией часто зарабатывает больше простого сеньора.

3️⃣ Стек и инструменты: Playwright, API, CI/CD, работа с логами и БД

Чем ближе к реальной разработке — тем выше вилка.

4️⃣ Домен проекта: финтех, e-commerce, крупные продукты

Платят заметно больше, чем аутсорс и маленькие студии.

5️⃣ Английский язык — B2+ резко расширяет рынок

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

6️⃣ Локация и формат работы: Москва платит больше

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

📌 Как проверить себя:

— смотрите вакансии @testerrjob
— сравнивайте несколько источников
— обновляйте ожидания раз в 6–12 месяцев

💬 И главный момент:

Если вы не знаете свою цену — её за вас определит работодатель.

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

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

📎 Шпаргалка по Jest

Что внутри:

— структура тестов (describe, beforeEach, afterAll)
— все основные matchers без лишней воды
— работа с моками (fn, spyOn, mockReturnValue и т.д.)
— async-тесты (promises, async/await, done)
— таймеры, snapshot’ы, data-driven тесты

🔗 Ссылка на GitHub

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

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

#артефакт

😱 Tinder для GitHub

GitHub огромный и найти в нем нужный инструмент сложно. Интузиасты придумали максимально простой формат — свайпать репозитории!

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

— находить инструменты для тестирования (Playwright, Cypress, утилиты)
— смотреть, как в реальных проектах пишут автотесты
— искать примеры для pet-проектов
— быстро находить полезные репозитории без долгого поиска

🔜 Что удобно:

— фильтры по языкам и темам
— тренды (день / неделя / месяц)
— каждый проект показывается один раз
— можно сразу открыть README и оценить проект

🔗 Забрать в App Store

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

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

#тест_драйв

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

Junior QA engineer — 80 000 ₽, гибрид (Москва)

QA Manual Specialist — ≈ 100 000 —‍ 150 000 ₽, гибрид (Москва)

QA Specialist — гибрид (Турция)

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

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

😈 Тестировщик и «вера»: баг или фича?

Мы привыкли думать, что тестирование — это про проверки и факты, но есть нюанс:

➖Тестирование не может доказать, что система работает, оно может только показать, что она ломается.

И тогда возникает вопрос:

почему мы вообще решаем «релизить»?

🔤 В статье разбирается ключевая идея:

QA каждый день опирается не только на проверки,
но и на допущения:

— что требования корректны
— что стенд похож на прод
— что тесты покрывают критичное

И часть из этого мы просто принимаем «на доверие».

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

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

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

💡 Бесплатный QA Handbook для начинающих (и не только)

Нашли подробный гайд по тестированию, который можно использовать как шпаргалку и базу знаний 👇

🔗 Доступен по ссылке

Что внутри:

— основы тестирования (SDLC, STLC, принципы)
— виды тестирования (функциональное, нефункциональное, перфоманс)
— тест-менеджмент (баг-репорты, тест-кейсы, регресс)
— база по автоматизации (Cypress)
— примеры из реальной практики

👍 — заберу себе

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

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

#артефакт

🧬 Что такое Mutation testing

Обычные метрики покрытия (coverage 90%) ничего не говорят о качестве тестов. Код можно покрыть, но не проверить. Mutation testing проверяет не код, а тесты.

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

Инструмент специально вносит мелкие изменения (мутации) в код:

🟣 > заменяет на <
🟣 == на !=
🟣 убирает строки, инвертирует условия

Если после этого тесты всё равно проходят — значит, они не ловят ошибку.

🔜 Пример:

def is_adult(age):
    return age >= 18

Тест проверяет age = 18.
Мутация меняет код на > — тест всё ещё проходит.
Вывод: тест слабый, не покрывает граничные случаи.

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

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

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

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

Как проверить, что сообщение в брокере (Kafka / RabbitMQ) не потерялось, если продюсер отправил его, а консюмер не получил?

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

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

#стендап_qa

✅ Правильный ответ: B. Проверить наличие сообщения в очереди/топике и offset/acknowledgement

HTTP 200 от продюсера не гарантирует доставку → это только факт отправки

В брокерах сообщений важны:
— факт записи в очередь/топик
— подтверждение доставки (ack в RabbitMQ / offset commit в Kafka)
— состояние консюмера

👉 Сообщение может:
— не дойти до брокера
— записаться, но не обработаться
— обработаться, но не зафиксироваться

💡 Поэтому проверка всегда на уровне брокера + консюмера, а не только API

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

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

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

#стендап_qa

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

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

🗂 Английский, который пригодится в работе

Можно знать грамматику, но теряться на простых словах вроде verify или deploy. В работе важен не уровень языка, а базовая IT-лексика, которая встречается каждый день.

— действия: deploy, debug, install, update, verify, restore
— базовые операции: copy, paste, delete, connect, reboot
— разработка: compile, implement, integrate, execute
— тестирование: regression testing, unit testing, acceptance testing
— окружение: OS, runtime, IDE, database, server software
— сеть: DNS, router, bandwidth, latency

С вас 🎀, если сохранили!

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

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

#артефакт

💡 Почему unit-тесты не ускоряют регресс

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

В статье разобран кейс, как это починили:

🔴 Юниты вывели в Allure, связали с тест-кейсами и встроили в общий прогон. После этого они перестали быть внутренней историей разработчиков и стали частью QA-процесса.

📌 Полезно, если у вас:

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

🔗 Ссылка на гайд

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

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

#тест_драйв

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

Что произойдёт, если не очищать тестовые данные между тестами?

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

Тесты начнут влиять друг на друга → результаты станут нестабильными.

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

— один тест может “сломать” другой
— появляются случайные падения (flaky tests)
— сложно понять, где реальная ошибка
— результаты в CI и локально могут отличаться

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

— базы данных (не очищаются записи)
— пользователи/сессии
— кэш и cookies
— файлы и временные данные

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

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

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

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