Попались 😂

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

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

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

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. Если бы можно было решить одну проблему в карьере тестировщика мгновенно - что бы это было?