🤍🤍🤍🤍🤍🤍🤍🤍

#уроки
1. Задание: Чит-листы
2. Задание: Исправление баг - репортов
3. Задание: Серьезность и Приоритет
4. Задание: Ищем баги на тренировочном сайте «Собаседник»
5. Задание: Тест-кейс ДЗ 1 (Ламода)
6. Задание: Тест- кейс ДЗ 2 (Лемана ПРО)
7. Задание: Составление тест-сьюта
8. Задание: Проведение тест-рана
9. Задание: Разработка интеграционных тест-кейсов для Лемана ПРО
10. Задание: Написание чек-листа для мобильного приложения Яндекс.Маркет
11. Тестирование требований
12. Тест-дизайн на практике
13. Тест-план для мобильного приложения Ozon

🤍🤍🤍🤍🤍🤍🤍

#словарь
1. Пагинатор/бордер
2. Превью и маска
3. Хедер и футер
4. Чек-бокс
5. Тогл
6. Индикатор загрузки
7. Datepicker
8. Splashscreen
9. Action menu
10. Toast
11. Кнопка
12. Progress bar
13. Drag-and-drop
14. Вкладки - табы
15. Онбординг
16. Алерт
17. Выдвижная панель
18. Попап
19. Лонгтап
20. Слайдер
21. Counter
22. Pinch
23. Скрол
24. Фильтры
25. Blisk — адаптивный браузер

🤍🤍🤍🤍🤍🤍🤍🤍🤍🤍🤍

📍#инфо

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

19. Приоритизация и управление временем: Как успевать больше без стресса?
20. Проверила один баг → нашла два новых.
21. Смежные профессии для тестировщиков

📍 #созвон
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 Ретест
39. Фильтрация vs Сортировка: Ловим хитрые баги
40. Тестируем вход по номеру телефона
41. Тестируем форму входа/регистрации по email и паролю

🚦 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

Попались 😂