🔈Регрессионное тестирование: Как не сломать старое, добавляя новое?

Есть несколько основных стратегий.

✅1. Полный регресс

Что это: Вы проверяете ВСЁ. Абсолютно все функции продукта, как будто он снова на стадии полного тестирования.
Когда использовать:

- Крупные релизы или смена мажорной версии (например, с v2.0 на v3.0).
- Когда изменения в коде были глобальными и затронули ядро системы.
- После серьезного рефакторинга архитектуры.

Плюсы: Максимальное покрытие и (теоретически) уверенность, что ничего не упустили.
Минусы: Очень дорого, долго и часто избыточно. На практике применяется все реже.

✅2. Выборочный регресс

Что это: Быстрая проверка только самых КРИТИЧЕСКИХ функций, без которых продукт не может работать.

Когда использовать: После каждого небольшого билда, чтобы убедиться, что «система не дымится» (smoke test) и можно приступать к более глубокому тестированию.

Плюсы: Очень быстрый, отсекает катастрофические баги на раннем этапе.
Минусы: Не дает никакой гарантии по остальному функционалу.

✅3. Регресс по зонам риска

Что это: Самый интеллектуальный подход. Вы анализируете, какие именно модули и функции были затронуты изменениями, и какие из них наиболее критичны для бизнеса. Фокус — на точках пересечения.

Плюсы: Оптимальное соотношение усилий и результата. Требует глубокого понимания продукта и архитектуры.
Минусы: Можно что-то упустить, если анализ рисков проведен неверно.

✅4. Регресс на основе чек-листа

Что это: У вас есть заранее подготовленный (и постоянно обновляемый!) чек-лист основных сценариев, которые должны всегда работать. Вы не покрываете всё, но покрываете главное.

Плюсы: Структурировано, повторяемо, проще для новичков.
Минусы: Чек-лист может устаревать, если за ним не следить.

📎Какую стратегию выбрать?

Спросите себя:

· Масштаб изменений? (Одно поле / целый модуль)
· Критичность изменений? (Затрагивает ли ядро?)
· Сколько есть времени?
· Насколько зрелая ваша автоматизация?

Чаще всего вы будете комбинировать эти стратегии: перед каждым билдом — смоук-тест, в конце спринта — регресс по зонам риска, а перед крупным релизом — почти полный регресс
#знания

🧠Тестирование — это не про то, чтобы знать все ответы, а про то, чтобы уметь находить решения.

Мы все иногда бываем в тупике: странный баг, спорные требования или просто нужен совет по карьере.

🤝Не стесняйтесь просить о помощи!

⬇️Если у вас есть вопрос, нужна подсказка или просто мнение по ситуации в тестировании — пишите прямо в чат канала, в личку @larisa_voin или в комментарии под постами

Что можно спросить?

· Как подойти к тестированию этой штуки?
· Сталкивался ли кто-то с таким багом?
· Какой инструмент лучше выбрать?
· Помогите разобрать тест-кейс.
И тд

Думаю над призами 👁️

➡️Подставка для ноутбука
➡️Павербанк

А что еще❔

🟢💚💚💚💚💚💚💚💚

Протестируй свою удачу! Участвуй в нашем розыгрыше — все просто и понятно.

💚Призы для трех победителей
➡️Подарочная карта Ozon на 1500₽ (или любой товар с Ozon на эту сумму - по выбору победителя)
➡️Подставка для ноутбука
➡️Павербанк

💚Как участвовать
💚Подписаться на @testingqabug
💚Сделать репост этой записи в любой соцсети ИЛИ отправить ссылку другу
💚В комментариях ниже написать порядковый номер и прикрепить скриншот

💚Формат комментария
«1» + скриншот репоста/отправки
«2» + скриншот репоста/отправки
«3» + скриншот репоста/отправки
и так далее...

💚Важно
💚Проверьте наличие пунктов выдачи Ozon в вашем городе
💚Приз отправляем в течение 24 часов после определения победителя

💚Сроки: до 31 октября
💚Итоги: 1 ноября - выберу победителей по номеру комментария через
https://randstuff.ru/number/

✍️Домашнее задание: «Тест-план для мобильного приложения Ozon»

Цель: Научиться структурировать процесс тестирования и создавать ключевой документ, определяющий scope, подход и риски проекта.

Продукт для тестирования: Мобильное приложение Ozon
Версия: 4.25.0 (гипотетический следующий релиз)

💚💚💚
📝Описание продукта:

Ozon — мобильное приложение одного из крупнейших в России маркетплейсов.
Целевая аудитория: пользователи 18-60 лет, совершающие покупки онлайн.

🕷Основной функционал для тестирования в версии 4.25.0:

1. Поиск и каталог
- Поиск товаров по названию/артикулу
- Фильтрация и сортировка
результатов
- Просмотр категорий товаров
- Карточка товара (характеристики, отзывы, рейтинг)

2. Работа с корзиной
- Добавление/удаление товаров
- Изменение количества товаров
- Применение промокодов
- Расчет общей стоимости

3. Оформление заказа
- Выбор способа доставки.
(курьер, пункт выдачи)
- Выбор способа оплаты (карта,
рассрочка, наличные)
- Ввод/выбор адреса доставки
- Подтверждение заказа

4. Личный кабинет
- Просмотр истории заказов
- Отслеживание текущих заказов
- Настройки уведомлений
- Бонусный счет Ozon Card

5. Акции и промо
- Просмотр акционных товаров
- Участие в распродажах (Ozon Days)
- Персональные предложения

💚Технические требования:
💚Поддерживаемые ОС: iOS 14+, Android 10+
💚Необходим интернет для работы основных функций
💚Поддержка различных разрешений экрана

💚💚💚
💚Задание:

Разработать упрощенный тест-план для мобильного приложения Ozon версии 4.25.0. План должен содержать следующие разделы:

1. Введение
- Краткое описание проекта и целей тестирования

2. Цели тестирования
Какие бизнес-критичные функции требуют наибольшего внимания?
Пример: бесперебойное оформление заказа, корректность расчетов стоимости

3. Объем тестирования
- Входит: основные сценарии
покупки, работа корзины, поиск товаров

- Не входит: Ozon Travel, Ozon Finances, Ozon Premium (предположим, что они не входят в этот релиз)

4. Подход/Стратегия
Какие виды тестирования будут применяться

5. Расписание/Этапы
Предложите примерный план на 2 недели

6. Критерии начала/окончания тестирования
- Начало: сборка от разработчиков прошла smoke-тестирование

- Окончание: выполнено 95% тест-кейсов, критические баги исправлены

7. Риски
Минимум 3-5 потенциальных рисков:
Пример:
- Нестабильность тестового стенда
- Недоступность платежного шлюза для тестирования
- Изменение требований в процессе тестирования
- Для каждого риска предложите способ mitigation

💚💚💚
📊Критерии оценки:
💚Полнота разделов — все пункты плана заполнены
💚Реалистичность — предложения соответствуют реальному
e-commerce проекту
💚Понимание приоритетов — выделены бизнес-критичные функции
💚Качество рисков — риски реалистичны для проекта такого масштаба
💚Структура документа — логичная последовательность разделов

💡Советы для выполнения:
- Сфокусируйтесь на основных пользовательских сценариях (поиск → товар → корзина → заказ)
- Учитывайте высокие требования к безопасности (платежные данные)
- Помните о важности кросс-платформенного тестирования (миллионы пользователей на разных устройствах)
- Предусмотрите тестирование в условиях нестабильного интернета

💚💚💚
Форма сдачи и срок:
1. Ссылка на Google таблицу
2. Срок: 31 октября 2025

💚Работы проверяются только от подписчиков канала
💚Дз проверяется, если отправлено первое по теме «Чит-листы»
💚Если не успели сдать, то отправляете 2 сделанные домашки (первые из списка)

💬 Если присоединились позже дедлайна, напишите мне для уточнения @larisa_voin

#уроки

👋Регресс vs Ретест

🔎Ретест (Re-test)

🤍Что это?
Повторная проверка одного и того же дефекта после того, как разработчик его исправил. Берем баг-репорт, который был в статусе «Fixed», и убеждаемся, что теперь всё работает как надо.

🤍Когда делаем?
Сразу после того, как получили от разработчика билд с исправлением. Это быстрая точечная операция.

🤍Зачем?
Чтобы поставить дефекту статус «Closed» и двигаться дальше. Это формальность, но обязательная.

🤍Простая аналогия:
Представьте, что у вас в машине перегорела лампочка в фаре. Вы ее заменили. Ретест — это когда вы включаете фару, чтобы проверить, горит ли та самая, новая лампочка.

💡Регрессионное тестирование (Regression Testing)

🤍Что это?
Это более масштабная проверка. Мы убеждаемся, что новое исправление (или новая функциональность) не сломала существующий, ранее работавший функционал.

🤍Когда делаем?
- После исправления серьезного или сложного бага.

- После добавления новой фичи.

- После изменения кода (рефакторинга).

- Перед выпуском версии (релизом) — это ОБЯЗАТЕЛЬНЫЙ этап.

🤍Зачем?
Потому что код — это часто карточный домик. Можно ткнуть в одном месте, и оно упадет в другом. Регресс — это наша страховка от таких сюрпризов.

🤍Простая аналогия:
Продолжая пример с машиной. Вы поменяли лампочку в фаре (ретест показал, что она горит). Регресс — это когда вы заводите машину, проверяете ближний/дальний свет, габариты, поворотники, печку, магнитолу и т.д. Вдруг при замене лампочки вы случайно задели проводку, и теперь не работает поворотник?

🤍Выводы
Сначала ретест. Всегда сначала убедись, что починили именно тот баг, что ты нашел. Закрой его.

Потом — регресс. Подумай, что еще могло задеть это исправление, и проверь эти области. Особенно то, что связано логически.

#знания