Отчет верен, потому что кто-то исправил его до того, как он покинул команду. Если вы тестируете только окончательный отчет, вы можете пропустить исправление, которое сделало его правильным. Рассмотрим вымышленное приложение, которое экспортирует служебные записи. Рецензент неоднократно со...
Отчет верен, потому что кто-то исправил его до того, как он покинул команду.
Если вы тестируете только окончательный отчет, вы можете пропустить исправление, которое сделало его правильным.
Рассмотрим вымышленное приложение, которое экспортирует служебные записи. Рецензент неоднократно исправляет одно поле перед использованием экспорта. Это полезная отправная точка для инженерного расследования, но она еще не говорит вам, являются ли причиной проблемы данные, код, интеграция или недокументированные бизнес-правила.
В этой статье предлагается рабочий процесс на синтетических примерах. Он не сообщает о выполненном тесте или результатах клиента.
Запишите исправление, прежде чем выбирать исправление.
Зафиксируйте исходное значение, исправленное значение, причину и ссылку, использованную рецензентом. Дайте примеру стабильный идентификатор, чтобы можно было сравнивать входные, сохраненные записи и выходные данные, не полагаясь на память.
Спросите, является ли исправление детерминированным или требует суждения. Преобразование поля и исключение, требующее утверждения, требуют разных критериев приемки.
Не используйте исправление рецензента как неоспоримое оракул. Установите применимое правило и источник с лицом, ответственным за рабочий процесс.
Найдите место несоответствия
Осмотреть