Когда прекращать тестирование программ

Несколько лет назад, примерно в то же время, когда я начал проводить тренинг «Быстрое тестирование ПО» (Rapid Software Testing), мой соавтор Джеймс Бах (James Bach) записал видео для демонстрации быстрого стресс-тестирования. В его примере подход заключался в подаче на вход визарда приложения огромного объема данных, по существу заставляя приложение нагружать само себя.

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

А вскоре после этого Джеймс предложил эвристики для остановки: мы останавливаемся, когда: 1) мы обнаружили достаточно серьезную проблему, или 2) в поведении программы нет явных изменений – программа в целом работает стабильно, или 3) ценность от продолжения теста не оправдывает стоимость. Таковы были эвристики для остановки того теста.

Повторное тестирование (Re-testing или Confirmation testing) | Курс тестирование — Урок 17 | QA Labs

Где-то через год после того, как я впервые увидел это видео, я решил более полно описать эвристики для прекращения тестирования в колонке для журнала «Better Software». По этому поводу мы с Джеймсом устроили транспективную беседу. Колонку вы можете найти здесь. Ещё год спустя колонка превратилась в неформальную лекцию, которую я прочитал в нескольких местах.

Примерно через шесть месяцев после этого мы оба нашли еще больше эвристик для остановки тестирования. Мы обсуждали их на STAR East 2009, и проходившие в тот момент мимо нас Дэйл Эмери (Dale Emery) и Джеймс Линдсей (James Lyndsay) присоединились к дискуссии. В частности, Дэйл высказал предположение, что во время сражения стрельба может быть остановлена в нескольких случаях: временное затишье, поступление команды «прекратить огонь», соглашение между сторонами о прекращении огня, отход сторон на начальные позиции, разоружение противника. Это показалось мне интересным.

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

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

1. Эвристика «Время вышло!». Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда заканчивается выделенное на него время.

Получили ли мы информацию, которую нам требуется знать о продукте? Не слишком ли высок риск прекращения тестирования? Не был ли срок искусственным, произвольным? Будет ли выполняться дополнительная разработка, которая потребует дополнительного тестирования?

Из тестировщика в разработчики. Почему так делать не стоит?

2. Эвристика пиньяты (The Piñata Heuristic). Мы прекращаем ломать программу, когда начинают выпадать конфеты – мы останавливаем тестирование, когда видим первую достаточно серьезную проблему.

Не застряло ли в ноге пиньяты еще несколько конфет? Является ли первая серьезная проблема самой важной? Единственной, о которой стоит беспокоиться? Не найдем ли мы другие интересные проблемы, если продолжим тестирование? Что если наше ощущение «серьезности» ошибочно и проблема не столь грандиозна?

3. Эвристика «мертвой лошади» (The Dead Horse Heuristic). В программе слишком много ошибок, так что продолжение тестирования не имеет смысла. Мы знаем, что все изменится настолько, что сведет на нет результаты текущего тестирования.

Здесь мы предполагаем, что уже найдено много интересного и важного. Если мы сейчас остановимся, не пропустим ли мы что-то еще более важное или более интересное?

4. Эвристика «Задание выполнено» (The Mission Accomplished Heuristic). Мы останавливаем тестирование, когда найдены ответы на все поставленные вопросы.

В процессе нашего тестирования могут возникнуть новые вопросы. Это приводит нас к эвристике Рамсфелда (Rumsfeld Heuristic): «Есть то, про что мы знаем, что мы это не знаем, и есть то, про что мы не знаем, что мы этого не знаем». Достаточно ли неизвестных переместило наше тестирование в область известного? Обнаружило ли наше тестирование новые неизвестные? И сложный для разбора, но важный вопрос: удовлетворены ли мы тем, что мы переместили достаточно неизвестных неизвестных в область известного или по крайней мере сделали их известными неизвестными.

5. Эвристика «Отмена задания» (The Mission Revoked Heuristic). Наш клиент сказал нам: «пожалуйста, прекратите тестирование». Это может произойти по причине перерасхода бюджета, или вследствие отмены проекта, и по любой другой причине. Какова бы ни была причина, нам поручили остановить тестирование. (На самом деле эвристика «Время вышло!» может быть частным случаем более общей «Отмены задания», в том случае, если предпочтительнее, чтобы не мы сами, а заказчик принял решение о том, что время вышло.)

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

6. Эвристика «Я зашел в тупик!» (The I Feel Stuck! Heuristic). По какой бы то ни было причине мы останавливаемся, поскольку обнаруживаем некое препятствие. У нас нет информации, которая нам требуется (например, многие люди заявляют, что не могут тестировать без достаточного количества спецификаций). Имеется блокирующая ошибка, и таким образом мы не можем перейти в ту область продукта, которую необходимо протестировать, у нас нет необходимого оборудования или инструментария, у команды нет квалификации, требуемой для выполнения некоторых специальных тестов.

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

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

7. Эвристика «освежающей паузы» (The Pause That Refreshes Heuristic). Вместо прекращения тестирования мы приостанавливаем его на некоторое время. Мы можем остановить тестирование и сделать перерыв, когда мы устали, когда нам стало скучно или пропало вдохновение. Мы можем сделать паузу на то, чтобы выполнить некоторые исследования, разработать планы, поразмыслить над тем, что мы делали в прошлом и понять, что делать дальше. Идея заключается в том, что нам требуется определенный перерыв, после которого мы сможем вернуться к продукту со свежим взглядом или свежими мыслями.

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

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

Является ли функция с «более высоким приоритетом» действительно более приоритетной? Готова ли она к тестированию? Не протестировали ли мы ее и так уже достаточно?

8. Эвристика «Отсутствие продвижения» (The Flatline Heuristic). Что бы мы ни делали, мы получаем тот же самый результат. Это может происходить в случае, когда программа падает определенным способом или перестает отвечать, но также мы можем не продвигаться, когда программа в основном ведет себя стабильно: «выглядит хорошо!»

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

9. Эвристика Привычного завершения (The Customary Conclusion Heuristic). Мы останавливаем тестирование тогда, когда мы обычно останавливаем тестирование.

Имеется протокол, задающий определенное количество идей для тестирования, или тест-кейсов, или циклов тестирования, или как вариант – имеется определенный объем работ по тестированию, который мы выполняем и после этого останавливаемся. Agile-команды, например, часто применяют такой подход: «когда выполнены все приемочные тесты, мы знаем, что продукт готов к поставке». Эвальд Руденриджс (Ewald Roodenrijs) приводит в своем блоге пример этой эвристики в статье «Когда прекращать тестирование». Он говорит, что он останавливается, «когда выполнено определенное количество тестовых циклов, включая регрессионное тестирование».

Отличие от эвристики «Время вышло!» в том, что временные ограничения могут изменяться более гибко, чем некоторые другие. Поскольку в большинстве проектов главенствует именно график проекта, и у меня и у Джеймса заняло некоторое время осознание того, что эта эвристика также очень распространена. Иногда мы можем слышать фразы типа «один тест на требование» или «один положительный и один отрицательный тест на требование», в качестве соглашения для определения «достаточно хорошего» тестирования. (Конечно же, мы не согласны с этим, но мы слышим это).

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

10. Больше нет интересных вопросов (No more interesting questions). В этот момент мы решаем, что не осталось вопросов, ответы на которые были бы достаточно ценными, чтобы оправдать стоимость продолжения тестирования, и поэтому мы останавливаемся. Эта эвристика используется в основном как дополнение к другим эвристикам, помогая принять решение о том, есть ли какие-то вопросы или риски, которые отменяют действие этих эвристик (примеры таких вопросов я привожу после каждой эвристики). Кроме того, если одна эвристика советует нам прекратить тестирование, следует проверить, нет ли интересных вопросов или серьезных рисков в других областях, и если они есть, то мы скорее продолжим тестирование, чем остановимся.

Что мы думаем о наших моделях рисков? Нет ли опасности недооценки или наоборот переоценки риска, не случилось ли так, что мы не заметили Чёрного лебедя (а может быть даже Белого лебедя)? Достигли ли мы достаточного покрытия? Достаточно ли тщательно мы проверили свои оракулы?

11. Эвристика уклонения/безразличия (The Avoidance/Indifference Heuristic). Иногда людей не интересует дополнительная информация, либо они не хотят знать, что происходит в программе. Тестируемое приложение может быть первой версией, которую, как мы знаем, скоро заменят. Некоторые люди прекращают тестирование по причине лени, злого умысла или отсутствия мотивации. Иногда бизнес-критичность выпуска нового релиза настолько высока, что никакая мыслимая проблема не остановит выход программы, и поэтому никакие новые результаты тестирования не будут иметь значения.

Если это безразлично нам сейчас, то почему мы вообще тестировали? У нас сменились приоритеты? Если кто-то закончил работу, то почему? Иногда компанию меньше беспокоит незнание о существовании проблемы, чем знание и отсутствие действий по ее устранению – не может ли это быть нашим случаем?

Дополнение: Кем Канер (Cem Kaner) предложил еще одну эвристику: «Отказ от выполнения задания» (Mission Rejected), в которой тестировщик сам отказывается от продолжения тестирования. Подробнее читайте здесь.

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

Источник: www.software-testing.ru

Критерии выхода, завершения тестирования (Exit criteria). Когда остановиться тестировать?

Критерии завершения тестирования это один из часто задаваемых вопросов на собеседованиях на должность тестровщика ПО. Давайте разберем какие же основные факторы влияют на принятие решения о завершении тестирования тестировщиком.

Часто новички в тестировании отвечают на данный вопрос — буду тестировать пока не найду все баги 🙂
А возможно ли это? Нет конечно, никто не может гарантировать отсутствие багов, даже если это приложение было протестировано несколькими опытными тестировщиками. Исчерпывающие тестирование невозможно и об этом гласит один из принципов тестирования

Следует выделить 3 основных критерия для остановки, завершения тестирования:

• Время
• Бюджет
• Все тест кейсы пройдены, найденные баги исправлены и перепроверены

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

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

3) Все тест кейсы пройдены, найденные баги исправлены и перепроверены — Для того чтобы протестировать приложение, тестировщик для начала должен ознакомиться с требованиями, функциональными спецификациями к приложению, если они конечно есть, или узнать со слов заказчика какое поведение должно быть при разных сценариях использования приложения или фитчи. Затем заняться составлением тестовой документации — написанием тест кейсов, написать тест план если нужно, покрывая весь функционал и требования к приложению. Также обсудить и решить в команде или самостоятельно не требуется ли проводить нефункциональное тестирование, такое как нагрузочное тестирование (Performance and Load Testing), тестирование удобства пользовавия (Usability Testing) и т.д. Так как у каждого приложения есть «узкие места», на которые следует обратить внимание при тестировании. Далее начать выполнять, проходить тест кейсы и в момент, когда все тест кейсы пройдены и найденные баги исправлены и перепроверены, можно завершать тестирование.

• IevgeniiKucherenko
• 11 октября 2016, 02:43
• 1

Здравствуйте, а подскажите, пожалуйста, когда определяются критерии выхода, на каком этапе ЖЦ тестирования?
На этапе Test Planing? И кто их утверждает?

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

Источник: software-testing.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

• Первый день – обнаружен дефект Show Stopper.
• Тестирование остановилось до устранения опасного дефекта.
• Дефект устранен на четвертый день.
• Тестирование продолжилось.

• Обнаружены критические ошибки.
• Проверены 20 сценариев.

• Особое внимание к дефектам.
• Выполнение оставшихся сценариев тестирования.
• Повторное тестирование на предмет наличия дефектов.

• Обнаружены еще несколько дефектов 1, 2 и 3 уровня.
• Общее количество завершенных тестов 70.

• Перепроверка и поиск основных дефектов.
• Выполнение оставшихся сценариев.
• Осталось найти дефекты третьего уровня критичности.

• Обнаружено несколько дефектов 1, 2 и 3 уровня.
• Проверены 120 сценариев.

• Повторное тестирование дефектов высокого и среднего уровня.
• Выполнение тестовых сценариев.

• Обнаружены несколько дефектов 3 уровня.
• Общее число проверенных сценариев 180.

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

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

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

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

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

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

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

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

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

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

• Первый день – обнаружен дефект Show Stopper.
• Тестирование остановилось до устранения опасного дефекта.
• Дефект устранен на четвертый день.
• Тестирование продолжилось до конца первой недели.

• Обнаружены критические ошибки.
• Проверены 20 сценариев.

• Основной акцент на количестве сценариев, дабы наверстать упущенное время.
• Повторное тестирование устраненных дефектов.

• Обнаружены еще несколько дефектов 1, 2 и 3 уровня.
• Общее количество завершенных тестов 70.

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

• Обнаружено несколько дефектов 1, 2 и 3 уровня.
• Проверены все сценарии.

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

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

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

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

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

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

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

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

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

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

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

Охват теста:

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

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

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

Сроки:

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

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

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

Бюджет:

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

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

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

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

Источник: getbug.ru