🤍🤍🤍🤍🤍🤍🤍🤍🤍🤍🤍

📍#инфо

1. Ошибочные утверждения о тестировании и почему они неверны
2. Стресс тестировщика
3. Подходит ли мне тестирование?
4. Баг- трекеры
5. Страх тестировщика. Ручное тестирование скоро станет не нужным?
6. Боюсь не обнаружить дефекты. Как себе помочь
7. Как найти время на учебу, если у вас работа, учеба или семья?
8. Мини-опрос для тестировщиков
9. Советы для тестировщиков перед дедлайнами
10. Как преодолеть страх перед недостаточной квалификацией в тестировании
11. Страх перед недостаточной документацией
12. Страх перед негативной обратной связью
13. Страх перед взаимодействием с разработчиками
14. Страх перед изменениями в проекте
15. Страх перед новыми технологиями
16. Состав команды Разработки
17. Как работать и не выгорать ?
18. Как Miro и подобные подобные в могут помочь тестировщикам в работе ?
19. Приоритизация и управление временем: Как успевать больше без стресса?
20. Blisk — адаптивный браузер
21. Проверила один баг → нашла два новых.
22. Смежные профессии для тестировщиков

📍 #созвон
1. Созвон с тестировщиком: «от поиска работы до первых успехов»

🤍🤍🤍🤍🤍🤍

#знания
1. Типы требований
2. Жизненный цикл тестирования
3. Жизненный цикл бага
4. Пишем баг-репорт
5. Ошибки при написании баг-репорта
6. Что происходит с баг-репортом после его создания?
7. Серьёзность и приоритетность багов: что нужно знать
8. Шпаргалка для составления баг-репорта
9. Тест - кейсы. Урок 1
10. Где писать тест - кейсы
11. Зачем писать тест-кейсы
12. Ошибки при создании тест - кейсов .
13. Какие статусы есть у тест - кейсов
14. Что такое тест-сьют?
15. Тест-кейсы: почему их нужно регулярно обновлять?
16. Тест-ран. Этапы проведения
17. Типы тест-кейсов
18. Что отличает тест-кейс от баг-репорта
19. Чек-листы заменяют тест-кейсы?
20. Рекомендации по составлению чек-листа
21. Структура пирамиды тестирования
22. Клиент-серверная архитектура
23. Основные виды ручного тестирования
24. Тест-дизайн в тестировани. Техники тест-дизайна. Эквивалентное разбиение, Анализ граничных значений
25. Попарное тестирование
26. Таблица принятия решений
27. Предугадывание ошибок
28. Что считать плохим требованием к продукту?
29. Использование Holst
30. Кросс-платформа vs Кросс-браузер: В чем разница и зачем это ?
31. Frontend vs Backend: Куда смотреть тестировщику?
32. START & STOP: Когда начинать и заканчивать тестирование?
33. 1. Метрики: баги, серьёзность, проход тестов, покрытие требований
34. 2. Метрики качества продукта для QA-инженеров.
35. Внедрение QA (Quality Assurance — обеспечение качества) процессов в проекте, где их никогда не было
36. Тестовая стратегия и Тест-план
37. Регрессионное тестирование: Как не сломать старое, добавляя новое?
38. Регресс vs Ретест

🚦 START & STOP: Когда начинать и заканчивать тестирование?

▶️НАЧИНАЕМ ТЕСТИРОВАТЬ, КОГДА:

✅Среда готова: Серверы, доступ, стабильность – есть.

✅Данные на месте: Нужные для + и - сценариев – готовы.

✅Билд установлен: Четко знаем, что тестируем.

✅Документы есть: Требования + тест-кейсы/чек-листы (хотя бы миник) – доступны.

✅Критичные баги прошлые – закрыты (если были).

🛑ЗАКАНЧИВАЕМ ТЕСТИРОВАТЬ, КОГДА:

✅План выполнен: Запланированные тесты (особенно ключевые!) – пройдены.

✅Покрытие требований – достигнуто: Основной функционал проверен.

✅Качество ОК:

✅Blocker/Critical баги – ИСПРАВЛЕНЫ и проверены.

✅Остальные баги – низкого приоритета, их риски приняты стейкхолдерами.

✅Smoke-тест финального билда – ПРОЙДЕН.

✅Сроки вышли (и пункты 1-4 в адекватном состоянии).

🚫 НЕЛЬЗЯ заканчивать ТОЛЬКО из-за:

"Протестировали ВСЁ" (невозможно!)

"Кончились тест-кейсы"

"Устали"

"Завтра релиз!"

"Менеджер сказал" (без оценки рисков!)

💡Суть:
Старт – когда есть ВСЕ условия для работы.
Стоп - при достижении целей качества или истечении сроков с приемлемым качеством и принятыми рисками

#знания

Предложить тему поста

📊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 → Команда не успеет выполнить все тесты за один спринт.

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

#знания

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