Оптимизируем процесс тестирования: на какие подходы стоит обратить внимание

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

К слову, ранее я уже рассказывал о своем опыте работы с одной из таких методологий — с моделью зрелости TPI Next (ознакомиться с материалом можно здесь). Статья будет полезна для QA-менеджеров всех уровней. Несмотря на то, что эта методология давно в моем фаворе, существует множество других достойных альтернатив и дополнений. Им я и посвящаю этот лонгрид.

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

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

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

Откуда возникает необходимость в улучшении

Приведу два примера стимулов. Первый — низкий уровень обеспечения качества. Самые распространенные проявления:

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

Второй пример — острая необходимость в повышении уровня качества в рамках высококонкурентной среды. Часто возникает, когда:

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

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

Теперь наши задачи ясны, цели определены — можно двигаться дальше!

Подходы к имплементации изменений

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

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

Одна из самых широко известных методологий в этой категории — цикл Деминга (Deming Cycle, он же цикл PDCA — Plan-Do-Check-Act).

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

Plan. Это время сбора информации, ее анализа и прогнозирования. А также определения целей, составления требований и работы с рисками. На основе всего вышеперечисленного (и многого другого) и должно происходить планирование.

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

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

Act. В этой точке мы принимаем самые важные решения: что оставляем, что требует корректировки, а что и вовсе в топку! Хотелось бы отметить, что здесь важно суметь отказаться от очевидно неудачной идеи. Если изменение не показало ожидаемой эффективности, то стоит либо откорректировать его сейчас (зависит от сложности и очевидности этих корректировок), либо сместить в следующий цикл, либо вообще отказаться. И тут снова плавно начинается планирование...

Еще один рабочий подход — IDEAL, это, по сути, продолжение цикла Деминга, но он еще более фрагментированный.

I — Identify. Идентификация проблемы, нуждающейся в решении.

D — Define. Определение этой проблемы и желаемого результата. Чего мы хотим в результате решения этой проблемы?

E — Explore. Поиски вариантов решения, их анализ и прогнозирование.

A — Act. Выбор метода решения проблемы и его реализация.

L — Look back. Ретроспектива цикла и принятие решения. Если сработало, оставляем. Если нет, снова проходим цикл.

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

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

Не стану описывать всю методологию, так как попросту не смогу. Это тема для отдельной статьи, а то и серии. Ограничимся тремя основными принципами:

• управление рабочим местом;
• устранение неоправданных потерь;
• стандартизация.

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

Модели улучшения процесса тестирования

Наконец-то обсудим то, ради чего мы все тут собрались! Итак, базово существует 4 категории подходов к улучшению:

1. Подходы, основанные на моделях.
2. Аналитические подходы.
3. Подходы, основанные на метриках и индикаторах.
4. Гибридные модели.

Рассмотрим их по порядку.

Оптимизация тестирования на основе модели

Модели улучшения процессов тестирования бывают двух типов:

• Общие модели управления или улучшения, которые затрагивают все сферы разработки ПО и часто состоят из множества узкоспециализированных фреймворков для разных процессных областей. Здесь предусмотрены отдельные протоколы для тестирования, девопсинга, разработки, менеджмента и всего прочего. Как пример, CMMI (Capability Maturity Model Integration), которая затрагивает весь цикл разработки ПО и требует изменений на каждом этапе.
• Узкоспециализированные модели для улучшения тестирования или качества продукта и достижение зрелости командой. Примеры: TMAP, TPI Next, TMMI.

Также добавлю, что все эти модели базируются на одном принципе — достижения ступеней зрелости. Чаще всего их 5: Initial, Managed, Defined, Quantitatively Managed, Optimizing.

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

Подходит, если у вас:

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

Не подходит:

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

Аналитические подходы

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

Fishbone Diagram (Cause and Effect). Название эта практика получила из-за визуального сходства диаграммы с рыбьим скелетом. Построение скелета мы начинаем с черчения прямой линии, которая визуализирует для нас развитие проблемы. Отправная точка — условная инициация процесса, окончание — ошибка, с которой столкнулись. Ответвления от этой линии — процессные области или факторы, влиянию которых был подвержен этот процесс. Затем в рамках каждого такого ответвления мы ищем гипотетическую причину неисправности, после чего дело за малым — соотнести гипотезы с реальностью и проверить на практике.

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

The 5 Whys. Метод крайне прост и элегантен. Отправная точка — точно сформулированная проблема, после чего мы задаемся логическим вопросом — «почему так случилось?». К полученному ответу снова предъявляем тот же вопрос — «почему?». И так до тех пор, пока не найдем исчерпывающий ответ. Обычно на это уходит не более 5 итераций.

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

GQM — Goal/Question/Metric. Здесь мы проводим анализ любой идеи на трех уровнях:

1. Conceptual level (Goal) — этап, на котором важно правильно сформулировать цель или задачу для команды. Она должна максимально четко отображать конечный результат, из формулировки должен быть очевиден профит от достижения цели.
2. Operational level (Question) — ряд операционных вопросов, нацеленных на определение метода и стратегии достижения цели.
3. Quantitative level (Metric) — подбор правильных метрик для того, чтобы ответ на эти вопросы был количественным и измеримым, а не абстрактным. Прежде всего это поможет объективно оценить свои успехи в достижении задачи. Во-вторых, это уже руководство к действию, а не предположения и теории.

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

Улучшения процессов на основе метрик

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

Но есть ряд важных правил:

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

Релевантность. Я бы не рекомендовал увлекаться многообразием метрик. Время все-таки ограничено, и велика вероятность, что вы просто не сможете регулярно снимать много показателей. Ну или будете тратить на это много времени. Абсолютно безрезультатно. Максимальную эффективность метрики показывают тогда, когда они грамотно подобраны. Они должны всесторонне описывать интересующие вас процессы и дополнять друг друга.

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

Напоследок оставлю примеры метрик, часто используемых для оптимизации процесса:

• Defect Detection Percentage (DDP);
• Post-release Defect Rate;
• Organizational Cost of Quality;
• Cost of Quality Ratio;
• Early Defect Detection;
• Relative Test Effort;
• Test Efficiency;
• Automation Level;
• Test Productivity;
• Lead-time Metrics;
• Predictability Metrics;
• Product Quality Metrics.

Гибридный подход к оптимизации

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

Все проекты разные, а следовательно подход к улучшению тестирования и управления в целом не может быть одинаков. Я всегда избегаю генерализации и обобщений. Все ситуации разные, и даже в рамках одного проекта то, что сработало однажды, необязательно выстрелит и во второй раз! Если бы человечеству удалось создать универсальную и исчерпывающую систему улучшений и внедрения изменений (хотя бы только для IT), то эту статью я бы сейчас не писал. Но поскольку такой нет, то давайте действовать креативно и искать решения сами.

Напомню вам о своем самом излюбленном принципе — законе Парето. Он гласит: «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата». Поэтому призываю вас быть рассудительными и не бросаться в оковы перфекционизма. Если вы правильно приоритизируете задачи, грамотно подберете методы их решения и выполните первые 20% работы, то увидите отличные результаты.

Рассмотрим на примере, пусть даже очень образном:

Сеттинг. Вы QA Team Lead, и ваша команда не справляется с объемами задач. Более того, ребята часто допускают ошибки и неточности, что еще сильнее усугубляет ситуацию. Как следствие, ритм работы вашего отдела крайне стрессовый, и ситуация только усугубляется. Все работники заняты реактивным разгребанием «срочняков» и своих критических ошибок.

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

Модель позволит вам оценить положение вещей и определить, на каком уровне зрелости находится команда. И, скорее всего, это будет первый уровень (или в некоторых моделях — нулевой). Она также подскажет, чего вам не хватает для достижения следующего уровня. Но ответа на вопрос «как этого достичь?» вы толком и не получите.

Но вот что мы получим, если будем действовать всесторонне и последовательно:

1. Для начала введем ряд практик, помогающих быстро и эффективно искать причины ошибок и устранять их. Например, Root Cause Analysis. Обнаружим для себя черные дыры, куда утекает ресурс, и составим список улучшений, которые нужны в срочном порядке.
2. Для внедрения этих изменений выберем, допустим, цикл Деминга. И постараемся небольшими итерациями эти нововведения имплементировать в рабочий процесс. Цикл за циклом, освободив весомое количество свободного ресурса и подкрепив свой дух чередой побед, команда начнет показывать хороший перфоманс. По мере создания более комфортных рабочих условий и своевременного реагирования на возникновение ошибок команда станет сплоченнее, эффективнее и более зрелой! А там, где возникает зрелость, есть место и для проактивности.
3. А где есть проактивность, возможно внедрение моделей зрелости (например, TPI Next) или же следование философии Кайдзен. Хорошо поставленные процессы требуют все меньше внимания, поэтому вы сможете все больше времени уделять интересным активностям, обучению и развитию.

Выводы

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

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

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