👀Все учимся, это не заканчивается!

🚀Чем я занимаюсь сейчас:
Самостоятельное обучение.

➖Перевожу автотесты на Page Object Model. Свои сложности и область изучения.

➖Уделяю время не только практике, но и теории автоматизации. Медленно, больше в выходные.

➖Циклы, массивы и более подробное изучение JS.

➖Хочу писать еще более сложные автотесты.

Можете поделиться в комментарии , что изучаете и с чем сложности

Ночь на подходе, время укутаться в уют. Завтра вас ждет новый пост. Спокойной ночи 🚀

🧩Frontend vs Backend: Куда смотреть тестировщику?

🌐Frontend — "лицо" приложения
Что тестируем:
1. Вёрстка: "Уезжает" ли меню на Samsung Galaxy? 📱
2. Логика UI: Блокируется ли кнопка после клика?
3. Валидация: Ругается ли форма на email "test@"?

Пример бага: Календарь выбора даты на iPhone 15 не прокручивается.

⚙️Backend — "мотор" системы
Что тестируем:
1. Бизнес-логика: Списались ли деньги при отмене заказа? 💸
2. Работа с БД: Пропадают ли загруженные файлы? 💾
3. API: Возвращает ли /orders ошибку 500 при фильтрации?

Пример бага: После смены пароля можно войти со старым паролем через API.

➖Пример взаимодействия:

Сценарий "Оплата заказа":

Фронт: Ввод карты → анимация "Загрузка..."

Бек: Проверяет баланс → отправляет запрос в банк

Фронт: Получает "Успех" → показывает номер чека
#знания

💡Как это поможет в работе?
• Локализация багов:

- "Не работает оплата"

+ "Фронт: Кнопка 'Оплатить' не блокируется при повторном клике

+ Бек: /pay возвращает 400 при CVV=000 (должен=200)"

🛠

Лайфхак:

Откройте DevTools (F12) → вкладка Network:

• Статусы 4xx/5xx → ошибка бека
• Долгий ответ сервера → проблема производительности
• Кривой интерфейс при 200 OK → баг фронта

🤍🤍🤍🤍🤍🤍

#какнайтиработу
1. Поиск вакансий тестировщика
2. Почему врут в резюме: причины и решение
3. Как уменьшить процентов отказов ботом hh
4. Как найти первую стажировку тестировщику
5. Таблица откликов при поиске работы (стажировки)
6. Как ответить на неизвестный вопрос на собеседовании QA?
7. Из корзины - в оффер: Какие ошибки в резюме начинающего тестировщика топят карьеру на старте

🤍🤍🤍🤍🤍🤍🤍🤍

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

🤍🤍🤍🤍🤍🤍🤍🤍🤍🤍🤍

📍#инфо

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

📍 #созвон
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. Метрики: баги, серьёзность, проход тестов, покрытие требований

🚦 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