📊1. Метрики: баги, серьёзность, проход тестов, покрытие требований

1️⃣Базовые:
🤍Количество найденных багов:

Сколько ошибок выявили? Сравнивайте между релизами/модулями.

👉 Пример:
🤍В релизе 2.5 в модуле "Оплата" нашли 2 критических бага.
В релизе 2.4 в этом же модуле нашли 4 критических бага.
(4 - 2) / 4 * 100% = 50%


🤍В релизе 2.5 в модуле "Корзина" нашли 5 багов Средних(Medium) и 1 Низкий(Minor)
В релизе 2.4 в модуле "Корзина" нашли 4 Низких (Minor) бага

🤍По общему числу багов: (6 - 4) / 4 × 100% = +50% (рост на 50%).
По Critical-багам: (0 - 0) / 0 * 100% -> не рассчитывается (стабильно 0).

🤍Формула:
Процентное изменение = ((Новое значение - Старое значение) / |Старое значение|) * 100%

🤍Распределение багов по Серьезности: (пост о приоритетах и серьезности)

👉

Пример:
Blocker/Critical > 20%:

🚨

Высокий риск! Срочно фиксить!
Пример:
"Critical: 25% (5 из 20 багов) — критические ошибки в оплате. Требуется немедленное вмешательство!"

Major > 30%:

⚠️

Серьезные проблемы. Приоритетный фикс.
Пример:
"Major: 40% (8 из 20) — частые сбои функционала. Необходимо ускорить исправления."

Medium/Minor > 70%:

✅

Низкий риск. Стабильное качество.
Пример:
"Medium+Minor: 85% (17 из 20) — преобладают незначительные дефекты. Модуль стабилен."

Формула:
(Кол-во багов уровня / Общее кол-во багов) × 100%

🧡Процент успешных тестов (Pass Rate): % тест-кейсов, прошедших успешно.

👉

Формула:
Pass Rate = (Количество Passed тестов / Общее количество Executed тестов) * 100%
_____

🧡

Пример:
Passed : 80
Failed: 20
Blocked: 50
Skipped: 0
Всего запланировано тестов: 150
Фактически выполнено (Executed):
80 + 20 = 100

🧡

Процент успешных тестов (Pass Rate):
= (Passed / Executed) × 100%
= (80 / 100) × 100% = 80%

🧡

Процент блокировок (Blocked Rate):
= (Blocked / Всего запланировано) × 100%
= (50 / 150) × 100% ≈ 33.3%

🧡

Процент выполнения плана (Completion Rate):
= (Executed / Всего запланировано) × 100%
= (100 / 150) × 100% ≈ 66.7%

💚

Покрытие требований тестами: % функционала, который проверили.

👉

Пример:
Создай Traceability Matrix
→ Таблица связи: Требование ID — Тест-кейсы.

💚

Пример:
Требование ID Тест-кейсы
REQ-123 TC-45, TC-78
REQ-456 Не покрыто!

💚

Посчитай покрытые требования:
→ Требования с ≥ 1 привязанным тест-кейсом = A
→ Всего требований в модуле/релизе = B

💚

Рассчитай процент:
→ Покрытие = (A / B) × 100%

💚

Оцени глубину (критично!):
→ 1 требование ≠ 1 тест-кейс!
→ Проверь:
Есть ли тесты для граничных значений?
Покрыты негативные сценарии?
Учтены альтернативные потоки?

#знания
Нашли опечатку, пишите в лс @larisa_voin

Попались 😂

Тема: Знакомство с участниками сообщества

Это поможет вам найти коллег для обмена опытом, а возможно, и будущих партнёров по проектам.

👋Пожалуйста, представьтесь по шаблону ниже:

1. Ваше имя (или как к вам обращаться):
2. Из какого вы города:
3. Ваш опыт в тестировании: (например: нет опыта / месяц / 1+ год и т.д.)
4. Чем сейчас занимаетесь: (учусь / работаю тестировщиком / работаю в другой сфере / в активном поиске)
5. Чего ждёте от этого сообщества?(найти друзей / учиться / делить опыт / свой вариант)
6. Чем увлекаетесь или что хотите рассказать о себе? (люблю видеоигры / читаю / путешествую)
7. Чем могу быть полезен(-на) сообществу?(делюсь опытом, готов помочь советом)
8. Над каким проектом работаете или что сейчас изучаете?
9. Какой инструмент или технология в QA вас сейчас больше всего интересует?
10. Какую цель в профессиональном развитии вы ставите на ближайший год?

Если вопрос в списке - не нравится , пропусти его

Добавьте тег #общение в конце

2. Метрики качества продукта для QA-инженеров.

🤍О Качестве Продукта:

Процент дефектов, дошедших до пользователей

Формула:
Escaped Defect Rate (%) = (Количество багов в проде / Общее количество багов) *100%

Расчет:
Находим общее количество багов:
Всего багов = Баги в QA + Баги в Prod = 95 + 3 = 98`

Escaped Defect Rate (%) = (3 / 98) * 100%

Вычисляем результат:
Escaped Defect Rate (%) ≈ 3.06%

Цель: Стремиться к 0% (идеал), но на практике <5% — хороший показатель.

🤍🤍🤍🤍🤍
Плотность дефектов (Defect Density)- это метрика, которая показывает концентрацию ошибок в модуле или компоненте относительно его размера.

Формула:

Плотность дефектов= кол багов / размер модуля (требования, фичи).

Расчет:

Модуль "Поиск" = 8 багов / 5 требований = 1.6 бага

Как использовать?

Нашли модуль с самой высокой плотностью → чините его первым!

Пример:

Нашли модуль с самой высокой плотностью → чините его первым!
Пример:

"Плотность 'Поиска' = 1.6, а у других 0.3–0.8 → значит, 'Поиск' — наш 'пожар'!"
Если плотность резко выросла → тревога!

"В прошлом релизе было 0.9, сейчас 1.6 → что-то сломалось!"

Всегда смотрите типы багов:
→ 1 баг "не находит товар" (Critical) > 5 багов "неправильный шрифт" (Minor).

🤍О Процессе и Вашей Работе:

Коэффициент отклонения багов (Rejection Ratio): % ваших баг-репортов, отклоненных (дубликат, не воспроизводится и т.д.).

Формула:

Rejection Ratio (%) = (Количество отклоненных багов / Общее количество ваших багов) * 100%

Высокий %? Учитесь писать четче!

Расчет:

Данные за последний месяц:
Всего вы завели багов: 42
Из них было отклонено: 5
2 бага — дубликаты(уже были созданы ранее).
2 бага — не воспроизводятся (разработчик не смог повторить ошибку по вашим шагам).
1 баг — by design(«так и задумано», поведение системы не является ошибкой).

Расчет:

Rejection Ratio (%) = (5 / 42) * 100% ≈ 11.9%

Цель:

Стремиться к 0% идеально, но на практике <5-10%— хороший показатель. Выше 15-20% — это уже серьезный повод пересмотреть свою работу.

🤍🤍🤍🤍🤍
Коэффициент переоткрытия багов (Reopen Rate): % багов, вернувшихся после "исправления".

Формула:

(Переоткрытые / Закрытые баги) * 100%

Высокий %? Проблемы с фиксами или ретестом!

Расчет:

Данные за спринт:
Всего багов было закрыто (исправлено):50

Из них пришлось переоткрыть: 6
3 бага — фикс неполный (разработчик исправил только часть проблемы).
2 бага — появилась новая ошибка (исправление затронуло соседний функционал и сломало его).
1 баг — ошибка на тестовом окружении (на стейдж -среде фикс работал, а на продовой — нет).

Расчет:

Reopen Rate (%) = (6 / 50) * 100% = 12.0%

Цель:

стремиться к 0% идеально, <5-10%— зона риска. Выше 10% — тревога

🤍🤍🤍🤍🤍
Test Execution Speed (Скорость выполнения тестов)
Эта метрика для планирования

Формула:

Общее количество выполненных тест-кейсов / Затраченное время (дни или спринты)

Скорость на человека в день

= (Общее количество кейсов / количество тестировщиков) / количество рабочих дней

Скорость на человека в день

= (240 кейсов / 2 тестировщика) / 10 дней = 12 кейсов/день

Расчет:

Задача на новый спринт:

Нужно протестировать новый большой функционал, который содержит 360 тест-кейсов.

Вопрос:

Успеет ли команда сделать это за спринт? Если нет, что делать?

Оцениваем нагрузку:

Наша скорость: 240 кейсов/спринт.
План на новый спринт: 360 тест-кейсов.

Вывод:

360 > 240 → Команда не успеет выполнить все тесты за один спринт.

🤍🤍🤍🤍🤍
❗️ Важно помнить:
Метрики — не самоцель! Они помогают понять картину, найти слабые места, спланировать работу.

#знания

🤍🤍Такое ощущение, что тут все уснули.

🔥Со склада — в IT: один тестирует программы, другой — проверяет на прочность рекрутеров.

💜Это история Димы и Аллы, которые год назад разгружали коробки, а теперь штурмуют айтишный мир с двух флангов:

🖤Дима: Уже джуниор, учит Python и Kotlin. Его кредо: упорство + наставник + ночи за учёбой.

🖤Алла: Отправила 327 резюме, получила 33 отказа, ловит по 15+ багов в тестовом, но всё равно не сдаётся.

💜Вместе они создали канал «Путь Джуна». Там нет глянца — только то, о чём молчат другие:

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

🖤 Это честный дневник тех, кто не ищет лёгких путей.

🖤Подписывайтесь, чтобы читать продолжение!
@way_of_junior

💬Пишите ваши вопросы для Димы и Аллы в комментарии

Ставь 🔥, если хочешь прямую трансляцию с авторами блога

570 😍

Время вашего мнения: ответьте на 4 вопроса ⌛

🤍1. С какими основными сложностями сталкиваетесь при изучении тестирования или на первых проектах?

🤍2. Какой вопрос о тестировании вам бы хотелось разобрать максимально подробно?

🤍3. Какой этап изучения тестирования требует больше всего времени и усилий?

🤍4. Если бы можно было решить одну проблему в карьере тестировщика мгновенно - что бы это было?