Попались 😂

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

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

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

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

Всем хорошего вечера
Сил на пост, нет 😴

☄️Внедрение QA (Quality Assurance — обеспечение качества) процессов в проекте, где их никогда не было

👩‍💻🖤Шаг 1: Диагностика и аудит
Задайте себе и команде вопросы:

- Что сейчас? 
1. Кто и как проверяет фичи? Разработчик сам проверяет свою работу? Показывает коллеге? Делает демо продукт-менеджеру?

2. Как часто выходят релизы? Это регулярные процедуры или хаотичные?

3. Кто принимает решение, что можно выпускать?

4 Как происходит откат, если что-то пошло не так?

- Где болит? 
1. Какие баги «утекают» на прод
чаще всего?

2. Сколько времени уходит на их исправление? (фикс + повторное развертывание + проверка)?

3. Как описаны задачи? Все ли однозначно их понимают?

4. Часты ли ситуации «я сделал то, что ты сказал, но не то, что ты хотел»?

- Что за проект? 
MVP / Стартап: Скорость важнее идеального качества.

Enterprise-решение / Высоконагруженный проект: Качество, стабильность и безопасность — приоритет.

Вывод по шагу 1: Поймите текущее состояние и болевые точки.
🖤🖤🖤

👩‍💻🖤Шаг 2: Фундамент — Начните с планирования (Test Plan Light — облегченный тестовый план)

1. Что мы тестируем? (Объем тестирования)
- Определите критически важный функционал (то, что точно не должно сломаться)
- Составьте список основных функций и модулей продукта

2. Как мы это тестируем? (Стратегия и подходы)
- Ручное тестирование — пока основной инструмент
- Автотесты — начните с 2-3 ключевых e2e-тестов (end-to-end — сквозное тестирование)
- Регрессионное тестирование — чек-лист основных сценариев

3. Когда мы это тестируем? (Вход и выход критерии)
- Вход: Когда функция готова к тестированию
- Выход: Когда функция считается протестированной

Результат шага 2: У вас есть легкий, понятный всем документ — «Правила игры».
🖤🖤🖤

👩‍💻🖤Шаг 3: Инструменты и среда
Не усложняйте. Начните с минимального набора:

1. Баг-репорты:
- Используйте трекеры задач: Jira, YouTrack
- Научите команду правильно оформлять баги

2. Тестовая документация:
- Чек-листы /тест-кейсы
- Mind maps (интеллект-карты) для визуального планирования

3. Тестовые среды:
- Локальная среда у разработчиков
- Общая тестовая среда (stagе)

Результат шага 3: У вас есть «единая точка правды» для багов и простые инструменты для организации работы.
🖤🖤🖤

👩‍💻🖤Шаг 4: Встраиваемся в процесс разработки
Самая важная часть. Ваша цель — находить баги как можно раньше.

- Участие в планировании — задавайте вопросы на этапе проектирования
- Релизный цикл — определите четкий процесс тестирования
1. Разработка завершена → код в тестовой среде
2. QA проводит тестирование
3. Разработчики исправляют баги
4. Ретест (повторная проверка)
5. Готово к релизу

Результат шага 4: Тестирование становится неотъемлемой частью цикла разработки.
🖤🖤🖤

👩‍💻🖤Шаг 5: Масштабирование и автоматизация

Когда основные процессы налажены:
1. Автоматизация регресса — постепенно добавляйте автотесты
2. CI/CD - интегрируйте тесты в процесс сборки
3. Метрики — начинайте считать показатели качества

Результат шага 5: Процесс становится предсказуемым и масштабируемым.

🖤🖤🖤
🖤Главные принципы, которые стоит запомнить
- Ваша задача не в том, чтобы найти все баги, а в том, чтобы защитить продукт и пользователей от серьезных проблем
- Если какой-то процесс не работает, смело меняйте его.
- Идеальных решений нет, есть рабочие

Договоритесь о простых правилах, подберите базовые инструменты и постепенно становитесь частью рабочего процесса
#знания

Пишите свои мысли
Как внедряли тестирование ?
С какими сложностями столкнулись ?

Реакцию ❤️плиз на пост