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

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

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

• Ценность тестирования для заинтересованных сторон
• Квантовая теория и теория относительности (не физика)
• Использование правильного языка
• Оценки, бюджеты и переговоры

Давайте же начнем.

Ценность тестирования для заинтересованных сторон

Каждый тест должен иметь ценность для заинтересованных сторон, поскольку он предоставляет доказательства для поддержки принятия их решений по четырем направлениям:

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

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

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

Красота — в глазах смотрящего, а ценность тестирования – в глазах заинтересованной стороны.

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

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

Ценность тестирования измеряется уверенностью заинтересованных сторон, когда они принимают решения.

Приведенные выше постулаты имеют ряд важных последствий.

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

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

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

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

Квантовая теория и теория относительности

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

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

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

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

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

Сравнивать ценность тестов можно, но только в том случае, если они основаны на одной и той же модели.

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

Использование правильного языка

Теперь, когда мы определили, кто отвечает за принятие решения о том, «сколько тестов достаточно», как мы — добросовестные тестировщики — можем поддержать это решение?

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

Если тестировщики будут использовать язык рисков, руководство услышит их.

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

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

Риск-ориентированное тестирование говорит с руководителями на их языке.

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

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

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

Оценки, бюджеты и переговоры

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

Вы немного подумали и пошли разговаривать с руководителем: «Мне нужно шесть тестировщиков на восемь недель».

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

Вы возражаете: «Но это займет больше, чем шесть недель. Это будет стоить больше, чем вы выделили на тестирование этой системы. Система больше, чем в прошлый раз. Она сложнее. Конечно, в этот раз нам слишком рискованно экономить на тестировании. Этого просто недостаточно».

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

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

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

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

Вам необходимо обсудить скоуп.

Переговоры о бюджете на тестирование всегда должны быть связаны с объемом работ (скоупом), а не с усилиями.

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

Скоуп как перечень требований или фичей

Когда оценка сокращается на 30%, задайте себе вопрос: «Какие 30% системы я не должен тестировать?».

Скоуп как инвентаризация рисков

При сокращении сметы на 30% задайте себе вопрос: «Какие риски заинтересованных сторон следует исключить из плана?»

Скоуп как табличная или графическая модель

При сокращении оценки на 30% задайте себе вопрос: «О каких сценариях/элементах я должен сообщить заинтересованным сторонам, что они не будут тестироваться?»

Надеюсь, вы понимаете, о чем идет речь.

1. Скоуп тестирования основывается на некоторой модели, которая предварительно обсуждалась и согласовывалась с заинтересованными сторонами. Этот скоуп является предварительным, зависит от наличия ресурсов и времени, и вы должны поставить заинтересованные стороны в известность об этом.
2. Оценка производится на основе этого предварительного скоупа. Используйте модель (риски, требования, бизнес-процессы или любую другую модель) для установления целевого показателя охвата и подсчета элементов охвата и оценивайте на этой основе.
3. Обсудите это с руководителем проекта. Если оценка слишком высока, используйте приведенные выше ответы, чтобы начать обсуждение с заинтересованными сторонами.

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

Пища для размышлений

Подумайте, кто в ваших проектах берет на себя ответственность за объем проводимого тестирования:

• Вы как тестировщик определяете скоуп и количество тестирования?
• Менеджер проекта определяет бюджет, а вы делаете все возможное в отведенное вам время?
• Обсуждаете ли вы скоуп с менеджером проекта и заинтересованными сторонами, чтобы согласовать баланс между затратами и скоупом выполняемого тестирования?

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

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

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



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