Команда исправляет похожие дефекты, но они регулярно возвращаются. Как провести анализ первопричины, чтобы изменить процесс QA, а не только закрыть очередной дефект?
Нужно исследовать не только непосредственную причину конкретного сбоя, но и условия процесса, которые позволили ему появиться и повториться. Результатом должны стать проверяемые корректирующие меры: изменение требований, тестов, критериев ревью, тестовых данных или процесса выпуска с последующей проверкой их эффективности.
Анализ первопричины появился как ответ на практику устранения только видимых симптомов. Исправление отдельного дефекта восстанавливает конкретный сценарий, но не гарантирует, что аналогичная ошибка не возникнет в другой части продукта.
Подход используется в управлении качеством и улучшении процессов: цель состоит не в поиске виновного, а в обнаружении управляемой причины, устранение которой снижает вероятность повторения проблемы.
Повторяющийся дефект может иметь несколько уровней причин. Например, ошибка в интерфейсе может быть симптомом неясного требования, отсутствия проверки переходов состояния, неполных тестовых данных или того, что тестирование начинается слишком поздно.
Если команда исправляет только код, она рискует получить новый вариант той же проблемы. При этом чрезмерно широкое расследование может задержать релиз и породить меры, не связанные с доказанной причиной.
Сначала нужно точно описать повторяющийся класс дефектов: общие условия, затронутые функции, момент обнаружения, этап, на котором ошибка могла быть предотвращена, и уже предпринятые исправления. Полезно отделить симптом, непосредственную техническую причину и системную причину процесса.
Затем строят причинную цепочку. Метод «пять почему» помогает последовательно уточнять причины, но это не обязательное количество шагов и не механическое упражнение. Если причин несколько, применяют причинно-следственную диаграмму или группируют факторы по требованиям, реализации, тестированию, окружению и процессу поставки.
Каждую предполагаемую причину нужно проверять фактами: историей изменений, требованиями, результатами тестов, данными дефекта, код-ревью и условиями воспроизведения. Нельзя объявлять первопричиной удобную гипотезу только потому, что она выглядит правдоподобно.
После подтверждения причины формулируют меры. Корректирующая мера устраняет обнаруженную проблему, а предупреждающая мера снижает вероятность аналогичных проблем в будущем: например, добавляет правило к чек-листу ревью требований, расширяет регрессионный набор или вводит проверку обязательного сценария до выпуска.
Мера должна иметь владельца, срок, критерий выполнения и способ проверки эффективности. Если добавили тест, важно проверить не только его наличие, но и способность обнаружить соответствующий класс дефектов. Ограничение подхода в том, что одна неисправность может иметь несколько взаимодействующих причин, а причинность нельзя надёжно установить без достаточных данных.
В системе несколько раз появлялись дефекты, при которых после изменения статуса заказа пользователь видел старые данные. Команда каждый раз исправляла конкретный экран, но проблема возвращалась в других местах.
Рассматривались два варианта. Первый — добавить отдельные тесты для каждого найденного экрана: это быстро и недорого, но плохо защищает от повторения того же класса ошибки. Второй — исследовать жизненный цикл данных и процесс изменений: это требует времени, зато позволяет найти общую причину.
Выбран второй вариант. Анализ показал, что требования описывали изменение статуса, но не определяли момент обновления связанных данных, а тесты проверяли только успешный переход без повторного открытия экрана. Команда уточнила критерии приемки, добавила проверки обновления данных после переходов и включила их в регрессионный набор.
Результат оценивали по двум признакам: устранён ли исходный дефект и обнаруживаются ли аналогичные ошибки на связанных сценариях. Такой подход не гарантирует отсутствие всех будущих дефектов, но снижает риск повторения именно выявленного класса проблем.
Непосредственная причина — ближайшее событие, вызвавшее сбой, например отсутствие обновления данных после изменения статуса. Первопричина объясняет, почему процесс позволил этому событию появиться и не выявил его раньше: например, неясное требование и отсутствие проверки перехода между состояниями. Устранение непосредственной причины чинит конкретный случай, а устранение первопричины должно уменьшать вероятность повторения класса дефектов.
Тест может проверять только один пример и не закрывать общий механизм ошибки. Кроме того, он может быть добавлен в набор, но не запускаться на нужном этапе, иметь слабые ожидаемые результаты или зависеть от нестабильных данных. Поэтому нужно оценить область риска, включить проверки в подходящий регрессионный набор и убедиться, что процесс действительно использует их до выпуска.
Нужно заранее определить наблюдаемый критерий: например, аналогичные дефекты не должны проходить определённый этап в течение нескольких релизов, а новый тест должен воспроизводимо обнаруживать известный класс ошибок. Одного факта выполнения задачи недостаточно: запись правила в чек-лист ещё не доказывает, что оно применяется и предотвращает дефекты. Если повторения продолжаются, анализ нужно пересмотреть, поскольку найденная причина могла быть неполной или мера оказалась слишком слабой.