Home

Автор: Александр Мешков

Оригинальная публикация

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

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

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

Любой процесс, неважно, разработка это или тестирование, сопровождение, управление качеством и т.д., всегда должен быть цикличен. Существуют 4 основных подхода к работе с процессами, и самый популярный из них, это уже общепризнанный цикл Демминга. Именно на его основе строится работа процесса и все другие методологии, такие как DMAIC (6 сигм), IDEAL, EFQM, которые всегда говорят нам о том, что нужно не только требовать выполнение процесса, но и постоянно его анализировать и непрерывно совершенствовать. Эти модели позволяют нам понять, как мы должны работать с процессом, и самое главное, мы должны всегда видеть проблемы нашего процесса и стараться их решить.

Говоря о тестировании, существуют 2 основополагающих подхода к совершенствованию процесса тестирования, это MBI и ABI.

MBI или Model Based Improvement — подход к совершенствованию процесса тестирования, который основан на референтных моделях совершенствования процесса тестирования. Модели могут быть процесcные, такие как TMMi, TPI и контекстные, такие как STEP или CTP. Эти модели позволяют нам на основе практик строить наш процесс тестирования по конкретным шагам, тем самым развивая процесс тестирования равномерно и последовательно.

Но подходят ли нам такие модели для аудитов уже существующих процессов?

По моей практике скажу, что нет!

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

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

И все это потому, что многие руководители, тест-менеджеры, особенно в России, не понимают различия между аудитом и оценка уровня зрелости процесса тестирования.

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

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

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

Для это существует подход ABI.

ABI или Analytical Based Improvement — это подход к совершенствованию процесса тестирования, который основывается на аналитических подходах  анализа процесса.

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

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

Задайте себе вопрос, как часто к вам приходил ваш руководитель со словами, у нас есть такая проблема в процессе и ее нужно решить? Что выделаете? Вы ищете причину этой проблемы и пытаетесь ее устранить. Но очень часто бывает так, что вроде вы решаете причину, но процесс все равно не работает как надо. И все это потому, что вы выбрали для решения не то узкое место!

Поэтому для проведения аудита процесса тестирования, с целью решения конкретных проблем стоит обратить свое внимание на Root Cause Analysis.

Root Cause Analysis – подход для выявление скрытых (внутренних) причин, которые позволяют определить, почему произошел тот или иной инцидент (проблема).

Таким образом RCA представляет собой древовидную иерархическую структуру зависимости причин, как с проблемой, так и между собой.

Стандартно, к проблемам процесса тестирования, я отношу только те проблемы, которые связаны с классическим треугольником — цена/качество/сроки. Почему это так? Любой процесс ИТ, в том числе и тестирование, должен обеспечивать бизнес организации. ИТ — это помощник бизнеса, поэтому, когда вам бизнес говорит, что они не успевают внедрять все запланированные фичи, продукты, то это не проблема бизнеса (что они генерят много задач), а проблема тестирования. Все остальное, что не связано с этим «треугольником проблем» является причинам возникновения проблем, которые зачастую бывают непонятны и скрываются от нас.

Процесс аудита по RCA состоит из 5 этапов:

1. Определить проблему и ее влияние на общие цели
2. Поиск вероятных причин
3. Сбор информации и анализ вероятных причин
4. Причинно-следственный анализ
5. Предотвращение  или минимизация любых негативных последствий для поставленных целей путем выбора наиболее эффективных решений

Итак, что такое проблема? Проблема — это вопрос или задача, требующая разрешения. Проблемы в нашей работе мы находим постоянно, критичность проблемы мы определяем симптомами, т.е. признаками существования проблемы.

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

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

Следующий и очень важный шаг — это анализ вероятностных причин.

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

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

В результате анализа мы видим, что только первые 2 причины на 60% влияют на сдвиг сроков внедрения, что существенно больше, чем остальные 3 причины суммарно.

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

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

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

Наиболее понятной книгой, рассматривающей модель RCA, я считаю Андерсон Бьерн — «Анализ основной причины. Упрощенные инструменты и методы», в которой на обычных жизненных примерах рассматриваются различные возможности применения модели RCA.

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

Надеюсь было полезно!

Спасибо!

Обсудить в форуме