💥 Полезные статьи о работе с Selenium

6️⃣ Пройди собеседование на QA: 15 популярных вопросов и ответов (Python + Selenium + API). Готовитесь к собеседованию по тестированию? В этом материале собраны основные вопросы по работе с Python, Selenium и API, которые помогут вам подготовиться к интервью и повысить шансы на успешное трудоустройство.

2️⃣ Начало работы с Selenium IDE. Из этой статьи вы узнаете, как пользоваться Selenium IDE: от установки и записи действий до настройки команд и отладки.

3️⃣Как автоматизировать вход в систему в Selenium. В статье представлены методы автоматизации входа с помощью прямых API вызовов и управления токенами через localStorage. Эти техники помогут вам оптимизировать автоматизацию и ускорить проверки.

4️⃣Автоматизация при создании профилей для антидетект браузера через API: мой практический опыт. Когда у тебя 10–15 профилей, нет смысла заморачиваться со скриптом (хотя если он уже готовый — почему бы и нет, правда?) Но когда профилей нужно кратно больше? Можно, конечно воспользоваться массовым созданием, но кому-то проще, интереснее, да в конце-концов разумнее написать скрипт, который сделает всё за вас.

❓ Что делать, если нужно пройти регресс, а времени нет?

Когда на полную регрессию не хватает времени, главная задача — минимизировать риски и защитить критически важный функционал. Вот 5 практических стратегий для такой ситуации:

1️⃣ Фокус на критическом пути (Smoke-тестирование)

Если времени катастрофически мало, проведите базовый smoke-тест. Убедитесь, что приложение запускается, основные бизнес-цели пользователя выполняются (например, товар добавляется в корзину и оплачивается), а ключевые экраны не падают.


2️⃣ Приоритетная регрессия (Risk-based testing)

Вместо полной проверки выделите две зоны:

🔴Зона изменений: участки кода, которые непосредственно правились или затрагивались.
🔴Критическая зона: самый популярный и важный функционал, отказ которого принесет наибольшие убытки.
Остальные тесты отложите.


3️⃣ Таргетированное тестирование (Impact Analysis)

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


4️⃣ Выборочная автоматизация

Если у вас есть пул автотестов, не запускайте весь регрессионный сьют — это долго. Запустите только критичный набор (критикал-пас) или тесты, покрывающие измененный компонент. Пока они крутятся в фоне, вы можете проводить ручную проверку.


5️⃣ Быстрые чек-листы вместо тест-кейсов

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

Оффер редко приходит сам. Обычно между «без работы» и «оффер получен» стоят десятки откликов, доработок резюме и часов поиска.

Talanto.work помогает пройти этот путь быстрее:
🟠 50 000+ IT-вакансий с разных сайтов

🟠 Telegram-бот с уведомлениями по вашим фильтрам

🟠 Проверка резюме и рекомендации по улучшению

🟠 Проверка соответствия резюме конкретной вакансии

🟠 Генератор персональных сопроводительных писем

Ищите работу не дольше. Ищите эффективнее.

📌 Статьи о метриках в тестировании

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

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

🎌 Меланхолия тестировщика: почему метрики врут. Мастера северного Возрождения видели божественное в деталях. Не в грандиозных замыслах, а в складках ткани, в отражении света на металле. Может, и нам стоит взглянуть не на космические дашборды с метриками, а на содержимое каждого теста?

🎌 QA-метрики: когда они могут быть полезны и как их использовать. Многие команды сталкиваются с необходимостью формализовать показатели эффективности своей работы для оценки её качества и выявления возможных проблем. Автор этой статьи рассказала о метриках, которые используются в команде тестирования Яндекс Музыки.

🎌 Кейс обучения QA-персонала: развитие навыков оценки задач и контроль качества через метрики. История лида о том, как он обучал сотрудников системному подходу к оценке задач и внедрял регулярный контроль фактического времени выполнения тестовых активностей.

❓ Что происходит с баг-репортом, если ему ставят статус «Не баг»?

Когда баг-репорт получает статус Rejected, As Designed или Not a Bug, это означает, что система работает именно так, как было задумано, либо ошибка произошла на этапе тестирования.

✅ Основные причины такого статуса:

🎌 Спецификация: поведение системы соответствует требованиям, даже если оно кажется странным или неудобным. Это «фича», а не ошибка.

🎌 Ошибка в ожиданиях: тестировщик неверно понял логику работы приложения или обратился к устаревшей документации.

🎌 Проблемы окружения: баг вызван некорректными тестовыми данными или локальными проблемами на стенде тестировщика.


✅ Что происходит с репортом дальше?

Баг-репорт закрывается. При этом автор отклонения (обычно разработчик или аналитик) обязан оставить комментарий с обоснованием: дать ссылку на пункт в требованиях или объяснить логику системы. Это нужно, чтобы при повторном тестировании вопрос не возникал снова.


✅ Что делать тестировщику в такой ситуации?

🎌 Проверить аргументы. Если аргументы логичны и подтверждены документацией — согласиться и закрыть задачу.

🎌 Защитить пользователя. Если поведение системы действительно «по проекту», но ломает пользовательский опыт (UX), баг-репорт закрывается, но вместо него создается задача на улучшение — Improvement или Feature Request.

💥 Материалы о работе с Playwright

🚩 Global Cache, или как выполнить BeforeAll в Playwright один раз для всех воркеров. BeforeAll в Playwright запускается в каждом воркере, а не один раз на все тесты — и это часто ломает ожидания тестировщиков. В статье разбирается, почему так происходит и какие есть стандартные обходные пути.

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

🚩 Тестирование API в Playwright. В статье разбирается, как использовать Playwright для тестирования GraphQL API.

🚩 Веб-скрапинг с помощью Playwright. Из этой статьи вы узнаете, как с помощью Playwright извлекать данные с сайтов и генерировать из них JSON-файл.

🚩 Как запускать тест-кейсы Playwright в CI/CD. В этой статье подробно рассказано, как настроить CI/CD-конвейер в Bitbucket Pipelines для автоматического запуска тестов Playwright.

✅ SaveTest — новая TMS для управления тест-кейсами, прогонами и отчетностью.

Современный подход: тест-кейсы можно вести как код, хранить их в YAML, python, gherkin-файлах в Git.

Сценарий простой:
1. Создаете тест-кейсы в VS Code или Cursor.
2. Загружаете их в репозиторий, например в GitHub или Gitlab.
3. SaveTest синхронизирует изменения и подтягивает их в интерфейс.
* Но можно вести и классические проекты

Переходите на SaveTest — добавим неиспользованный срок вашей текущей лицензии бесплатно при покупке нашей лицензии от 1 года.
*Предложение не является публичной офертой. Детали уточняйте в чате @savelink_official

Наш сайт: save-test.ru
Наш ТГ канал: @savelink_testing

Реклама. ООО «Сейв Линк» ИНН: 9725129745 erid: 2W5zFJfmVAh

❓ В чем особенность протокола TCP?

TCP (Transmission Control Protocol) — это протокол транспортного уровня, главная задача которого — гарантировать, что данные дойдут до получателя в полном объеме и в правильном порядке. В отличие от легковесного UDP, TCP берет на себя полный контроль над доставкой.


✅ Основные механизмы работы TCP:


1️⃣ Установление соединения (Three-Way Handshake)

Прежде чем отправить первый байт полезных данных, клиент и сервер согласуют сессию с помощью трех шагов:

🔎Клиент отправляет запрос: пакет со флагом SYN.

🔎Сервер подтверждает запрос и отправляет свой: SYN-ACK.

🔎Клиент подтверждает готовность: ACK.
Только после этого начинается обмен данными.


2️⃣ Контроль ошибок (Error Checking)

Каждый пакет содержит контрольную сумму для проверки целостности. Если пакет пришел поврежденным или не пришел вовсе, получатель не отправит подтверждение (ACK), и TCP автоматически переотправит утерянные данные. Кроме того, протокол сам собирает пакеты в правильном порядке, если они дошли с задержкой.


3️⃣ Управление потоком (Flow Control)

Механизм защищает получателя от перегрузки. Используя алгоритм «скользящего окна» (Sliding Window), получатель сообщает серверу, какой объем данных он готов обработать за раз. Сервер не отправит больше, чем буфер получателя способен вместить.


4️⃣ Управление перегрузкой (Congestion Control)

Если «управление потоком» заботится о получателе, то этот механизм следит за состоянием всей сети между устройствами. Если маршрутизаторы в сети перегружены и пакеты начинают теряться, TCP автоматически снижает скорость отправки, а затем плавно увеличивает ее снова, когда ситуация стабилизируется.