Когда следует завершить тестирование?

Начало — половина дела. Это правило приложимо практически к любой сфере деятельности, и даже к тестированию ПО.

Зачастую в начале проекта тестировщики излучают энтузиазм, составляя документацию (стратегия тестирования, план тестирования или тест-кейсы).

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

В подобных ситуациях у многих возникает ощущение того, что они делают монотонную работу, и, как следствие, теряется интерес к продолжению тестирования уже знакомого ПО. И во время третьего, примерно, раунда над тестировщиком неумолимо нависает вопрос: «Когда же все-таки нужно прекращать тестирование?»

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

«Когда, на каком этапе и как прекращать тестирование?»

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

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

Начальные действия:

• Команда тестировщиков получает требования.
• Затем следует планирование и разработка.
• Подготавливается и проверяется документация по тестированию.

Тестирование, раунд #1)       

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

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

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

Тестировщики проводят проводят проверку на предмет наличия дефектов, затем переходят к регрессионному тестированию.

Как только серьезные дефекты устранены и ПО демонстрирует стабильную работу, команда разработчиков выпускает следующую версию.

Тестирование, раунд  #2)

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

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

Дефекты устраняются разработчиками и приложение вновь отправляется на проверку.

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

Это можно продолжать до бесконечности. Раунд 3, 4, 5… до тех пор, пока программное обеспечение совершенно не очистится от багов.

Графически этот процесс можно изобразить следующим образом:

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

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

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

Более того, такая задача не стоит. Цель тестирование ПО — убедиться, что оно функционально и работает так, как запланировано. Достигается это за счет попыток взлома или поиска отклонений от ожидаемого поведения.

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

А если «прекращение тестирования, после полного устранения дефектов» теперь не является критерием, тогда из чего же следует исходить?

Попытаемся разобраться, какие факторы следует считать наиболее важными?

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

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

Пример

Сценарий тестирования:

Допустим, необходимо протестировать программный модуль, на эту работу выделен определенный бюджет. Время: 1 месяц. Общее количество тестовых сценариев: 200.

Сценарий #1)      

Первая неделя: Вы добились успеха — в первый же день нашли дефект Show Stopper. Но тестирование остановилось на 3 дня. Проверять другие сценарии вы не можете, пока не будет устранен обнаружившийся баг. Потеряв время, вы вновь приступаете к работе.

К концу недели проверено 20 сценариев и найдено еще несколько опасных багов.

Неделя 2: Вы начинаете тестирование, тщательно выискиваете дефекты. За вторую неделю находите несколько багов 1-го, 2-го и 3-го уровня критичности. За это время удалось проверить 70 сценариев.

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

Неделя 4: К началу четвертой недели необходимо перепроверить дефекты и 80 оставшихся сценариев. К концу недели вы проверили 180 сценариев; все дефекты с высоким приоритетом были устранены и протестированы повторно.

Данные о проведенном тестировании помещаются  в таблицу:

Может этого уже достаточно?

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

• Сценарии проверены не все.
• Несколько потенциально опасных дефектов не тестировались ни разу.
• Все проверенные сценарии тестировались только раз.
• У ПО все еще есть дефекты.
• Регрессионное тестирование не проводилось.

Сценарий #2)    

Неделя 1: Вы находите дефект первого уровня в первый день тестирования. И тестирование откладывается на 3 дня. Потеряв три дня, вы вновь приступаете к работе.

К концу недели проверено 20 сценариев, найдено еще несколько опасных дефектов.

Результаты первой недели аналогичны примеру #1.

Неделя 2: За вторую неделю вы находите несколько багов 1-го, 2-го и 3-го уровня критичности. Но теперь задача — охватить как можно больше сценариев. Как итог, 120 сценариев к концу недели.

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

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

Данные о проведенном тестировании:

Этого достаточно?

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

Не совсем:

• Все сценарии проверялись лишь по разу.
• У ПО все еще есть дефекты.
• Регрессионное тестирование не проводилось.

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

Критерии завершения или выхода

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

Что включает в себя критерий выхода?

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

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

Тестирование может быть завершено когда:

• Все 100% требований учтены.
• Дефекты установлены/ожидаемое число дефектов обнаружено.
• Все дефекты, относящиеся к классу Show Stopper или Blocker, устранены, ни у одного из критических дефектов нет статуса «открытый».
• Все дефекты с высоким приоритетом идентифицированы и исправлены.
• Defect Rate (скорость дефектообразования) ниже установленного допустимого уровня.
• Очень небольшое число дефектов среднего уровня критичности «открыты», их разбор проведен.
• Число «открытых» дефектов среднего уровня, которые не влияют на пользование системой, очень небольшое.
• Все дефекты с высоким уровнем приоритета закрыты и соответствующие регрессивные сценарии успешно проведены.

Охват теста:

• Охват теста должен быть на уровне 95%.
• Pass Rate текст-кейса также должен быть 95%. Для расчета этого процентного соотношения применяется формула:

(Общее число успешных текст-кейсов / общее число тест-кейсов ) * 100.

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

Сроки:

Срок, отведенный на тестирование, истек.

Документация по тестированию:

Вся документация по тестированию, подлежащая сдаче (например, отчет о тестировании), подготовлена, проверена и передана.

Бюджет:

• Бюджет, выделенный на тестирование, полностью израсходован.
• Совещания в формате «Go / No Go» проведены, решение о релизе продукта принято.

И в заключение, пожалуйста, ответьте на несколько вопросов

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

• Были ли все тест-кейсы проверены по меньшей мере один раз?
• Установлен ли показатель успешности тест-кейса (Test Case Pass)?
• Достигнут ли полный охват тестирования?
• Все функциональные/бизнес «потоки» проверены как минимум раз?
• Найдено ли установленное число дефектов?
• Устранены и «закрыты» ли все дефекты с высоким приоритетом?
• Все ли дефекты прошли повторную проверку и считаются «закрытыми»?
• Регрессивное тестирование проведено для всех «открытых» дефектов?
• Закончился ли выделенный на тестирование бюджет?
• Истекли ли сроки проведения тестирования?
• Вся ли документация по тестированию проверена и опубликована?