5 инструментов для анализа первопричин (RCA), которые помогут вам улучшить тестирование и QA

от автора

Привет, Хабр! В рамках набора учащихся на курс «QA Lead» подготовили перевод статьи.

Приглашаем также всех желающих зарегистрироваться на открытый вебинар «Организация процесса тестирования в agile и не agile-командах». На вебинаре участники вместе с экспертом рассмотрят вопросы:
1. Организация процесса работы в waterfall проекте.
2. Организация процесса тестирования в scrum команде.
3. Организация процесса работы в масштабируемых agile-подходах.
4. Организация процесса тестирования в команде, работающей по kanban методу.


Когда возникает проблема, требующая анализа, компании необходимо использовать инструменты анализа первопричин (RCA) , чтобы рассмотреть нечто большее, чем «некоторые образовавшиеся симптомы».

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

Что такое RCA?

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

Это мера контроля качества, которая позволяет выяснить, что произошло, понять, почему это произошло, а затем начать настройку процесса так, чтобы уменьшить вероятность повторения одной и той же проблемы.

RCA работает на основе того, что все системы и события взаимосвязаны. Что-то одно в определенной области триггерит что-то другое в другой области. Способность отслеживать эти взаимосвязанные триггеры позволяет человеку видеть, с чего начиналась проблема и как она становилась системой, которая сейчас является основной проблемой. RCA ищет паттерны, находит ошибки, которые скрыты внутри самой системы. Он эффективно показывает первопричину или несколько причин существующих проблем.

RCA определяет, был ли дефект вызван ошибкой при тестировании, ошибкой при разработке или, возможно, требованием или ошибкой при проектировании.

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

Инструменты RCA

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

Поиск истинной первопричины проблем с помощью хорошего инструмента для анализа означает, что вы не просто пытаетесь «потушить пожар от первоначальных симптомов». 

Вот пять методов RCA, которые можно использовать в качестве инструментов для выявления первопричины проблемы.

8D RCA

Методология решения проблем 8D (8 Дисциплин или Шагов) была разработана автомобильной компанией Форд как решение проблем с ориентацией на команду (Team Oriented Problem Solving — TOPS) в 1980-х годах. Это — методология, использующая процесс анализа основной причины. Она применяется, чтобы найти проблему, зафиксировать итерим (промежуточный период), а также создать долгосрочный ответ, чтобы проблемы не повторялись. Данная методология используется для постоянного повышения надежности и качества.

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

Сосредоточение внимания на команде, а не на индивидууме также приносит пользу. Эта методология улучшает качество и надежность и работает над потенциальными проблемами будущего, прежде чем они погубят продукт. Ее следует использовать для оценки:

  • Безопасности и регулярных обнаруженных проблем

  • Поступающих жалоб клиентов

  • Ситуаций, когда гарантийные проблемы показывают более высокую частоту отказов, чем ожидалось.

  • Неприемлемых уровней внутреннего брака и низкой производительности или полных отказов при тестировании.

Инструмент Исикавы для RCA

Инструмент Исикавы — Диаграмма Исикавы или диаграмма «рыбьей кости».

Как бы странно ни звучало название, оно описывает внешний вид анализа на бумаге. В самом простом варианте, это просто причинно-следственная диаграмма. Она также называется «Диаграмма Исикавы».

Этот инструмент помогает при «брейнсшторминге» как части процесса анализа в попытке выявить элементы, которые вызвали проблему. По сути, это дерево первопричин в обратном направлении. Схема дерева используется для того, чтобы сузить список причин, а «рыбья кость» расширяет его. Диаграмма рыбной кости используется для изучения причин и следствий. Проблема помещается на «голову рыбы», а затем на маленьких костях различных категорий записываются потенциальные причины.

Она позволяет взглянуть на потенциальные причины, которые в противном случае могли бы быть упущены. После четкого определения проблемы командой создаются такие категории, как поставки, оборудование, персонал и т.п. Затем вы брейнштормите о том, почему произошло определенное событие. Диаграмма «рыбная кость» держит в центре внимания причину, а не «симптомы». Ценность диаграммы в том, что она позволяет членам команды глубоко копнуть и понять проблему, чтобы ее можно было адекватно решить в настоящем и будущем.

Техника RCA 5-Почему

Этот инструмент — еще один надежный способ найти первопричину проблемы и предотвратить ее повторное возникновение. Эта система была создана Сакичи Тойода (Sakichi Toyoda) и является частью философии Бережливого производства. Смысл состоит в том, чтобы пять раз спросить «почему?», когда возникает какая-то проблема. Это делается для того, чтобы решение стало понятным. Это поможет найти и устранить первопричину проблемы, чтобы избежать повторных неудач.

Этот процесс осуществляется путем формирования межфункциональной команды для наличия различных уникальных точек зрения. Вам нужно четко определить проблему, чтобы не было сомнений в том, что исследуется. Пусть кто-нибудь возглавит команду и будет фокусировать ее на проблеме. Начните спрашивать «почему?» и анализировать ответы до тех пор, пока не найдете первопричину проблемы.

Будьте открыты к тому, что, возможно, причина будет не одна. Что возможно вам нужно будет принять определенные меры по устранению проблемы, как только будет найдена ее причина. Проверяйте, была ли устранена проблема и если нет, начните процесс заново.

5m, 6m, и E Анализ RCA

Эти инструменты для анализа первопричины очень схожи. Все эти анализы: 5М, 6М и E имеют похожие категории для анализа: Люди, Инструменты, Измерения, Материалы, Методы и Окружение. Эти элементы содержат ответы в случае возникновения проблемы или изменений в процессе.

Существуют вопросы, которые необходимо задать, на которые необходимо ответить и оценить для того, чтобы сузить область, в которой может находиться первопричина. Это может применяться к тестированию программного обеспечения, поскольку проблемы могут исходить не только от внутренней программы. Является ли это проблемой пользователя? Программирования? Аналитики? Человеческой ошибкой? Метода или это просто глюк, который каким-то образом стал частью программного обеспечения из внешнего источника?

Эти 5-6 пунктов структурированы таким образом, чтобы назвать и связать отношения между событиями, пользователями и проблемами, которые привели к сбою или инциденту.

Как и в других протоколах RCA, этот протокол используется для выяснения и устранения неисправности, которая вызвала конкретную проблему. Это протокол помогает снизить трудозатраты и экономические потери, выявляя первопричину, и таким образом, облегчая «симптомы», которые сигнализировали о проблеме. Это, в свою очередь, помогает предотвратить повторные сбои.

RCA Software

Для анализа и решения проблем имеются различные программы RCA. Эти программы собирают данные и используют их в помощь командам при проведении различных анализов, что способствует эффективному управлению качеством. Данные анализы:

  • Исикава ( диаграмма рыбной кости)

  • Анализ 5-Почему

  • Gap-анализ (анализ разрывов)

  • Анализ изменений

  • Анализ случаев (accident)

  • Анализ причин и последствий отказов (FMEA)

Преимущества софта RCA заключаются в том, что оно может значительно упростить анализ причин, записывая любые и все инциденты и данные анализа причин в одном месте в веб-пространстве, чтобы их можно было совместно использовать в доступном виде.

Примеры софта RCA включают как программу по управлению инцидентами, так и многие средства автоматизации обеспечения качества, которые имеют модули RCA. 

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

Сотрудники могут быть назначены для работы над определенными задачами, чтобы удостовериться, что все исправлено и переделано. Программное обеспечение может помочь уменьшить количество подобных инцидентов, а также снизить затраты и частоту возникновения инцидентов, устранив первопричину.

Выводы

Использование любого из вышеперечисленных инструментов RCA  может обеспечить более качественное тестирование и надежную поддержку QA (обеспечения качества), когда команда сталкивается с «симптомами проблемы» и нуждается в определении первопричин для устранения проблемы.

Все эти инструменты просты в понимании и логичны в том, как они решают различные проблемные ситуации. 

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


Узнать подробнее о курсе «QA Lead».

Смотреть открытый вебинар «Организация процесса тестирования в agile и не agile-командах».

ссылка на оригинал статьи https://habr.com/ru/company/otus/blog/549774/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *