📌 Команда дня: npx playwright codegen

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

npx playwright codegen https://example.com



➡️ Откроется браузер, и всё, что ты кликаешь — превращается в готовый код автотеста.

Чем полезно:

• Быстрый старт для E2E-тестов

• Ускоряет написание скриптов

• Удобно показать джунам, как это вообще работает

➡️ Поддерживает JavaScript, TypeScript, Python и C#. Так что, хочешь — пиши на чём угодно, хоть на эльфийском, если настроишь парсер.

P.S. Да, ты потом всё равно перепишешь этот автотест руками. Но начать — станет легче. А иногда «записал и отдал в CI» — это уже победа.

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

#буст

🙂 Как бороться с «flaky tests» в автоматизации

Автотесты шалят – то проходят, то падают. Вот гайд, как их привести в порядок раз и навсегда:

1️⃣ Выявляем «прыгающие» тесты

Собирайте статистику падений каждого автотеста в CI, отслеживайте процент флейкиности и отмечайте сценарии с частыми сбоями (например, более 5% падений за неделю).

2️⃣ Изолируем внешние зависимости

Заменяйте реальный API и сторонние сервисы на моки и стабы (WireMock, MockServer или MSW), чтобы сбои в сети или внешних системах не портил прогоны.

3️⃣ Укрепляем локаторы

Добавляйте в HTML специальные атрибуты, например:

<button data-test-id="login-submit">Войти</button>


и в тестах ищите элемент по ним:

driver.find_element(By.CSS_SELECTOR, "[data-test-id='login-submit']")


4️⃣ Применяем адаптивные ожидания

Лучше отказаться от sleep(5) и пользоваться явными ожиданиями:

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

submit = WebDriverWait(driver, 10).until(
EC.element_to_be_clickable((By.ID, "submit"))
)

5️⃣ Используем ретраи осознанно

Добавляйте 1–2 повтора только к отмеченным flaky-тестам, чтобы сгладить случайные тайм-ауты, но при этом не скрывайте настоящие ошибки.

6️⃣ Мониторим и рефакторим

Настраивайте дашборд стабильности (Allure TestOps, ReportPortal), регулярно удаляйте устаревшие проверки и упрощайте сложные сценарии, чтобы со временем слово «flaky» пропало из вашего лексикона.

С вас ❤️ за полезную инфу!

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

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

После собеседования тебе кажется, что ты прошёл квест. А потом появляется секретный уровень 😬

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

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

😒 Тестировать в продакшене: гениальный ход или полный треш

Сколько раз вы слышали эту фразу:

«Да нормально, все уже проверили, давайте прямо на прод!”

А потом начинаются приключения.

➡️ Что говорят те, кто за тесты на проде:

— Тестировать на реальных данных — это честно. Никакая песочница не покажет тех фокусов, которые вытворяют живые пользователи.

— Быстрее увидеть баг — быстрее починить. А если сидеть ждать идеального теста — можно пенсию встретить.

— Всё равно сто раз всё не предусмотришь. Прод — лучший краш-тест.

➡️ Что думают те, у кого сработал инстинкт самосохранения:

— Один факап на проде — и тебе потом объясняться не только перед клиентами, но и перед начальством… и юристами.

— Пользователь не должен быть тестировщиком. Он пришёл зарабатывать/покупать/играть — а не ловить баги за тебя.

— Чистый релиз — как чистая совесть. И спится спокойнее.

❓ И вот главный вопрос: тестировать в проде — это смелость или безумие?

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

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

📣 Дайджест материалов за неделю

🔘 Как быстро заводить баг-репорты прямо в браузере

🔘 Инструмент недели: Fiddler в нагрузочном тестировании

🔘 Подборка подкастов от TestGuild: как сэкономить на автоматизации и не проиграть ИИ

🔘 Команда дня: npx playwright

🔘 Как бороться с “flaky tests” в автоматизации: гайд, как привести их в порядок

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

#свежак

🧪 Найди баг

Тебе дали тестировать простую форму. Она должна принимать только корректные email-адреса.

Пользователь вводит email → если validateEmail вернёт true, форма отправляется.
Если false — показываем ошибку.

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

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

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

QA specialist — Белгород

QAA Lead (Транспорт) — от 350 000 ₽, офис/гибрид (Москва/Новосибирск)

QA Инженер — от 114 500 ₽, офис (Санкт-Петербург)

Разработчик автотестов — 150 000 —‍ 250 000 ₽, офис/гибрид (Москва)

AQA Lead — от 350 000 ₽, удаленно (Москва)

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

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

#свежак

🌸 Ключевые направления в QA-технологиях 2025 года

➖ AI и машинное обучение в тестировании

Использование AI для предсказания проблем, автоматизации тестов и создания синтетических данных. Инструменты, такие как Tricentis Testim, помогут в этом.

➖ Shift-Left и Shift-Right тестирование

• Shift-Left: тестирование на ранних стадиях разработки.

• Shift-Right: тестирование в реальной эксплуатации после релиза.

➖ Low-Code/No-Code автоматизация

Платформы, такие как testRigor и ACCELQ, позволяют создавать тесты без программирования.

➖ QAOps

Интеграция QA в DevOps для непрерывного тестирования и автоматического выявления дефектов.


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

#свежак

✏️ Альтернатива Postman для тестирования API

Hoppscotch — это лёгкий и быстрый сервис для работы с API. Никаких установок: просто заходишь на сайт и начинаешь отправлять запросы.

Что умеет:

➖ Отправлять HTTP-запросы

➖ Работать с WebSocket, GraphQL, SSE и даже gRPC

➖ Импортировать коллекции запросов из Postman и сохранять истории запросов

➖ Работать в браузере или поставить как приложение (PWA)

➖ Настраивать токены авторизации (OAuth 2.0, API-ключи и др.)

➖ Делать запросы в оффлайне, если поставить локальную версию

Есть нюансы:

🔴 Нет встроенного автоматического тестирования, как в Postman.

🔴 При очень больших проектах может подтормаживать.

🔴 Некоторые продвинутые функции всё ещё в разработке.

Hoppscotch подходит, если тебе нужно быстро и просто тестировать API без лишней головной боли.

🔗 Источник: GitHub проекта
🔗 Скачать для локального пользования

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

#буст

🤯 Как простая задачка поставила в тупик программистов

На собеседовании задали простой вопрос:

«В мешке числа от 1 до 100. Одно пропало. Как найти его? А если пропали два числа? Три? Или вообще k чисел?»

Эта задачка превратилась в одно из самых обсуждаемых тем на Stack Overflow.

➡️ Что внутри статьи:
— Как найти 1 пропущенное число (формула + код).
— Как находить 2 и больше пропущенных чисел (оптимальные алгоритмы).
— Алгоритм Мински–Трахтенберга–Зиппеля.
— Симметрические многочлены и тождества Ньютона (и зачем они нужны).
— Примеры кода на Python для всех случаев.

Если хочешь понять, как красиво решать задачи уровня собесов — обязательно прочитай статью.

👉 Переходи к статье

🔵 Чтобы получить оффер-мечты в Data Science, забирайте наш курс → «Математика для Data Science»

Proglib Academy #буст

🧪 Как быстро сгенерировать тест-кейсы с помощью ChatGPT

В повседневной работе QA-инженера часто требуется быстро составить тест-кейсы для новых или изменённых функций. Вместо того чтобы тратить время на ручное написание, можно воспользоваться возможностями ChatGPT.

📍 PROMPT:

Generate relevant test cases for the following requirement: [добавьте описание требования]. For each test, include Name, Description, Steps, and Expected Result. Consider both typical use cases and edge cases.

Пример использования:

Допустим, у вас есть требование: «Пользователь должен иметь возможность сбросить пароль через электронную почту.»

📍 Вставив это требование в промпт, ChatGPT сгенерирует набор тест-кейсов, включая:

1️⃣ Тест на успешный сброс пароля с действительным адресом электронной почты.

2️⃣ Тест на попытку сброса пароля с недействительным адресом электронной почты.

3️⃣ Тест на попытку сброса пароля с незарегистрированным адресом электронной почты.

4️⃣ Тест на повторный запрос сброса пароля до истечения срока действия предыдущей ссылки.

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

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

#буст

Мы дружелюбные 🙂

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

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

❓ Как найти баг, если он «не воспроизводится»

Один из самых бесящих сценариев: баг есть, репорт от пользователя тоже есть, но у тебя — ничего не падает. Ни в dev, ни в staging, ни локально.

Вот как системно подойти к такой ситуации:

1️⃣ Уточни шаги воспроизведения у репортера

Часто «баг» — это неполный сценарий. Спроси: браузер, устройство, час, с чем в руках сидел, кто был рядом и как дышал.

2️⃣ Проверь, есть ли логика, завязанная на дату, гео или роль пользователя

Например: скидка работает только по пятницам или кнопка доступна только админам.

3️⃣ Загляни в логи

Пусть даже это staging. Всё, что попадает в логи рядом с подозрительным действием — важно. Особенно исключения и странные тайминги.

4️⃣ Сравни окружения (локальное vs прод)

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

5️⃣ Проверь кэш и cookies

Иногда баги связаны с устаревшими токенами, кукой логина или багнутым localStorage.

6️⃣ Попроси видео или скрин

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

7️⃣ Протестируй соседние кейсы

Если баг проявляется «иногда», проверь неочевидные связи: предыдущие шаги, параллельные вкладки, баги гонки.

Баг, который не воспроизводится — это либо плохой репорт, либо баг, завязанный на контекст. Хитрость QA — найти этот контекст и сделать баг воспроизводимым 😺

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

#буст

🌸 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 больше не просто проверяет «работает ли кнопка», а следит за целостностью сложных облачных процессов.

🔗 Источник

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

#свежак

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

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