Ответ.

Ручное тестирование на этапе сопровождения — это тестирование уже существующей и работающей системы при доработках, исправлениях багов или интеграции новых компонентов.

История вопроса

Ранее сопровождение выполнялось по остаточному принципу, часто тестированию подвергались только новые функции. Однако со временем стало понятно, что любое вмешательство способно затронуть уже работающие сценарии.

Проблема

Типична следующая ситуация:

Вносятся локальные изменения, но их влияние на старый функционал часто недооценивается
Регрессия возникает в, казалось бы, не связанных модулях
Отсутствие системного подхода повышает риск внезапных "падений" на продуктиве

Решение

Эффективная организация maintenance testing требует:

Выделения и постоянного обновления "набора ключевых сценариев", которые проверяются при каждой доработке
Использования чек-листов и регрессионных карт
Включения в работу exploratory testing для поиска неожиданных эффектов от изменений

Ключевые особенности:

Быстрое реагирование на небольшие изменения с минимальным откатом
Фокус на реальных пользовательских сценариях, которые могут быть затронуты опосредованно
Гибкость в выборе методики: от чек-листов до креативного исследовательского тестирования

Вопросы с подвохом.

Нужно ли проверять только те модули, которые были изменены?

Нет, необходимо обязательно тестировать и связанные с ними части системы, чтобы не пропустить побочные эффекты изменений.

Достаточно ли полного регрессионного тестирования после каждого фикса?

Нет, часто достаточно проверки ключевых (критических) путей, а полный регресс проводят только перед релизом или при значительных изменениях.

Можно ли полностью отказаться от exploratory testing на этапе сопровождения?

Нет, исследовательское тестирование позволяет находить нетривиальные баги вне сценарного покрытия и должно сопровождать maintenance phase.

Типовые ошибки и анти-паттерны

Пренебрежение связанными модулями: тестируют только "патченое" место
Отсутствие актуального регрессионного набора сценариев
Игнорирование понимания архитектуры, тормозит определение зон риска

Пример из жизни

Негативный кейс

После исправления бага в профиле пользователя тестируется только профиль, но не проверяется авторизация и отображение профиля на других страницах. В результате выходит баг: на главной странице профиль не обновляется.

Плюсы:

Быстрое завершение тестирования конкретной задачи

Минусы:

Пропуск багов в связанных разделах
Снижение доверия к QA и продукту

Позитивный кейс

Исправленный баг в профиле тестируется как отдельно, так и комплексно: проводится проверка профиля везде, где он используется. Используется чек-лист ключевых сценариев.