какое количество тестирования можно считать достаточным
Какое количество тестирования можно считать достаточным
Что пишут в блогах
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Introduction
Разделы портала
Про инструменты
Автор: Майкл Болтон
Перевод: Дмитрий Дудников по заказу Software-Testing.RU
Несколько лет назад, примерно в то же время, когда я начал проводить тренинг «Быстрое тестирование ПО» (Rapid Software Testing), мой соавтор Джеймс Бах (James Bach) записал видео для демонстрации быстрого стресс-тестирования. В его примере подход заключался в подаче на вход визарда приложения огромного объема данных, по существу заставляя приложение нагружать само себя.
Видео длится почти шесть минут. Примерно на середине Джеймс спрашивает: «Вы можете поинтересоваться, почему я не хочу остановиться сейчас. Причина в том, что мы наблюдаем неуклонное ухудшение ситуации. Мы могли бы остановиться сейчас, но возможно мы увидим нечто худшее, если будем продолжать». Таким образом, он продолжил тест. А вскоре после этого Джеймс предложил эвристики для остановки: мы останавливаемся, когда: 1) мы обнаружили достаточно серьезную проблему, или 2) в поведении программы нет явных изменений – программа в целом работает стабильно, или 3) ценность от продолжения теста не оправдывает стоимость. Таковы были эвристики для остановки того теста.
Где-то через год после того, как я впервые увидел это видео, я решил более полно описать эвристики для прекращения тестирования в колонке для журнала «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), в которой тестировщик сам отказывается от продолжения тестирования. Подробнее читайте здесь.
Про Тестинг
Ручное, автоматизированное, нагрузочное тестирование программного обеспечения
Процессы разработки ПО
вторник, 29 января 2008 г.
Необходимые и достаточные условия для проведения тестирования
Некоторое время назад пришлось составить список программного обеспечения и артефактов необходимых тестировщику в повседневной работе, и параллельно с этим в голову пришел один замечательный вопрос: «Необходимые и достаточные условия для проведения тестирования». Казалось бы, что ответ прост, да не так прост, как кажется. Попытался найти правду на форуме тестировщиков – получилась замечательная дискуссия. Общего ответа выработать не удалось, но вот поразмыслить и выработать свое решение этой задачки вполне получилось.
В своей недавней статье «Обеспечение качества. Контроль качества. Тестирование» я предложил, выработанное по результатам опроса, определение понятия тестирования программного обеспечения:
Software Testing (тестирование ПО) является одной из техник контроля качества и включает в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
Решив продолжить свою теорию, хочу предложить вашему вниманию исследование на тему «необходимые и достаточные условия для проведения тестирования».
Перейдем к определению достаточных условий.
Так как не каждое действие, совершенное над программой, с целью получения ожидаемое поведения, является тестированием, встал вопрос о том, что сама по себе цель, а именно: тестирование, является одним из достаточных условий. Принимая за основу то, что наличие плана тестирования прямо указывает на намерение проведения тестирования, получаем, что тест план является одним из достаточных условий.
При проведении тестирования, человек или машина должны будут выполнять какие-то действия для проверки реального и ожидаемого поведения программы. Значит, наличие тест кейсов/тестов также является достаточным условием.
Итого мы имеем следующие необходимые и достаточные условия для проведения тестирования:
В ходе формулирования условий и проведенной дискуссии на форуме, было получено, что набор необходимых и достаточных условий зависим от выбранной методологии или процесса, так как наличие некоторых артефактов на определенных стадиях тестирования является обязательным.
Конечно предложенные мной условия всего навсего являются попыткой их определения, и вполне возможно содержат ошибки, но все же: «На ошибках учатся». А лично я стремлюсь к познанию истины. Так как она где-то рядом.
Буду весьма благодарен, получить комментарии по поводу проделанной мной работы и теории в целом.
Какое количество тестирования можно считать достаточным
Что пишут в блогах
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Introduction
Разделы портала
Про инструменты
Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова
Классический вопрос, который задают про тест-стратегию – это «А сколько тестирования достаточно?» Если вы тестируете исключительно по тест-кейсам или через автоматизацию, то ответ кажется очевидным – проделано достаточно тестирования, когда у вас закончились тесты. Однако этот ответ недостоин мыслящего тестировщика. Мыслящий тестировщик задает вопрос так, чтобы он затрагивал миссию тестирования, а не только кнопочки, которые нажимаются в процессе. Всех уже существующих тест-процедур может быть недостаточно для осуществления миссии… или же они могут быть избыточными.
Наша миссия не в том, чтобы выполнять определенный набор действий. Для большинства из нас миссия в том, чтобы узнать о продукте достаточно важной информации, чтобы наши клиенты (в основном разработчики и менеджеры) могли принимать информированные решения.
Тестирование как рассказ
Тестируя, вы делаете нечто похожее на проведение журналистского расследования. Это история о том, что вы знаете о продукте, том, почему вы считаете, что знаете это, и том, какие последствия это знание несет для проекта. Все, что вы делаете в тестировании, или входит в эту историю, или помогает вам расширить ее. Вы проделали достаточно тестирования, когда вы можете рассказать убедительную историю о продукте, которая достаточно затрагивает вещи, значимые для ваших клиентов. Так как ваша убедительная история – это фактически предсказание, как продукт оценят пользователи, то другой способ это сформулировать – это сказать, что ваше тестирование завершено, если вы полагаете, что отчет о тестировании будет справедлив и спустя месяцы – поэтому попытайтесь написать нетленку.
К примеру, я как-то раз тестировал процесс установки сложного продукта. Моей миссией было оценить и каталогизировать все изменения, которые продукт проводил в системах, где устанавливался. Моим первым шагом был анализ процесса установки. Затем я создал его диаграмму, определил, как тестировать его важные части, и нашел способы делать это при разумно контролируемых условиях. Я пришел к выводу о продукте, который логически вытекал из тестирования, а затем проверил этот вывод, чтобы убедиться, что каждая его часть была доказана и поддержана проведенными тестами. Мне было нужно, чтобы мой отчет был хорошей, убедительной историей, поэтому я попытался представить, как моя аудитория может его раскритиковать. Где моя история слабовата? Как она может оказаться ложной? Я провел дополнительные тесты, чтобы исключить альтернативные гипотезы. Я прогнал тесты неоднократно, чтобы повысить уверенность в том, что полученные результаты были связаны с контролируемыми мной процессами и переменными, а не со случайными событиями.
Когда я исчерпал возможности своего внутреннего критика (и внешних критиков, которых просил проверить мою работу), я решил, что моя история достаточно хороша.
Короткая история может быть такой же законченной, как и роман.
Отличное тестирование – это потенциально бесконечный процесс. Если полнота тестирования означает, что вы должны прогнать все возможные тесты, вы никогда не закончите. Однако вы можете сказать, что у вас все, когда у вас есть тест-история, содержащая все основные повороты сюжета, и вы можете обосновать, что дополнительные тесты, скорее всего, не повлияют на нее значительным образом. Вот в чем штука: вы, конечно, никогда не можете быть уверены, что достигли этой точки уменьшающейся выгоды, однако вам и не нужно знать это наверняка! Все, что вам нужно, все, что от вас могут ожидать – это убедительная история о том, почему мыслящий и ответственный тестировщик – вроде вас – пришел к выводу, что вы достаточно знаете о тестируемом продукте. В некоторых ситуациях это займет месяцы, а в некоторых – всего лишь несколько часов.
Возможно, вы не знаете, сколько тестирования еще понадобится, потому что вы в середине процесса. Элли, тебе придется пройти дорогу из желтого кирпича до конца, прежде чем щелкнуть каблучками и вернуться домой.
Сюжетные линии тест-истории
Полная тест-история отвечает на следующие вопросы: Каков статус продукта (бага, и т. д.)? Как вы это узнали (тест-стратегия, включая информацию о тест-покрытии и оракулах)? Насколько хорошим было тестирование?
Тестирование зачастую развивается сложным образом. В нем бывают фальстарты. Я отчитываюсь о багах, которые оказываются не багами. Я исследую автоматизацию, которая может пригодиться. Я пытаюсь заполучить нужные тест-окружения, и иногда мне это удается лишь частично. Я разрабатываю богатые тестовые данные. Настоящее тестирование – сложная история, и мне нужны способы его упрощать. Один из них – использование сессионного тест-менеджмента, или тест-менеджмента через цепочки. Другой способ – не рассказывать историю целиком. Тут нужно быть осторожным – если я скрываю детали своего тестирования, другим людям может показаться, что тестирование – плевое дело.
Один из способов упрощения тест-истории, который применяется множеством тестировщиков – это прятки среди тест-кейсов. Их история выглядит как «я написал тест-кейсы, я прогнал тест-кейсы. Кейсы прошли». У этой истории нет содержания. Она слишком общая, и, как я считаю, скучна и безответственна. Вы можете больше! Поговорите о том, что значат эти кейсы. Что они покрывают? Какие риски вы исследуете с их помощью?
Концепция тест-истории – это не только отчетность. Она также помогает вам управлять собой. Она помогает решать, когда нужно остановиться. И поэтому в мире Rapid Software Testing тест-история и занимает центральное место.
Когда следует завершить тестирование?
Начало — половина дела. Это правило приложимо практически к любой сфере деятельности, и даже к тестированию ПО.
Зачастую в начале проекта тестировщики излучают энтузиазм, составляя документацию (стратегия тестирования, план тестирования или тест-кейсы).
Но в дальнейшем нередко возникают сложности. По завершении первого раунда тестирования, тестировщики обычно находят кучу багов, а затем подходят ко второму этапу несколько расслабленными. Имеет место т.н. человеческий фактор и общечеловеческая тенденция, когда становится скучно выполнять повторные операции.
В подобных ситуациях у многих возникает ощущение того, что они делают монотонную работу, и, как следствие, теряется интерес к продолжению тестирования уже знакомого ПО. И во время третьего, примерно, раунда над тестировщиком неумолимо нависает вопрос: «Когда же все-таки нужно прекращать тестирование?»
Каждый тестировщик хотя бы раз задавался таким вопросом, расширенная версия которого выглядела бы так:
«Когда, на каком этапе и как прекращать тестирование?»
Многие тестировщики полагают, что не существует каких-то особых условий, указывающих на то, что тестирование следует завершить. Но чтобы ответить на этот вопрос, придется проанализировать тестовую активность от начала до конца.
Допустим, стоит задача протестировать новый проект.
Тестирование, раунд #1)
Команда тестировщиков приступает к тестированию, как только ей передают только что созданный программный продукт.
На этапе тестирования тестировщики выполняют различные сценарии, пытаясь взломать ПО и обнаружить дефекты. (Поскольку приложение новое и проходит оценку впервые, показатель обнаруженных дефектов будет сравнительно высоким).
Разработчики устраняют дефекты и возвращают разработку тестировщикам для повторного теста.
Тестировщики проводят проводят проверку на предмет наличия дефектов, затем переходят к регрессионному тестированию.
Как только серьезные дефекты устранены и ПО демонстрирует стабильную работу, команда разработчиков выпускает следующую версию.
Тестирование, раунд #2)
Тестировщики начинает второй раунд тестирования и повторяют то, что выполнялось во время первого раунда.
Во время этого процесса, как правило, обнаруживаются еще некоторые дефекты.
Дефекты устраняются разработчиками и приложение вновь отправляется на проверку.
Тестировщики проводят повторные тесты и регрессионное тестирование тех частей разработки, которые не претерпели изменения.
Это можно продолжать до бесконечности. Раунд 3, 4, 5… до тех пор, пока программное обеспечение совершенно не очистится от багов.
Графически этот процесс можно изобразить следующим образом:
Но представляется ли теоретически возможным найти абсолютно все дефекты? Это вопрос на миллион долларов, но попробуем на него ответить.
Большинство приложений устроены сложно, оттого фронт их тестирования достаточно большой. Не то чтобы обнаружить абсолютно все дефекты совсем невозможно, но для этого понадобится вечность.
Даже после того, как большинство багов в ПО найдены, никто не сможет с уверенностью заявить, что приложение стало безупречным.
Более того, такая задача не стоит. Цель тестирование ПО — убедиться, что оно функционально и работает так, как запланировано. Достигается это за счет попыток взлома или поиска отклонений от ожидаемого поведения.
У приложений может быть бесконечное множество дефектов, и проводить тестирование ПО до полного их устранения непрактично. Никогда не знаешь, какой из багов окажется последним.
А если «прекращение тестирования, после полного устранения дефектов» теперь не является критерием, тогда из чего же следует исходить?
Попытаемся разобраться, какие факторы следует считать наиболее важными?
Решение о прекращении тестирования обычно зависит от времени (которое есть в распоряжении), бюджета и необходимой продолжительности тестирования.
Чаще всего решение завершить тестирование принимается, когда закончилось время/бюджет, или же когда все тестовые сценарии выполнены. Но это компромиссное решение, которое может быть в ущерб качеству.
Допустим, необходимо протестировать программный модуль, на эту работу выделен определенный бюджет. Время: 1 месяц. Общее количество тестовых сценариев: 200.
Первая неделя: Вы добились успеха — в первый же день нашли дефект Show Stopper. Но тестирование остановилось на 3 дня. Проверять другие сценарии вы не можете, пока не будет устранен обнаружившийся баг. Потеряв время, вы вновь приступаете к работе.
К концу недели проверено 20 сценариев и найдено еще несколько опасных багов.
Неделя 2: Вы начинаете тестирование, тщательно выискиваете дефекты. За вторую неделю находите несколько багов 1-го, 2-го и 3-го уровня критичности. За это время удалось проверить 70 сценариев.
Неделя 3: К началу третьей недели все дефекты с высоким приоритетом устранены, но теперь к выполнению текущих сценариев добавляется еще и перепроверка ранее обнаруженных багов. За третью неделю вы охватили 120 сценариев, и нашли еще несколько багов. Теперь остается искать только дефекты третьего порядка.
Неделя 4: К началу четвертой недели необходимо перепроверить дефекты и 80 оставшихся сценариев. К концу недели вы проверили 180 сценариев; все дефекты с высоким приоритетом были устранены и протестированы повторно.
Данные о проведенном тестировании помещаются в таблицу:
Может этого уже достаточно?
Время, отведенное на тестирование, истекло. Вы нашли и устранили ряд дефектов первого уровня. Если на этом остановиться, можно ли будет считать разработанное ПО надежным? Не совсем, в силу некоторых причин:
Неделя 1: Вы находите дефект первого уровня в первый день тестирования. И тестирование откладывается на 3 дня. Потеряв три дня, вы вновь приступаете к работе.
К концу недели проверено 20 сценариев, найдено еще несколько опасных дефектов.
Результаты первой недели аналогичны примеру #1.
Неделя 2: За вторую неделю вы находите несколько багов 1-го, 2-го и 3-го уровня критичности. Но теперь задача — охватить как можно больше сценариев. Как итог, 120 сценариев к концу недели.
Неделя 3: К началу третьей недели все приоритетные дефекты устранены, и теперь, помимо текущих сценариев, необходимо перепроверить ранее обнаруженные дефекты. За третью неделю вы охватили 200 сценариев, и нашли еще ряд багов.
Теперь вы может сообщить только о дефектах второго и третьего уровня.
Данные о проведенном тестировании:
Этого достаточно?
Вы охватили полностью все сценарии тестирования, нашли еще несколько дефектов. Если на этом остановиться, можно ли будет считать ПО надежным?
Как можно видеть, оба сценария не гарантируют качества. Лучше всего в такой ситуации попытаться найти золотую середину, использовать такой подход, который бы учитывал все лучшие особенности из первого и второго сценариев. Для этого понадобится определить ряд критериев.
Критерии завершения или выхода
Критерий выхода позволяет установить, какой объем тестирования следует считать достаточным. Определяется он по завершении цикла тестирования и включается в план. Это набор условий или активностей, которые должны быть выполнены, чтобы тестирование можно было назвать законченным.
Что включает в себя критерий выхода?
В идеале это комбинация нескольких факторов, уникальных для всех проектов. Все зависит от требований конкретного проекта. Поэтому во время планирования целесообразнее подсчитать как можно больше параметров.
Ниже приведены некоторые нюансы, которые стоит учитывать во время функционального или системного тестирования. Вы можете составить определенную комбинацию или же использовать все эти факторы, чтобы определить, когда именно следует завершить тестирование.
Тестирование может быть завершено когда:
Охват теста:
(Общее число успешных текст-кейсов / общее число тест-кейсов ) * 100.
Сроки:
Срок, отведенный на тестирование, истек.
Документация по тестированию:
Вся документация по тестированию, подлежащая сдаче (например, отчет о тестировании), подготовлена, проверена и передана.
Бюджет:
И в заключение, пожалуйста, ответьте на несколько вопросов
Если большинство ответов окажутся утвердительными, это будет означать, что вы можете завершить тестирование. Если большинство ответов будут отрицательными, тогда придется искать, что было упущено.