Есть ли способ доказать, что измененная реализация не вводит регресс?

Question

Есть две конечности:

• Протестируйте всю систему после любого изменения кода.
• Не тестируйте вообще.

Здесь под "Тестирование" я имею в виду запуск всех неавтоматизированных тестов. Пользовательские приемочные тесты, чтобы быть более точным.

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

Я считаю, что 100% покрытия кода здесь недостаточно.

Answer 1

Ну, кажется, вы смешиваете термины. Нарушение поведения системы не означает, что система не проходит приемочные тесты, а также вы можете разрушить UAT, не нарушая систему, если у вас есть требования к производительности, или какие-то визуальные или UX вещи.

Если вы говорите о регрессии - то, что ранее пройденный UAT все равно пройдет, то их следует максимально автоматизировать. У QA всегда есть планы тестирования для регрессии в разных средах, их можно автоматизировать даже для сравнения скриншотов в разных разрешениях, как в Facebook.

Если вы говорите о новой функциональности и ее UAT, то вы можете формализовать и автоматизировать ее перед внедрением, например, подход огурца.

Другой способ - это тестирование на пользователях, таких как яндекс или почта. Вы показываете пользователям или сотрудникам компании известную версию, и если вы не собираете ошибки или жалуетесь, вы, вероятно, в порядке. Но это не то, что вы будете делать для каждого коммита, и если это приложение или приложение для ПК, все может стать сложнее