Насколько часто вы сталкиваетесь с проблемами, когда после проведения аудита процесса проверки ПО ваши рекомендации являются достаточно общими и не несут никакой пользы? А еще хуже, когда после внедрения новых технологий, на выходе от них не получаешь требуемого результата, что приводит к возникновению явных сомнений в вашей компетентности со стороны руководителей.
Порой главной проблемой подобных неурядиц является неверное понимание менеджером поставленной высшим руководством задачи, и, как итог, некорректный подбор методики проведения аудита/тестирования программного обеспечения со стороны QA.
Для начала стоит разобрать основы процессов тестирования и понять, как должен строиться каждый процесс. Итак, любой процесс, будь-то проверка ПО или управление качеством, должен выполняться в цикличной форме.
Есть сразу 4 базовых подхода к работе с процессами, но самый известный из них – общепринятый цикл Демминга. Именно на его базе выстраивается работа процесса и другие методологии, например EFQM, IDEAL, DMAIC, говорящие о том, что следует не просто требовать реализации процесса, но и всегда подвергать его анализу и постоянно совершенствовать.
Применительно к тестированию ПО, есть 2 фундаментальных подхода к улучшению процесса проверки, это MBI и ABI.
Model-Based Improvement (MBI)
Являет собой подход к совершенствованию методологии основ тестирования. Основывается на референтных моделях улучшения процесса проверки ПО. Данный подход может быть выраженный в моделях, например TMMi, TPI, либо же в контекстном (STEP, CTP). Подобные модели дают возможность выстраивать процесс тестирования по определенным шагам, тем самым совершенствуя процесс тестирования равномерно и в последовательной форме.
Model-Based Improvement лучше всего использовать только для разрешения задач по оцениванию уровня зрелости процесса проверки ПО и созданию модели развития процесса тестирования на длительные временные промежутки (сроки). Во всех других ситуациях, когда необходимо решить проблему, связанную с оптимизацией тестирования, MBI вам не помощник.
Analytical-Based Improvement (ABI)
Является специальным подходом к совершенствованию основ процесса тестирования, который выстроен на аналитических подходах анализа процесса. Базовое отличие модельного подхода от аналитического в том, что когда тестеры осуществляют анализ процесса по методике MBI, то он происходит сверху вниз. Другими словами, для начала мы изучаем процесс целиком, затем делим его на части, тем самым постепенно погружаясь во все детали процесса.
Аналитический подход выстроен по-другому. А именно, для начала происходит погружение в самые важные детали процесса и уже потом, следуя по намеченному плану, вверх, доходим до разрешения главной проблемы проекта.
Но всего этого недостаточно для проведения полноценного аудита тестирования. И вот тут стоит обратиться к анализу первопричин (Root Cause Analysis).
Анализ первопричин (Root Cause Analysis, RCA)
Итак, Root Cause Analysis – это особый подход для нахождения спрятанных причин, которые помогают определить, почему случился тот или иной баг.
То есть, RCA – это своего рода древовидная иерархическая структура зависимости некоторых причин как с багом, так и между собой.
Классически, к проблемам тестирования, стоит относить лишь те проблемы, которые так или иначе связаны со стандартным треугольником – стоимость/сроки/качество. Почему так? Ответ прост –дело в том, что все процессы в ИТ должен обеспечивать бизнес всей компании.
Сфера ИТ – это современный помощник бизнеса, а значит, когда бизнес говорит, что нет возможности имплементировать все верифицированные фичи, то это проблема не бизнеса, а отдела тестирования.
Традиционно, процедура аудита по критериям RCA состоит сразу из пяти стадий:
- Найти проблему и базовые факторы ее влияния на общепринятые цели;
- Поиск потенциальных причин;
- Нахождение информации и аналитика потенциальных причин;
- Построение причинно-следственных связей;
- Минимизация разнообразных негативных последствий для целей путем поиска самых эффективных решений.
Допустим, мы смогли найти и идентифицировать актуальную проблему, как существенный сдвиг сроков выполнения релиза ПО. Явным признаком наличия проблемы, в данном случае, скорее всего, будет систематичность ее воспроизведения.
Есть разница, если сдвиг сроков происходит один раз за 7 релизов и, если седьмой сдвиг рушит планы по единственному релизу. Второй случай прямо говорит о том, что проблема носит критический характер.
Решить все и сразу не получится, поэтому если возникают проблемы в рабочем процессе, необходимо для начала выбирать самые весомые по мере влияния на продукт и разбираться с ними по-отдельности.
Определив проблему, можно переходить к поиску возможных причин ее возникновения. Наиболее легкий способ – метод мозгового штурма со стороны всех вовлеченных в процесс разработки/тестирования участников проектной команды. Как вариант, можно собрать мнение всех специалистов касательно того, какие на их взгляд причины возникновения дефекта и затем выбрать из данного перечня максимально часто повторяющиеся (и с них начать процесс исправления).
Анализ потенциальных причин возникновения дефектов
На практике есть сразу несколько методик осуществления анализа, например диаграммы зависимостей, аффинная диаграмма и диаграмма Парето.
Методом мозгового штурма можно определить около пяти новых причин возникновения проблемы, влияющих на что-либо (в нашем случае, на сдвиг сроков сдачи запланированного релиза). Теперь задача отдела менеджмента и тестировщиков понять, какие именно причины сильнее всего влияют на анализируемую проблему. Здесь можно применить диаграмму Парето, дабы зафиксировать сумму человеко-дней, которые теряются из-за наступления той или иной проблемы.
Далее следует описать причинно-следственные связи с базовой целью фиксирования коренных причин и их зависимостей. Для этой цели лучше всего использовать диаграмму причинно-следственного анализа. Ее задача состоит в том, что пользователь, идя от проблемы по выстроенной дороге, углубляется на каждом уровне в корень появления причин, тем самым ища базовые катализаторы возникновения проблем. Как итог, разрешив коренную проблему, человек автоматически решает все прочие проблемы.
Для финальной реализации причинно-следственного анализа необходимо отобразить все проблемы в древовидной форме, которые были обнаружены ранее на основе принципа Парето. Далее их следует приоритизировать и установить зависимости.
И финальная стадия — наработка решений проблемы. Выполнив анализ RCA, решения будут логически понятны, но крайне важно, дабы они реально были направлены на конкретную цель и реализовывались всей проектной группой, на которую положено ее выполнение.
Подытоживая всё вышеописанное, стоит отметить следующее. Если вам дали задание по оптимизации процесса тестирования программного обеспечения, но для этого вы должны решить текущие проблемы, связанные с процессом тестирования (ресурсы, время, системное окружение и прочее), вам никак не обойтись без применения ABI и MBI. Ведь именно эти модели дают возможность решать проблемы и существенным образом оптимизировать процессы тестирования и все сопутствующие задачи.
Оставить комментарий