Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

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

Как руководители, мы часто должны отвечать прямо, линейно, исчислимо. Именно это, как правило, и нужно задающим вопросы – простой, удобоваримый кусок информации, на основе которого принимаются сложные бизнес-решения. Бизнес ожидает ответов вроде «Нам осталось выполнить 500 кейсов из 10000», «в среднем мы выполняем 50 кейсов в день, то есть дней 10», и «мы на 95% готовы».

Опытные люди, однако, знают, что эти ответы не всегда дают нужную информацию. Минусы соблазна «просто сказать им число»:

• Числа легко истолковать неверно.
• Числа не показывают всей картины.
• Они одномерны.
• Они отражают устаревшие данные.

Эффективный способ решить эту проблему – воспользоваться метрикой, разработанной одним из нас (это был Мас Коно). Он называет ее тест-пойнтами. По сути это взвешенный замер запуска планируемых кейсов.

Что руководителям на самом деле нужно?

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

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

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

Как правило, о предрелизном тестировании руководители хотят знать следующее:

• Выпускаться можем?
• Если нет, то насколько мы к этому близки?
• А если поедем сегодня, чем рискуем?
• Что будем делать, если случится что-то плохое?

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

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

Происхождение тест-пойнтов

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

Масу она не нравилась – он знал, что без поддержки контекста эта метрика не имеет особого смысла. Она не отражает ни трудозатраты тестировщиков, ни трудозатраты разработчиков. К тому же она ничего не говорит о характере работы, которую еще не выполнили.

Мас терпеть не мог отчитываться об этой метрике, но был обязан делать это – ничего другого для руководства не придумали.

Позднее в ходе разработки Маса вновь попросили отчитаться о прогрессе тестирования; у него не было выхода, кроме как сообщить, что оно на 80% завершено. Руководители решили выпускать продукт; они готовы были рисковать непротестированными 20%, чтобы продукт вышел на рынок.

Однако тут крылась огромная проблема: оставшиеся 20% тестов были наиболее важными для новой функциональности, а код этой функциональности еще не был внедрен.

Мас объяснил руководству ситуацию; естественно, их не обрадовало, что метрика не отражает реальность. Более того, они прочитали ему нотацию, почему именно число «80%» - плохая метрика, хотя он и без них это знал. Он был настолько раздражен, что придумал новую метрику.

Срок годности тест-кейсов

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

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

В торговле продуктами говорят, что у продукта есть «срок годности»; продукт превышает его, как только эта дата прошла.

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

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

Смысл тест-пойнтов

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

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

Между тест-пойнтами и стори-пойнтами есть два важных различия.

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

Как работают тест-пойнты

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

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

• Функциональная область (продажи, мессенджер, управление профилем)
• Тип покрытия («счастливый путь», негативное, граничное)
• Сложность (низкая, средняя, высокая)
• Усилия (мало, средне, много).

Код вашего продукта меняется со временем, поэтому некоторые атрибуты кейсов тоже могут измениться; это «активные атрибуты». Ниже – ряд примеров:

• Категория (новая фича, смоук, регресс)
• Приоритет (критический, высокий, средний, низкий)
• Важность для релиза (критическая, высокая, средняя, низкая)
• Частота запуска (после каждого билда, после каждого деплоя).

Значению каждого атрибута присваиваются очки. Чтобы определить, сколько тест-пойнтов приходится на один кейс, нужно просуммировать очки всех атрибутов; чтобы определить общее количество тест-пойнтов для набора тестов (например, регрессионного), нужно просуммировать пойнты всех кейсов в нем.

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

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

Как распределяются очки атрибутов

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

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

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

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

Вот пример

Представьте себе онлайн-магазин. Возможность сделать заказ, оплатив его банковской картой – это кейс высокого приоритета; он будет выполняться как минимум раз за релиз, и, возможно, при каждом деплое на препрод.

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

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

Чтобы понять, как в этом случае могут быть распределены тест-пойнты, присвоим значения атрибутам.

Теперь рассмотрим два тест-кейса и очки каждого атрибута для первого релиза, в котором появится возможность переписки с покупателем:

Тест-кейс 1. Оформление заказа с оплатой картой

Тест-кейс 2. Отправка сообщения покупателю.

Как можно видеть по общему количеству очков, при первом релизе сообщений кейс 2 набрал почти столько же тест-пойнтов, сколько кейс по оформлению заказа с оплатой картой (кейс 1). Тестирование новой функциональности практически так же важно, как тестирование основной.

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

«Отправка сообщений» перестала быть новой опцией, но все еще считается достаточно важной для тестирования; это немного изменит активные атрибуты кейса 2 – характеристику, приоритет и важность для релиза.

Изменение этих атрибутов приведет к изменениям общего количества очков. Таблица ниже отражает эти изменения.

Тест-кейс 2. Отправка сообщения покупателю.

Заметьте, что теперь кейс 2 набрал значительно меньше очков, чем кейс 1, что отражает новую, относительную позицию кейса 2 в плане критической важности тест-кейсов. Иными словами, важность кейса 2 для грядущего релиза ниже, чем у кейса 1. Логично этого ожидать – покупки всегда будут важнее для бизнеса, чем переписка.

Как использовать очки для информирования о статусе

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

Три вещи можно определить, просто взглянув на диаграмму выгорания тест-пойнтов:

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

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

Изображение 1. Идеальная диаграмма выгорания

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

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

Изображение 2. Неидеальная диаграмма выгорания

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

Изображение 3. Обычная диаграмма выгорания

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

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

Почему это работает

Частично этот подход работает, потому что выдаваемые им метрики не основаны на сравнении сущностей (то есть кейсов), которые несравнимы как по необходимым усилиям, так и по значимости работы.

Итак, что бы случилось с Масом, если бы он использовал тест-пойнты в начале двухтысячных? Когда его спрашивали о том, сколько процентов завершено, он дал бы более понятный ответ – например, «готово на 50%»; этот процент основан на завершенных тест-пойнтах, а не кейсах, и число дает более реалистичные представления об оставшемся объеме работ. Такая метрика информирует дальнейшие разговоры о содержании оставшихся задач.

Тест-пойнты не применимы в одиночку

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

Тест-пойнты – это инструмент. Это не метрика. Это способ помочь получить применимую информацию в понятной аудитории форме, но их недостаточно, чтобы рассказать обо всех актуальных аспектах тестирования.

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

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

Именно так и работают тест-пойнты – это дополнительный контекст, сжатый до одного-единственного числа. А для бизнеса контекст – все.

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