Что такое парадокс пестицида в тестировании
Принципы тестирования — применение, искажения и иллюзии
Эта статья была начата ещё в апреле текущего (2020) года. И с тех пор я её несколько раз переписывал. Я никак не мог достичь того результата, который бы меня устроил. Я не хотел писать очередную статью про 7 принципов тестирования, куда бы просто скопипастились переводы этих принципов из ISTQB, а потом (как в лучших из статей) сопровождались разъяснениями на тему «Что это всё означает». Получилось бы очередное переписывание «священного писания» с его толкованием. Однако, поистине священное писание в толковании не нуждается.
Моя статья будет не про то, что же это за 7 столпов тестирования. Я специально опущу некоторые детали при объяснении принципов. Легким движением руки по клавиатуре вы сможете нагуглить всё это сами. Мы поговорим сразу о боли.
Принципы тестирования — это своеобразная конституция, манифест и договорённости нашей профессии. Но, как и в реальной жизни, как бы чётко ни был написан документ, какими бы благими намерениями не руководствовались авторы, конституцию можно трактовать по-разному, на манифест можно забить, о договорённостях можно забыть.
Вот об этом я бы хотел поговорить в этой статье. О том, как же мы живём с семью принципами тестирования на самом деле.
Это статья-рассуждение. Тут не будет слишком много полезностей, будьте к этому готовы. Скорее призыв к диалогу и попытка поделиться своим опытом и кое-где даже болью. Так что комментарии приветствуются.
Немного о себе, прежде чем начать (эту часть можно пропустить)
Меня зовут Кирилл, я в ИТ с 2009 года, тестированием занимаюсь уже почти 10 лет. Сейчас я работаю на руководящей должности в QA, а так же помогаю в обучении начинающих тестировщиков и параллельно этому всему веду свой телеграм-канал для джуниоров QA (ссылочка будет в конце статьи)
Я не всегда руководствовался в жизни 7ю принципами тестирования. Более того, я не всегда даже знал о них (как и многие тестировщики, я думаю). Но, чем больше сила, тем больше и ответственность, как говаривал дядя Бен. И со временем до меня начал доходить смысл каждого принципа, а после я начал замечать как эти принципы трактуются, искажаются и видоизменяются под тяжестью корпоративных культур каждой отдельной компании.
Собственно семь принципов тестирования
Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие.
Но, коллеги, не забывайте, что иногда бизнес спрашивает «почему этот баг попал на продакшн?». На этот вопрос вы обязаны ответить вполне конкретно. У каждого конкретного бага есть причины появления/пропуска. Но давая ответ на вопрос, так же давайте понять бизнесу, что отсутствие найденных дефектов в процессе тестирования не гарантирует отсутствия ошибок в системе.
Сколь бы скрупулёзным тестирование не было, нельзя учесть все возможные сценарии, а значит и предвидеть все возможные ошибки.
Запомнили принцип выше? Отсутствие багов не гарантирует отсутствие ошибок, кажется, что второй принцип очевидно вытекает из первого, верно?
В мире ограниченных ресурсов и возможностей нужно уметь оценивать риски и расставлять приоритеты. Тестируя, мы снижаем риски. Делая правильный тест-дизайн, мы ещё сильнее снижаем риски. Так и живём.
Это избитая истина, примерно такого же плана, как и «ПО надо тестировать, т.к. писать код без ошибок физически невозможно». Но многим руководителям кажется, что на самом деле тестирование отнимает время релизного цикла, т.к. задерживает доставку фич, а так же тратит время тестировщиков, на то, чтобы они читали «бумажки» вместо того, чтоб тестировать.
Я всю свою жизнь сталкиваюсь с этим удивительным противоречием; парадоксом, если угодно. Менеджеры говорят, что качество ПО превыше всего, недовольные клиенты — недопустимо, если надо тестировать, то мы выделим на это время. Но на деле почти всегда оказывается, что рук не хватает, бюджета нет и «давайте вы сейчас проверите, чтобы катнуть побыстрее, а потом уже будете свои тест-кейсы писать».
Дефекты не размазаны равномерно по приложению, а сконцентрированы в больших количествах в некоторых модулях системы
Для начала хотелось бы заметить, что об этом принципе вообще не вспоминают. Наоборот, найдя пару ошибок в каком-то блоке функционала некоторые тестировщики успокаиваются, мол «ну мы там баги нашли, отлично, пойдем дальше».
Просто помните, если вы уже нашли несколько багов в каком-то модуле, стоит перелопатить его ещё тщательнее, скорее всего там есть ещё скрытые дефекты.
В то же время, отсутствие дефектов в других модулях не говорит, что дефектов там нет (помните первый принцип?)
Это самый распиаренный принцип тестирования. Суть его в том, что если вы долго проводите одни и те же проверки, скорее всего новых багов вы не найдете. Именно поэтому периодически нужно «встряхивать» вашу тестовую базу, ревьюить её новыми сотрудниками и проводить исследовательское тестирование.
Некоторые коллеги во имя избегания этого эффекта «забивают» на классические подходы к тестированию и всё время проводят только исследовательское тестирование. Часто объясняют это тем, что «раз регрессионные прогоны одних и тех же тестов не помогают выявлять новые дефекты, проще полностью отказаться от этого подхода и каждый раз тестировать как на новенького». К сожалению в этом суждении забывается тот факт, что парадокс пестицида говорит лишь о том, что имеющиеся наборы больше не находят новые баги, а не о том, что формальные повторяющиеся из раза в раз проверки вообще не способны находить ошибки.
Об этом я уже как-то упоминал в одной из предыдущих статей. Набор методологий и инструментов, а также подходов и ресурсов для тестирования зависит от того, что именно вы тестируете и на сколько объект тестирования важен
Иногда забывают о том, что каждой задаче своё решение и подход. Очень распространённая тактика, везде использовать старую методологию, если она себя показала хорошо. Однако этот принцип как раз напоминает нам о противоположном.
Зачастую, говоря о контексте, тестировщики рассуждают о внешнем контексте: доменных областях и пользователях (которые не меняются длительное время в рамках одного продукта). Но они забывают внутренний контекст: новые разработчики, больше разработчиков, другие владельцы компании, нагрузка на сотрудников, внутриполитические силы в компании. Этот внутренний контекст и позволяет нам поднимать вопрос о смене методологии и процессов, которые раньше были неуместны.
Тот факт, что тестирование не обнаружило дефектов, ещё не значит, что программа хорошая.
Ну вот снова! Хочется сорвать с себя шапку-ушанку и крикнуть: «Ай, да катись оно всё пропадом», раз никаких гарантий нет, то нафига вообще тестировать!? Ответ прост: чтобы снизить риски. Протестированный продукт с вероятностью 95% bug free, но не протестированный продукт с вероятностью 95% уйдет в продакшн с багами.
Не могу сказать, что я всю свою сознательную QA жизнь только и вижу, как принципы тестирования нарушаются. Нет, ни в коем случае. Я просто подобрал для каждого принципа распространенные случаи игнорирования или иной трактовки. В том или ином виде, объёме, сознательно или нет, но часть принципов соблюдается почти всеми командами, в которых присутствует процесс тестирования ПО. Мне лишь хотелось подсветить некоторые моменты/признаки, по которым чуть легче пустить факт нарушения принципов в своё сознание.
И напоследок вопрос без ответа, который я задаю сам себе (а теперь задам и вам): можно ли поступиться принципами тестирования во имя каких-то благих целей, или принципы тестирования, как семь смертных грехов (ох, вот это аллюзия. только сейчас это понял), являются нерушимой догмой, нарушение которой есть зло?
На просторах интернета я наткнулся ещё на парочку неофициальных доп.принципов, которые мне кажутся более понятными, приземленными и интуитивно полезными:
Про парадокс пестицида
Более 20 лет назад, в 1990 году, Борис Бейзер в свое книге «Software Testing Techniques» ввел понятие, известное как «парадокс пестицида» (pesticide paradox), которое формулируется следующим образом:
Каждый метод, который вы используете, чтобы предотвратить или найти ошибки, оставляет часть ошибок, против которых эти методы уже неэффективны.
На простом языке это означает, что если вы будете часто запускать одни и те же тесты, то со временем они перестанут находить ошибки. В своей книге Бейзер привел следующую аналогию между повторным выполнением тестов и обработкой сельскохозяйственных полей химикатом (в частности, пестицидом), который уже был применен ранее. После первой обработки химикатом большая часть вредителей погибает, однако все же некоторая часть из них выживает, потому что их организм оказался устойчив к яду. Те, кто выжил, с большой вероятностью переживут и последующие обработки пестицидом.
По этой причине тестовые наборы всегда требуют своего обновления, независимо от того, запускаются ли они в автоматическом или ручном режиме.
Существует ряд обстоятельств, по которым хороший тестовый набор со временем утрачивает свою эффективность:
1. Невозможно проверить все возможные сценарии
Даже простые приложения требуют большого количества тестов для проверки всех возможных сценариев и комбинаций данных. Вот почему мы прибегаем к помощи различных принципов, таких как классы эквивалентности или тестирование на основе модели, но все же и этого не достаточно. Большинство команд используют тестирование на основе рисков, создавая подмножество сценариев и наборов данных, а затем используют выявленные ошибки, найденные уже после первого релиза, для улучшения (изменения) своих тестовых сценариев. Это означает, что мы тестируем не все.
2. Функциональность приложения изменяется с течением времени
Каждый раз, когда в продукт вносятся изменения, тестовые сценарии также должны обновляться в соответствии с этими изменениями. Нужно всегда помнить, что любое, даже незначительное изменение, может повлиять на работоспособность всей системы, поэтому важно изменять тесты каждый раз, когда такие изменения происходят.
3. Люди осторожничают только там, где чувствуют непосредственную опасность
Это означает, что разработчики всегда будут проявлять гиперосторожность лишь в тех местах, где ранее тестировщики обнаружили проблемы. Однако там, где раньше было «все ОК», их внимательность снижается на порядок. Т.е. другими словами, разработчики учатся избегать ошибок, которые находятся тестами.
Для того, чтобы преодолеть парадокс пестицида, тестировщики должны постоянно писать новые и различные тесты для покрытия разных частей программы для нахождения как можно большего количества ошибок.
Вот несколько рекомендаций на этот счет:
1. Следите за изменениями в продукте и предугадывайте их возможные последствия
Необходимо приложить определенные усилия для того, чтобы понять, какие места в программе могло затронуть даже совсем небольшое изменение. После этого можно приступить к написанию дополнительных тестов, покрывающих эти изменения.
2. Откажитесь от неэффективных тестов
Бесполезно держать большое количество тестов, которые в итоге не помогают вам. К примеру, если у вас есть 10 тестов, которые покрывают одну и ту же область, и ни один из них за все время так и не нашел ошибок, то вполне целесообразно сократить число таких тестов.
3. Постоянно меняйте тестовые данные
Хоть это и кажется очевидным, но мы порой склонны забывать об этом. Многие ошибки в наших продуктах имеют специфический характер (особенно в автотестах), поэтому мы должны постоянно увеличивать / изменять тестовые данные (к примеру, использовать как можно больше тестовых БД).
4. Используйте неформальные средства тестирования
Используйте по крайней мере один вид неформального тестирования за цикл (или за релиз). Допустим, вы можете прибегнуть к исследовательскому виду тестирования.
7 принципов тестирования. Часть 3
Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.
7 принципов тестирования. Часть 3
В статье использованы материалы книги «Foundations of Software Testing: ISTQB Certification» by Dorothy Graham, Erik van Veenendaal, Isabel Evans & Rex Black.
О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 5. Парадокс пестицидов
[spoiler]
Если повторять те же тесты снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Те скопления дефектов, о которых говорит 4-й принцип, имеют тенденцию перемещаться. Почему так происходит?
Эту аналогию ввел Борис Бейзер в 1983 г. Он привел пример обработки полей пестицидами. Поле обрабатывается неким пестицидом в первый раз, и значительная часть вредителей погибает, но некоторые все же выживают, потому что их организмы оказались устойчивы к действию яда. Если повторно обработать поле тем же пестицидом, то выжившие после первой обработки с большой вероятностью выживут и после второй. Повторное применение тех же тестов и тех же методик приводит к тому, что в продукте остаются именно те дефекты, против которых эти тесты и эти методики неэффективны.
Чтобы преодолеть «парадокс пестицидов», необходимо регулярно пересматривать существующие тест-кейсы и создавать новые, разнообразные тесты, которые будут выполняться на различных частях системы. Это позволит обнаружить больше дефектов.
Принцип 6. Тестирование зависит от контекста
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.
Этот принцип тесно связан с понятием риска. Что такое риск? Риск – это потенциальная проблема. У риска есть вероятность (likelihood) – она всегда выше 0 и ниже 100% – и есть влияние (impact) – те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние. Например, когда мы переходим дорогу, есть некоторая вероятность, что нас собьет машина. Вероятность этого зависит от ряда факторов: насколько интенсивное движение на дороге, есть ли безопасный пешеходный переход, насколько хорошо мы видим, насколько быстро мы можем перейти дорогу. Воздействие зависит от скорости движения машины, от того, есть ли на нас какая-то защитная одежда, от нашего возраста и состояния здоровья и так далее. Исходя из этих факторов, человек выбирает наиболее оптимальную в данном случае стратегию перехода через дорогу.
То же можно сказать и о мире программного обеспечения: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьирует. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
Принцип 7. Заблуждение об отсутствии ошибок
Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.
Заказчики ПО – люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи – на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают.
Верификация – проверка ПО на соответствие требованиям. Валидация – проверка на предмет соответствия потребностям и ожиданиям, на соответствие заданным целям.
Часть тестовых активностей должна быть направлена на верификацию, часть – на валидацию.
Теоретически, если требования были собраны и проанализированы правильно и на этапе разработки архитектуры и кода не вкрались искажения, противоречия быть не должно. Но жизнь, увы, не идеальна.
Принципы Тестирования
Существует 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 принципов тестирования:
Попробуйте пройти тест и узнайте, насколько хорошо вы разобрались.