Тестирование — количество тестов

 

 

->

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вам нужно договориться о масштабе.

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

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

Область действия как перечень требований или функций

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

Объем как перечень рисков

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

Объем в виде табличной или графической модели

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

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

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

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

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

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

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

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

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

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