в каком случае тестирование может доказать отсутствие дефектов
Принципы тестирования
Тестирование программного обеспечения – креативная и интеллектуальная работа. Разработка правильных и эффективных тестов – достаточно непростое занятие. Принципы тестирования, представленные ниже, были разработаны в последние 40 лет и являются общим руководством для тестирования в целом.
1. Тестирование показывает наличие дефектов
Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Тем не менее, важно составлять тест-кейсы, которые будут находить как можно больше багов. Таким образом, при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в программном обеспечении. В то же время, даже если дефекты не были найдены в процессе тестирования, нельзя утверждать, что их нет.
2. Исчерпывающее тестирование невозможно
Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключениям совсем уж примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО.
3. Раннее тестирование
Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения и его усилия должны быть сконцентрированы на определенных целях.
4. Скопление дефектов
Разные модули системы могут содержать разное количество дефектов, то есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.
5. Парадокс пестицида
Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают.
Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов.
6. Тестирование зависит от контекста
Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицинских нужд требует гораздо более строгой и тщательной проверки, чем, скажем, компьютерная игра. Из тех же соображений сайт с большой посещаемостью должен пройти через серьезное тестирование производительности, чтобы показать возможность работы в условиях высокой нагрузки.
7. Заблуждение об отсутствии ошибок.
Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа готова к релизу. Нахождение и исправление дефектов будет не важным, если система окажется неудобной в использовании и не будет удовлетворять ожиданиям и потребностям пользователя.
И еще несколько важных принципов:
7 принципов тестирования. Часть 1
Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.
7 принципов тестирования. Часть 1
В статье использованы материалы книги «Foundations of Software Testing: ISTQB Certification» by Dorothy Graham, Erik van Veenendaal, Isabel Evans & Rex Black.
О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
[spoiler]
Принцип 1. Тестирование показывает наличие дефектов
Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов нет.
Доказать, что чего-то нет, в принципе затруднительно. Сколько бы белых лебедей мы ни видели, это еще не служит основанием утверждать, что «все лебеди белые». Но если мы увидим хотя бы одного черного лебедя, мы может сказать, что «не все лебеди белые».
Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку. Но если мы нашли хотя бы один дефект, мы уже можем утверждать, что в данном ПО присутствуют дефекты.
Впрочем, это отнюдь не означает, что тестирование бесполезно и не может повысить наш уровень уверенности в качестве ПО. Тестирование уменьшает вероятность необнаруженных дефектов, которые остаются в ПО, но всегда нужно помнить, что даже если дефекты не найдены, это еще не доказательство того, что их нет.
Принцип 2. Исчерпывающее тестирование невозможно
Этот принцип связан с вопросом: «сколько нужно тестировать?».
Какие вообще могут быть ответы на этот вопрос? Мы можем протестировать всё, ничего не тестировать или протестировать какую-то часть. Идеальным вариантом выглядит «протестировать всё», но стоит разобраться, должны ли мы и можем ли вообще это сделать.
Сколько тестов нужно выполнить, чтобы полностью протестировать поле ввода, принимающее одну цифру? Зависит от того, что мы понимаем под словом «полностью». Есть 10 возможных валидных значений, но, кроме того, надо еще убедиться, что невалидные значения правильно обрабатываются. 26 заглавных латинских букв, 26 строчных букв, не менее 6 знаков пунктуации и пробел… Уже 68, а это мы еще не вспомнили о кириллице, спецсимволах и тому подобном.
Если мы посмотрим на более реалистичный пример, то всё ещё хуже. На практике, системы обычно имеют более одного поля ввода и поля эти имеют разный размер. А еще есть различные окружения, на которых нужно выполнить тесты… Если мы возьмем для примера один скрин, на котором 15 полей ввода, каждое из которых принимает 5 значений, то чтобы протестировать все валидные комбинации ввода, нам понадобится 30 517 578 125 (5 в 15-й степени) тестов. Очень маловероятно, что это уложится во временные рамки вашего проекта.
Помните сказку о волшебном горшочке с кашей, который наварил ее столько, что залил целый город? Так вот, наш «горшочек» может варить очень-очень долго, почти бесконечно, и когда-то нам надо сказать: «Стоп! Горшочек, не вари!».
Используя технику классов эквивалентности, мы можем сократить число наших тестов, ведь тестирование нашего поля ввода, принимающего одну цифру, при помощи значений 2, 3, 4 не дает нам больше информации, чем если бы мы протестировали только со значением 3.
Объем тестирования в реальной жизни ограничен временными рамками и бюджетом, в то же время существует необходимость поставить техническое решение, которое отвечает требованиям заказчика. Заказчики и руководители проекта хотят возврата инвестиций (ROI) от времени, потраченного на тестирование (время – деньги). Например, предотвратить появление ошибок после релиза – исправлять их всегда дорого. Но полное тестирование они просто не могут себе позволить – даже если очень хочется…
Вместо попыток «протестировать всё» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта. При определении, какой объем тестирования достаточен, необходимо учитывать уровень риска, включая технические риски и риски, связанные с бизнесом, и такие ограничения проекта как время и бюджет. Оценка и управление рисками – одна из наиболее важных активностей в любом проекте. Это позволяет варьировать трудозатраты на тестирование, основываясь на уровне риска в различных областях.
Кроме того, тестирование должно обеспечивать необходимую информацию, чтобы заинтересованные лица могли принимать информированные решения о релизе продукта или передаче заказчикам.
Семь главных принципов тестирования
Собрали 7 базовых принципов тестирования, которые должен знать каждый QA.
Бэкграунд
Как определить, что вы применяете правильную стратегию тестирования? Нужно не отклоняться от базовых принципов тестирования.
Мы собрали 7 принципов тестирования, широко практикуемых в индустрии.
Чтобы понять это нагляднее, представьте сценарий, при котором вы перемещаете файл из папки А в папку В.
Кроме стандартных, неошибочных сценариев поведения, какие тест-кейсы тут можно набросать?
Или представьте, что есть 15 полей ввода, каждое имеет по 5 возможных значений, таким образом количество возможных комбинаций равно 5 в 15-й степени.
Протестировать все комбинации — невозможно, это будет огромное превышение времени и затраты на тестирование вырастут экспоненциально. Нам нужны принципы и стратегии оптимизации усилий тестирования.
Вот 7 принципов правильного тестирования
1. Все протестировать невозможно
Да, это невозможно. Вместо этого, требуется оптимальное тестирование, на основании оценки рисков.
Важнейший вопрос — как оценить эти риски?
Для этого нужно сделать мысленное упражнение: представьте, что вы тестируете операционную систему. Задайте себе вопрос: по своему опыту, какая операция, скорее всего, «положит» операционку? Уверен, ответ будет приблизительно такой: «открыть 10 приложений одновременно».
Итак, если вы тестируете операционную систему, то ошибки, скорее всего, будут сосредоточены «где-то в области многозадачности». И они должны быть протестированы тщательно. Что приводит к следующему принципу: классификация дефектов
2. Классификация дефектов
Классификация дефектов — принцип, который предполагает, что небольшое количество модулей содержат в себе большинство багов. Это яркий пример применения в тестировании принципа Парето: 80% проблем таятся в 20% модулей.
Имея опыт, можно легко определить эти проблемные модули. Но в этом подходе свои проблемы.
Если те же тесты повторяются снова и снова, то «почти одинаковые» тест-кейсы не смогут помочь найти больше ошибок.
3. Парадокс пестицида
Повторное применение одного и того же пестицида для истребления насекомых со временем приведет к выработке у насекомых устойчивости к этому пестициду. То же касается и тестирования софта. Если есть некий набор повторяемых тестов, он будет бесполезен в определении новых дефектов.
Чтобы решить эту проблему, тест-кейсы должны регулярно просматриваться и обновляться, должны добавляться новые тест-кейсы, ориентированные на другую функциональность или тестирующие уже существующую под другим углом.
Тестировщики не могут всегда зависеть от уже существующих тест-кейсов. Они должны постоянно развиваться, улучшая существующие тест-кейсы. Но даже так, делая все добросовестно, никогда нельзя дать гарантий, что багов в продукте нет. На презентации Windows 98, которую, между прочим, проводил сам Билл Гейтс, система «упала».
Казалось бы, такая корпорация как Microsoft, уж точно протестировала свою операционку вдоль и поперек, и не могла рисковать своей репутацией, но нет, операционка упала, презентация была почти что сорвана.
4. Тестирование показывает наличие дефектов
Принцип: тестирование говорит нам о наличии багов, но ничего не говорит об отсутствии багов. То есть, тестирование снижает вероятность существования необнаруженных дефектов остающихся в софте, но даже если ни один дефект не найден, это не есть доказательство полной корректности кода.
Но что, если вы делаете работу добросовестно, соблюдаете все требования и делаете свой продукт на 99,99% свободным от багов и он все равно не соответствует требованиям клиента?
Это подводит нас к следующему принципу: отсутствие ошибок может лишь казаться.
5. Отсутствие ошибок может быть обманчивым
Бывает, что софт, на 99% свободен от ошибок — тем не менее он не удовлетворяет требованиям. Это может быть в случае, если система тестировалась тщательно, но прописанные требования были некорректными. Тестирование софта — это не только поиск багов. Это еще и проверка, отвечает ли софт бизнес-требованиям. Этот принцип говорит о том, что поиск и устранение багов не поможет, если построенная система изначально неправильно построена и не соответствует требованиям клиента.
Для решения этой проблемы, следующий принцип: раннее тестирование.
6. Раннее тестирование
Тестирование должно начинаться как можно раньше в жизненном цикле разработки. И любые баги, еще на этапе сбора требований, или на этапе дизайна, будут отловлены заблаговременно. И да, намного дешевле исправить дефект на ранних стадиях разработки. Но как рано должно начинаться тестирование? Рекомендуется начинать поиск с момента, когда описаны требования.
7. Тестирование зависит от контекста
Тестирование зависит от контекста; это значит, что способ, которым вы тестируете сайт для e-commerce, будет отличаться от способа тестирования мобильного приложения. Софт бывает самый разный и подход к его тестированию тоже бывает самый разный. Необходимо применять разные подходы, методологии, техники и типы тестирования в зависимости от приложения. Тестирование POS-системы в ритейле отличается от тестирования АТМ-банкомата.
Миф: принципы — только для справки. На практике они не применяются.
Это неправда. Знание этих принципов тестирования помогает создавать правильную стратегию тестирования, и писать правильные тест-кейсы для отлавливания ошибок.
Научиться применять эти принципы — как научиться водить автомобиль.
Сначала, пока учишься водить, обращаешь внимание на переключение передач, на скорость, сцепление и т.п. С опытом, просто фокусируешься на вождении, все остальное делается на автомате.
Так же с принципами тестирования. Опытные тестировщики знают эти принципы в совершенстве и применяют их не задумываясь.
Принципы Тестирования
Существует 7 принципов тестирования:
Именно принципы тестирования являются основой всех стандартов, книг, методов и техник тестирования.
Их понимание является фундаментом знаний тестировщика и позволяет работать быстрее, качественнее и эффективнее.
В статье подробно рассказываю и объясняю принципы тестирования программного обеспечения. В конце вы сможете пройти тест и увидеть как хорошо вы разобрались.
Начнем с определения понятия “принцип”.
Принцип или основа, начало, первоначало (лат. principium, греч. αρχή, дословно первейшее) — постулат, утверждение, на основе которого создают научные теории и законы, юридические документы, выбирают нормы поведения в обществе.
Исходя из этого определения, мы можем сказать, что:
Принципы тестирования — это основы тестирования
Их нельзя изменить, отменить, понимать “частично” или поверхностно.
Они всегда были, есть и будут, и без их понимания тестировщик никогда не станет высокооплачиваемым профессионалом.
1️⃣ Тестирование демонстрирует наличие дефектов, а не их отсутствие
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет.
Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, тестирование не доказывает корректность работы ПО.
Для лучшего понимания, разобьем первый принцип на 2 части:
и посмотрим на каждую из них в отдельности.
Тестирование может показать, что дефекты присутствуют
Предположим, у нас есть сайт, который нужно проверить перед передачей заказчику.
Мы проводим тестирование и находим 20 багов.
В этом случае тестирование показало, что в изначальном варианте сайта было 20 дефектов.
Дальше, мы исправляем все ошибки и после следующего тестирования не находим ни одного бага. О чем это говорит?
Повторное тестирования показало, что мы исправили 20 багов и не нашли новых.
Это факт — мы нашли и исправили 20 дефектов в ПО.
Тестирование не может доказать, что дефектов нет
Предположим, что принцип не правильный.
Q: Тестирование МОЖЕТ доказать, что дефектов нет — что для этого необходимо?
A: Как минимум, знать все “места”, где находятся все дефекты, чтоб тестировщик смог их проверить после исправления ошибки.
Q: А можем ли мы каким-то образом узнать о всех “местах”?
A: Короткий ответ — нет!
Для нахождения всех дефектов нужно будет проделать очень большой объем работы:
И знаете что самое интересное?
Для ДОКАЗАТЕЛЬСТВА, что дефектов нет — эту проверку нужно будет делать КАЖДЫЙ раз после ЛЮБОЙ правки, внесенной в сайт, после ЛЮБОГО обновления ЛЮБОГО браузера, после выхода на рынок ЛЮБОГО телефона, часов, нового экрана и т.д. и т.п.
А учитывая количество и скорость изменений “систем”, окружающих сайт — нужно будет проводить десятки тысяч сложнейших тестов ежедневно, чтоб доказать, что дефектов нет, и надеяться, что вы учли все…
Именно из-за ОГРОМНОЙ сложности и ОБЪЕМА всей системы, в которой создается и работает сайт, мы не можем узнать ОБЩЕЕ КОЛИЧЕСТВО дефектов.
А не зная общего количества дефектов — мы никогда не докажем, что их нет.
Тестирование демонстрирует наличие дефектов, но не доказывает их отсутствие.
2️⃣ Исчерпывающее тестирование недостижимо
Рост количества тестов в процессе анализа задачи
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо (за исключением тривиальных случаев).
Вместо попытки исчерпывающего тестирования должны использоваться анализ рисков, методы тестирования и расстановка приоритетов, что бы сосредоточить усилия по тестированию.
Предположим, у нас есть сайт.
На сайте есть форма, в которой есть поле для ввода возраста.
Q: Какое общее количество комбинаций вводов существует для этого поля?
A: ∞
Если это поле — без ограничений и валидации — мы можем писать туда что угодно: числа, символы, буквы любого алфавита, emoji 😇, да еще и текст любой длины.
Если предположить, что максимальная длина строки для этого поля должна быть 3 символа (вряд-ли кто-то живет больше 999 лет), то максимальное количество всех возможных комбинаций (учитывая, что UTF-8 поддерживает 2,164,864 доступных символов) будет равно:
Х = 2,164,864³ =10 145 929 857 329 004 544
Можете представить, сколько комбинаций будет у поля для ввода текста с ограничением по длине в 10,000 символов 😅
Именно для упрощения таких ситуаций существует тест-анализ, анализ рисков и приоритезация проверок, которые позволяют сократить количество тестов к минимуму не ухудшая качество продукта.
3️⃣ Раннее тестирование сохраняет время и деньги
Для нахождения дефектов на ранних стадиях разработки, статические и динамические активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения.
Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения.
Для простоты примера можно рассмотреть процесс исправления дефекта, найденного в требованиях к ПО и дефекта, найденного клиентом.
Дефект, найденный в требованиях к ПО — исправляется очень быстро.
Теперь посчитаем стоимость исправления этого же дефекта, найденного клиентом.
Во первых, мы оцениваем стоимость технического исправления командой разработки.
Дальше, мы оцениваем “ущерб” от потерь репутации.
Числа, приведенные в примерах — сильно “обобщенные”. Компании HP и IBM делали исследования на эту тему, их результаты можно посмотреть здесь:
Если очень приблизительно, то стоимость исправления ошибки в зависимости от этапа разработки следующая:
4️⃣ Кластеризация дефектов
Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во время тестирования перед выпуском и отвечает за большинство эксплуатационных отказов.
Предсказанные кластеры дефектов и фактические наблюдаемые кластеры дефектов в ходе тестирования или эксплуатации являются важными входными данными для анализа риска, используемого для сосредоточения усилий по тестированию.
Код пишут люди. Люди ошибаются. Одни — ошибаются чаще, чем другие и это не исправить.
То же самое применимо и к системам. Одни — проще, другие — сложнее. Чем сложнее система— тем больше вероятность возникновения ошибки и так будет всегда.
Добавим сюда дедлайны. Чем ближе к дедлайну — тем больше нагрузка. Чем больше нагрузка — тем меньше времени разработчик уделяет “красоте” кода и перепроверке самого себя. Отсюда тоже берутся ошибки.
Все эти факторы приводят к одним и тем же последствиям — дефекты “собираются” в “кучки” в определенных частях системы.
Любой тестировщик, который занимался тестированием в команде разработки с более чем одним разработчиком на протяжении длительного отрезка времени “чувствует” это.
Он знает, что за Васей нужно проверять по 2 раза, а Саша — все делает хорошо, в большинстве случаев.
Также, он знает, что баги на сайте А — возникают очень редко, так как его делает команда опытных разработчиков. А вот с сайтом Б — не все так гладко, потому что там разработчики менее опытные.
Свойство дефектов к “группированию” нужно учитывать при планировании тестирования.
Это поможет вам, как тестировщику, лучше оптимизировать время на тестирование и помогать там, где это действительно необходимо.
5️⃣ Парадокс пестицида
Automation Test Run #428421 — ALL PASSED!
Если одни и те же тесты будут выполняться снова и снова, в конечном счете они перестанут находить новые дефекты.
Для обнаружения новых дефектов может потребоваться изменение существующих тестов / тестовых данных или написание новых.
Предположим, у нас есть набор тестов, которые проверяют некий функционал, в котором есть 3 дефекта.
Пройдя тесты, мы находим 2 дефекта и исправляем их, а один дефект останется “незамеченным”.
Проходя одни и те же тесты снова и снова — мы всегда будем видеть одну и ту же картину: PASS / Пройдено.
Но, по факту, один дефект будет оставаться в системе и текущие тесты НИКАК не смогут его найти.
Для определения дефекта придется:
Чаще всего парадокс пестицида проявляется в автоматизированном тестировании изменений (регрессионном тестировании).
Постоянно “зеленые” тесты создают иллюзию “все работает”, но, как мы уже знаем, на самом деле они перестают находить новые ошибки, а ошибки со временем начинают накапливаться…
Именно поэтому ручное тестирование НИКОГДА не исчезнет 🥳😎
Название принципа происходит от “эффекта пестицида”, так как пестициды через некоторое время больше не эффективны при борьбе с вредителями (как и тесты — с нахождением новых дефектов).
*я пытался найти информацию об этом “эффекте” в Google — и ничего не нашел 🙂 Не Fake ли это. (Если у кого-то есть ссылка на описание этого эффекта в природе — поделитесь, пожалуйста, в комментариях)
6️⃣ Тестирование зависит от контекста
Тестирование выполняется по-разному в зависимости от контекста.
Например, программное обеспечение управления производством, в котором критически важна безопасность, тестируется иначе, чем мобильное приложение электронной коммерции.
Предположим, нам нужно проверить простой сайт, который состоит из 5 страниц.
Вы пишете некий простой чек-лист (функционала нет, тест-кейсы не нужны, не тратим время) и проверяете сайт.
Все супер, залили, ничего критического нет, вы молодец! 🥳🥳🥳
Дальше, вам отдают на проверку другой сайт.
Но в этот раз не из 5, а из 45,000 страниц, с сложным функционалом, админками и т.д. и т.п.
Надеюсь, что вы ответили — нет на оба вопроса! 😍
Тестирование всегда зависит от контекста!
Поэтому, перед тем как начинать что-то проверять, нужно сделать анализ и продумать стратегию и план тестирования.
И только после этого приступать к написанию тестовой документации и тестированию!
7️⃣ Заблуждение об отсутствии ошибок
Некоторые организации ожидают, что тестировщики смогут выполнить все возможные тесты и найти все возможные дефекты, но принципы 2 и 1, соответственно, говорят нам, что это невозможно.
Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех системе.
Например, тщательное тестирование всех указанных требований и исправление всех обнаруженных дефектов может привести к созданию системы, которая будет трудной в использовании, не будет соответствовать потребностям и ожиданиям пользователей или будет хуже по сравнению с другими конкурирующими системами.
Сейчас мы уже знаем, что все ошибки найти невозможно, исходя из принципа 1 и 2. Ошибки есть всегда. Они были и будут, вы с этим ничего не сделаете и это нормально.
Важно не отсутствие ошибок, а критичность, скорость реакции и исправления!
Более того, не все ошибки нужно исправлять!
Почитайте про Zero Bug Policy, лучший процесс работы с багами, по моему мнению.
Резюме
В статье мы подробно рассмотрели 7 принципов тестирования:
Попробуйте пройти тест и узнайте, насколько хорошо вы разобрались.