Добро пожаловать в серию тестов «Лидерство в тестировании» от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы — особенно в Agile командах — преуспеть в своих ролях руководителя тестирования и менеджера по управлению.

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

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

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

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

2. Квантовая теория и теория относительности (не физика)

3. Использование правильных терминов

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

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

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

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

1. Доказательства того, что система будет соответствовать бизнес‑целям проекта.

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

3. Доказательства для воспроизведения и диагностики сбоев, а также фикса и повторного тестирования вышедшей из строя системы.

4. Доказательства в поддержку принятия решений в контексте проекта (принять, обнародовать, отклонить и т. д.).

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

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

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

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

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

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

Вышеприведенные принципы имеют некоторые важные последствия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование правильных терминов 

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

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

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

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

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

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

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

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

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

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

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

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

Вы немного подумаете и пойдете поговорить с боссом.

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

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

«У вас могут быть четыре тестировщика в течение шести недель, и это все».

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

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

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

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

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

Вам нужно согласовать скоуп тестирования. Согласование бюджетов тестирования всегда должно касаться объема, а не усилий.

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

1. Область применения как перечень требований или фич

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

2. Сфера охвата как перечень рисков

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

3. Область применения в виде табличной или графической модели

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

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

• Объем тестирования основан на некоторой модели, которая была предварительно обсуждена и согласована с заинтересованными сторонами. Этот объем является предварительным, при условии наличия ресурсов и времени, и вы должны проинформировать об этом заинтересованные стороны.

• Вы оцениваете на основе этого предварительного объема. Используйте модель (риски, требования, бизнес‑процесс или любую другую модель), чтобы установить целевой показатель покрытия, подсчитать элементы покрытия и произвести оценку на этой основе.

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

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

Немного пищи для размышлений 

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

• Определяете ли вы, как тестировщик, объем тестирования?

• Устанавливает ли руководитель проекта бюджет, и вы делаете все возможное за отведенное вам время?

• Согласовывается ли объем работ с руководителем проекта и заинтересованными сторонами, чтобы согласовать баланс между усилиями и объемом тестирования, которое необходимо выполнить?

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

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

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