🌸 Severity vs Priority

Ты нашел баг. Упал критичный функционал при смене языка. Иставишь Severity: High — ведь баг ломает фичу.

PM говорит:

«Ну никто туда не заходит, давайте потом».

Ты думаешь:

«А баг с иконкой у CEO чинили сразу…»

И тут начинается вечная война тегов.

Кто что определяет:

➡️ Severity — обязанность QA. Основана на техническом анализе: что сломалось, как часто, насколько критично

➡️ Priority — зона ответственности бизнеса/менеджмента. Определяет, когда чинить и сколько людей на это бросать

⚔️ Холивар внутри QA:

1. QA должен настаивать на фиксе по Severity → «Если баг реально критичен — мы обязаны его пушить, даже если PM молчит»

2. QA фиксирует, но не продвигает → «Мы не продуктологи. Мы указываем риски — бизнес решает, что с ними делать»

В чем мораль:

➡️ Хороший QA — не просто находит баги. Он умеет аргументировать, почему баг надо чинить сейчас, даже если его не видно на первом экране.

А ты как действуешь? Поделись в комментах — давай устроим баг-дискуссию! ✏️

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

#междусобойчик

🤘 Быстрый запуск запроса без мыши

Ctrl + Enter — моментальный запуск HTTP-запроса в Postman.

Зачем это нужно:

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

• Работает даже при активном фокусе в теле запроса — мышку трогать не надо.

• Идеально при ручном тестировании API или во время регресса.

Пример сценария:

1. Вводишь данные в JSON-теле POST-запроса.

2. Не отходя от клавиатуры — Ctrl + Enter.

3. Смотришь ответ, меняешь данные — снова Ctrl + Enter.

💡 Используй в паре с хоткеем Ctrl + Alt + C для быстрого копирования curl-эквивалента — полезно при передаче запроса разработчику или для консольного теста.

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

#буст

☁️ QA в облаке: вызовы гибридных сред

Теперь тестировать приходится не только код, но и целые динамические среды: микросервисы, контейнеры, API, распределённые базы.

Какие вызовы стоят перед QA:

1️⃣ Как обеспечить стабильность, если окружения нестабильны

Тестовые среды в облаке живут минутами: они динамически создаются и уничтожаются. Это требует автоматизированной и быстрой настройки окружений «на лету».

2️⃣ Как безопасно тестировать с реальными данными

Использовать PROD-данные рискованно, но без них теряется реализм. Нужно анонимизировать и маскировать данные, чтобы сохранить поведение и не нарушить безопасность.

3️⃣ Как охватить сразу несколько платформ

Тесты должны учитывать различия между AWS, GCP, Azure и on-premises — это требует абстракции инфраструктуры и расширяемых CI/CD пайплайнов.

4️⃣ Как уложиться в сжатые сроки

На проверку фичи остаются часы. Значит, приоритет — на автоматизацию, параллелизацию тестов и прицельную проверку критичных зон, а не «проверить всё».

Что помогает:

➖ SAP Cloud ALM и подобные инструменты: автоматизированный контроль стабильности в облаках.

➖ Контейнеризация тестов: запуск изолированных тест-контейнеров под каждую фичу.

➖ TaaS-платформы: Testing-as-a-Service даёт масштабируемые окружения “по запросу”.

QA больше не просто проверяет «работает ли кнопка», а следит за целостностью сложных облачных процессов.

🔗 Источник

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

#свежак

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

#развлекалово

🌍 CDN: что это и как тестировать

CDN (Content Delivery Network) — это сеть серверов, которые хранят копии контента (изображения, скрипты, стили) и раздают их пользователям с ближайшего к ним узла. Это ускоряет загрузку страниц и снижает нагрузку на основной сервер.

➡️ CDN влияет на производительность, доступность и поведение сайта. А значит — тестировать нужно с умом.

Что проверять:

• Загружается ли контент с нужных CDN-узлов (через DevTools или cURL)

• Актуальность кэша (очистка, TTL, обновление контента)

• Поведение при недоступности CDN

• HTTPS-сертификаты и CORS-заголовки

• Влияние CDN на загрузку страницы (LCP, TTFB и др.)

💡 Лайфхаки:

• Тестируй с разных регионов (VPN, прокси)

• Используй Chrome Lighthouse, WebPageTest, curl, dig

• Проверяй 304/200 коды ответа и правильную работу кэширования

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

#междусобойчик

📘 Подборка статей по юнит-тестированию

🔘 Искусство Unit-тестирования: сокращаем Arrange до нуля — статья предлагает подходы к оптимизации структуры юнит-тестов, акцентируя внимание на сокращении этапа подготовки данных (Arrange), что позволяет повысить читаемость и поддержку тестов.

🔘 Лучшие практики модульного тестирования

🔘 Юнит-тестирование: полное руководство

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

#свежак

🧠 Задача на алгоритмическое мышление: 12 монет

Представьте: у вас есть 12 одинаковых на вид монет. Одна из них — фальшивая.

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

Вопрос: как определить, какая монета фальшивая, и понять, она легче или тяжелее — всего за 3 взвешивания?

💡 Подумайте:

• Сколько групп нужно создать?

• Что делать, если весы в равновесии?

• Как сузить круг до одной монеты за 3 шага?

Правильный ответ с решением:

1️⃣ Разделим монеты на 3 группы по 4. Сравним 4 vs 4:

• Если весы равны → фальшивка в оставшихся 4.
• Если нет → фальшивка среди этих 8, и ты знаешь, тяжелее она или легче.

2️⃣ Из подозрительных 4-х выберем 3. Сравним 2 из них:

• Весы равны → фальшивка — третья.
• Не равны → по направлению понятно, кто фальшивка.

3️⃣ Подтверждаем монету, сравнив с обычной.

Итог: за 3 взвешивания — вычислена монета и известно, легче она или тяжелее.

👍 — если решил/а задачу правильно
🌚 — узнал/а новое

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

#междусобойчик

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

QA Engineer/Ведущий тестировщик — от 150 000 ₽, удаленно (Москва/Томск/Новосибирск)

QA engineer — гибрид (Санкт-Петербург/Пермь/Белград)

AQA Engineer (C#) — 275 000 —‍ 295 000 ₽, удаленно/офис/гибрид (Москва)

QA engineer — от 150 000 до 230 000 ₽, офис (Москва)

QA engineer (Middle) — до 2000 $, удаленно (ОАЭ)

➡️ Еще больше топовых вакансий — в нашем канале QA jobs

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

#свежак

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

Когда макетов нет, а тестировать всё равно нужно — практическое руководство для QA:

1️⃣ Непоследовательность

— Шрифты разных размеров/стилей на похожих кнопках или заголовках

— Разные отступы в одинаковых блоках

— Ссылки/кнопки с разным поведением (одни подчеркиваются, другие — нет)

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

2️⃣ Контраст и читаемость

— Текст сливается с фоном (особенно на фоне изображений)

— Слишком мелкий шрифт (меньше 12px на desktop и 14px на mobile)

— Нечитаемый placeholder или неочевидный label

➡️ Проверка: Ctrl+A выделить всё — иногда помогает увидеть невидимые элементы.

3️⃣ Переполнение и обрезка

— Контент вылезает за блоки или перекрывает другие элементы

— Текст уходит под кнопки/иконки

— Ошибки адаптивности: горизонтальный скролл на мобилке, обрезанные формы

➡️ Проверь в DevTools в режимах разных экранов (iPhone 12, Galaxy S20, iPad).

4️⃣ Неправильные состояния

— Hover/active/click эффектов нет или не соответствуют ожиданию

— Кнопка «Отправить» не меняется при клике (нет загрузки/disabled)

— Отсутствие сообщений об ошибках/успехе после действий

➡️ UI должен «отвечать» пользователю — нажатие, загрузка, подтверждение, ошибка.

5️⃣ Визуальный шум

— Элементы слишком близко друг к другу (нет визуального дыхания)

— Много разноцветных элементов без логики (каждый блок — свой цвет)

— Нет иерархии: заголовки выглядят как обычный текст

➡️ Если всё на экране одинаковое — значит, ничего не важно. Это UX-проблема.

💡 Как описывать визуальный баг:

На странице /profile кнопка «Сохранить» визуально отличается от аналогичных по стилю: без скругления и серого цвета, в то время как на остальных экранах она зелёная и скруглённая (пример — /settings).

📎 Приложи скрин, обведи баг, добавь сравнение с другим экраном. Даже без макета важна логика и консистентность.

Полезные инструменты:

• Contrast Checker — для проверки читаемости
• Chrome DevTools → Inspect → Computed Styles — сравни CSS
• Расширения: PerfectPixel, Page Ruler, WhatFont


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

#буст

💛 Ты не поверишь, но это работает: 6 странных лайфхаков для продуктивности

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

Что ты узнаешь из статьи:

📍 Почему стоит носить обувь дома, если хочешь «включить рабочий режим»

📍 Как продуктивно прокрастинировать и не чувствовать вину

📍 Зачем вести список дел не в приложении, а на бумаге

📍 Почему фиксация времени на мелкие задачи меняет поведение

📍 И как помогает… притворство, что ты в реалити-шоу

Глупо? Да. Работает? Абсолютно.

➡️ Читать статью

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

#свежак

📌 Команда дня для генерации автотестов из живого поведения в браузере

Запустите в терминале:

npx playwright codegen https://example.com

И Playwright откроет браузер, где вы кликаете мышью — а код теста пишется сам (в реальном времени, на языке по выбору: JS, Python, Java, C#).

Что это даёт:

➡️ Генерация реалистичных end-to-end сценариев без ручного написания.

➡️ Быстрое покрытие smoke/regression кейсов.

➡️ Ускорение перехода от ручного тестирования к автоматизации.

💡 Лайфхак:

— Добавьте параметр --target=python или --target=java для нужного языка.

— Сохраните результат с --output=login.spec.ts

Работает с любой страницей — можно генерировать тесты даже для staging-среды за VPN.

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

#буст

😬

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

#развлекалово

❓ Как тестировать продукты в финансовой компании

Тестирование в финтехе — это про данные, сложную бизнес-логику и глубокое понимание предметной области. Ниже — три опорные зоны, которые стоит прокачивать каждому QA-инженеру в этой сфере.

1️⃣ Погружаемся в предметную область:

• Изучите, как работают ключевые участники рынка: банки, брокеры, биржи, страховые

• Разберитесь с финансовыми инструментами: акции, опционы, фьючерсы, облигации

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

💡 Знание предметки = больше ответственности, шире зона тестирования, выше ценность специалиста.

2️⃣ Работаем с SQL:

• Агрегатные функции — считаем, группируем, объединяем

• Учимся джойнить результаты хранимых процедур и таблицы с id вместо текстов

• Преобразование типов данных (CAST, CONVERT) — часто спасает при объединении разных источников

💡 Сложные проверки в финтехе почти всегда связаны с БД.

3️⃣ Автоматизируем тестирование

• Автоматизируйте расчеты: отчеты, комиссии, портфели, валютные пересчёты.

• Используйте Python и pytest как удобный старт — легко работать с SQL, словарями и параметрами.

• Ставьте себе цель — минимум один рутинный сценарий автоматизировать в месяц.

💡 Рутинные регрессы — работа для кода, а не человека.

Чем лучше вы разбираетесь в бизнесе, умеете работать с SQL и автоматизировать проверки, тем увереннее чувствуете себя в этой сфере и тем больше пользы приносите команде.

🔗 Источник

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

#буст

❓ Вопросы подписчиков: как правильно сообщать разработчику о баге

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

Вот что он пишет:

«Нашёл баг, но каждый раз не знаю, как лучше донести информацию до разработчика. Хочется быть конкретным и не вызывать оборонительную реакцию. Как вы это делаете?»

Что мы советуем:

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

🔘 Подкрепляйте фактами — приложите скриншоты, логи, видео. Чем меньше догадок — тем быстрее фиксы.

🔘 Контекст — ваш союзник — если баг влияет на бизнес-логику или пользовательский опыт, укажите это. Разработчик быстрее поймёт приоритет.

🔘 Формат важен — узнайте у команды, как им удобнее получать отчёты: тикет, комментарий в MR, сообщение в Slack/Teams — подход варьируется.

Хороший баг-репорт — это не просто список шагов, это способ помочь команде сделать продукт лучше. И да, хорошие отношения с девами — не менее важно, чем тест-план.

💡 А как вы оформляете баг-репорты? Используете ли шаблоны, чек-листы или подход типа «given-when-then»?

P.S. Если хотите задать вопрос, заполните нашу гугл-форму. Это займет 5 минут.

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

#междусобойчик

😬 QA без галочек: как ИИ меняет подход к тестированию

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

➡️ Beyond Checkboxes: Rethinking Software Testing

Подкаст от DevelopSense, в котором обсуждают, почему тестирование — это не просто список галочек.

• Как построить эффективную коммуникацию между разработкой и QA

• Почему автоматизация — не панацея

• Как ИИ влияет на процессы тестирования уже сегодня

➡️ Python Test – The Role of AI in Software Testing

Подкаст о месте искусственного интеллекта в мире QA.

• Как ИИ помогает обнаруживать баги на ранних этапах

• Примеры применения ML-моделей в автоматизации тестов

• Чем должен владеть QA, чтобы не остаться за бортом в 2025

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

#буст

💼 Как управлять кросс-функциональными проектами в условиях большого продукта

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

Что в статье:

📍 Как выстроить архитектурное проектирование до старта разработки

📍 Почему важно подключать тестировщиков на раннем этапе

📍 Как избежать провалов на релизе с помощью чеклистов и синхронизаций

📍 Как планировать сопровождение ещё до запуска

Читать полностью 🔗

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

Один тестировщик на проекте — это когда сам себе начальник, сам себе контроль качества и сам себе виноват, если что-то пошло не так (а оно пойдет не так) 💻

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

#развлекалово

👊 Баг ушёл в прод: QA недосмотрел или это вообще не его проблема

«Обнаружить баг после релиза — это как увидеть таракана на ужине. Приятного аппетита уже не будет, но главное — найти, кто звал гостей.»

Почему виноват QA:

📍 Он — последний рубеж. Если вы не поймали баг, значит, пропустили врага через границу.

📍 Это ваша зона ответственности. Вы видели тикет, «одобрили».

📍 Автоматизация не оправдание. Даже если 98% тестов зелёные — оставшиеся 2% могут сжечь прод. Надо было предусмотреть.

Почему QA не виноват:

🔴 Баг был в фиче, о которой никто QA не предупредил. Ну как тут тестировать? Экстрасенсорика в список навыков не входит.

🔴 Тест-кейсы были на 3 страницы, а спринт — на 2 дня. И да, приоритет всегда был «проверить это потом».

🔴 Релиз без регрессии — это не QA, это менеджер с зажжённой спичкой в амбаре.

❓ Так кто отвечает за баги в проде: QA, Dev, PM или весь Agile вместе взятый? Можно ли считать баг «пропущенным» — если никто его не хотел замечать?

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

#междусобойчик

📌 Подборка платформ и тренажеров для прокачки практических навыков

🔘 QA PlayGround — новая русскоязычная платформа с «битым» сайтом, где надо находить дефекты и составлять баг-репорты.

🔘 Devtools-тренажер — научитесь смотреть информацию в cookies или local storage, проверять, какие запросы отправляет сайт и какие ответы присылает сервер, и многое другое.

🔘 Тренажёр от QA.GURU — реальный e-commerce сайт для практики UI/UX тестов, автоматизации.

🔘 gRPCServer — открытый учебный проект, поможет освоить взаимодействие с gRPC-методами через инструменты типа Postman.

🔘 Xpath Diner — для изучения и практики XPath-селекторов.

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

#свежак