🧑‍💻 Уютное сообщество тестировщиков

❓ Что такое кластеризация дефектов?

Кластеризация дефектов (Defect Clustering) — это один из фундаментальных принципов тестирования, который опирается на закон Парето. В контексте QA он звучит так:

Около 80% всех обнаруженных багов сосредоточены всего в 20% модулей приложения.

Проще говоря, дефекты редко распределяются по системе равномерно: обычно они «скучиваются» в определенных местах.


✅ Почему баги собираются в кластеры?

🔎 Сложная бизнес-логика. Чем больше ветвлений, интеграций и математики в модуле (например, корзина с промокодами, налогами и системами доставки), тем легче там ошибиться.

🔎 Частые изменения. Если модуль постоянно дорабатывается и переписывается под новые требования бизнеса, в нем регулярно будут появляться регрессионные баги.

🔎 «Унаследованный» код (Legacy). Старые, запутанные участки системы с плохой архитектурой, которые разработчики боятся трогать, почти всегда становятся рассадником дефектов.

🔎Человеческий фактор. Модуль мог писать менее опытный разработчик или команда работала над ним в условиях жесткого дедлайна.


✅Пример из практики

Представьте интернет-магазин из пяти крупных блоков: Каталог, Профиль, Корзина, Поиск и Панель администратора. В ходе тестирования релиза обнаруживается 50 багов.

При анализе выясняется, что 40 из них (80%) приходятся исключительно на Корзину, так как в этом месяце ее функционал полностью обновляли 10 раз, в то время как Поиск и Профиль почти не менялись. Корзина в данном случае - классический кластер дефектов.


✅ Как использовать этот принцип в работе?


🔎 Умная приоритезация. Зная проблемные зоны системы, распределяйте тестовое покрытие так, чтобы эти 20% кода проверялись в первую очередь и максимально глубоко.

🔎 Анализ истории (Risk-based testing). Ведите статистику багов. Если в прошлых релизах определенный модуль постоянно «мигал» и ломался, начните регрессионный тест именно с него.

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

Основы юзабилити-тестирования

Автор: Кэрол М. Барум
Год издания: 2021

Скачать книгу

🔥 Техники тест-дизайна

📥 Основные техники тест-дизайна. Статья знакомит с ключевыми методами сокращения тестовых сценариев без потери качества покрытия. Автор разбирает такие подходы, как граничные значения, классы эквивалентности, таблицы решений и переходы состояний.

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

📥 Первые шаги в тест-дизайне. Разбор основных техник тест-дизайна (анализ граничных значений, попарное тестирование, таблица принятия решений) на примерах.

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

📥 Pairwise тестирование. Почему, зачем и как? Автор рассказала, на чем основана эта техника тест-дизайна, почему она так распространена, а также разобрала примеры и инструменты, которые помогают автоматизировать процесс создания тест-кейсов.

❓ В чем особенность протокола 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 автоматически снижает скорость отправки, а затем плавно увеличивает ее снова, когда ситуация стабилизируется.

Чат с вашими резюме.

Присылайте резюме, чтобы HR вас увидела и ей(ему) было удобно с вами связаться.

QA Резюме

P.S сейчас там можно бесплатно «прожарить» свое резюме на предмет ошибок и обхода ATS

Тестируем яблоко: смартфоны, планшеты и часы

Автор: М. А. Осина
Год издания: 2023

Скачать книгу

✅ 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

💥 Материалы о работе с 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.

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

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

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

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

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

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


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

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


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

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

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

Agile-тестирование

Автор: Джанет Грегори
Год издания: 2019

Скачать книгу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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


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

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


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

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

Тестирование видеоигр

Автор: Торговкин Александр
Год издания: 2024

Скачать книгу

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

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

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

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

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

@rabotadlaqa - чат для поиска работы тестировщиков. HR менеджеры - welcome

❓ Как понять, что используется VPN? (Чек-лист для тестировщика)

1️⃣ Геолокация и провайдер. Проверка через API (ip-api.com, ipinfo.io). Если провайдер помечен как «Hosting/Data Center» вместо «ISP» — это почти всегда VPN/Proxy.

2️⃣ Утечка WebRTC. Проверка, не светит ли браузер реальный внутренний IP за пределами туннеля.

3️⃣ DNS Leak. Анализ соответствия локации IP-адреса и DNS-серверов.

4️⃣ Timezone Mismatch. Проверка разницы между временем по IP и системным временем устройства.

5️⃣ Сетевые параметры (MTU/MSS). Нетипично низкие значения MTU (меньше 1500 байт) из-за инкапсуляции пакетов.

6️⃣ Трассировка (Traceroute). Обнаружение узлов, принадлежащих крупным VPN-провайдерам или хостинг-площадкам.

✈️ Агрегатор вакансий в IT: talanto.work

🟢50.000+ вакансий с разных сайтов

🟢Бот с уведомлениями о ваших вакансиях

🟢Написание сопровода

🟢Разбор"прожарка" вашего резюме

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

А если вам интересно все держать в телеграме то наш канал с последними свежими вакансиями: @talantojob

⭐️ Полезные статьи о тестировании API

📥 Руководство по написанию тест-кейсов для тестирования API. Эта статья познакомит вас с процессом написания эффективных тест-кейсов. Также в ней рассмотрены десять примеров тест-кейсов, которые помогут вам начать.

📥 Автоматизация тестирования API посредством Python. Рассказ о тестировании API с помощью Python, фреймворка Pytest и библиотеки Requests.

📥 Тестирование API в Cypress. Cypress – это легкий и простой в использовании инструмент автоматизации тестирования. Он позволяет тестировать веб-приложения в режиме реального времени и узнавать результаты тестирования напрямую. Кроме того, Cypress можно использовать для тестирования API.

📥 Тестируем API с помощью Keploy. Множество современных приложений используют для взаимодействия вызов функций с помощью API. Для автоматизации таких тестов существуют различные инструменты, и Keploy - один из них.

📥 Скрипты для тестирования API в Postman. В этой статье: добавление скриптов, валидация ответов, формарование сообщений о результатах тестов, тестирование коллекций и папок, добавление документации к скриптам.

ТОП-10 Telegram-каналов с вакансиями по конкретным IT- направлениям — выбирай то, что подходит именно тебе 👇

🐞 Если ты в тестировании / QA
Вакансии для ручных и авто-тестировщиков, стажировки:
— Работа для тестировщиков. Вакансии
— QA Вакансии
— Job for Tester

🐍 Если учишься / работаешь с Python
Вакансии от джуна до сеньора, pet-проекты и реальные компании:
@pythonrabota

Java
@javaoffers

PHP
@rabotaphp

C# / .NET
@rabotacschap

Golang
@jobgolang

Project/Product менеджер
@projectmanagersjob

Релокация / зарубежные позиции
@relocatesme

Чтобы удобно пользоваться ВСЕМИ каналами забирай объединенную папку 🗂 IT-Вакансий

#подборочка