Принципы Тестирования

21 июня, 2021

Существует 7 принципов тестирования:

  1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
  2. Исчерпывающее тестирование недостижимо
  3. Раннее тестирование сохраняет время и деньги
  4. Кластеризация дефектов
  5. Парадокс пестицида
  6. Тестирование зависит от контекста
  7. Заблуждение об отсутствии ошибок

Именно принципы тестирования являются основой всех стандартов, книг, методов и техник тестирования.

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


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


Начнем с определения понятия “принцип”.

Принцип или основа, начало, первоначало (лат. principium, греч. αρχή, дословно первейшее) — постулат, утверждение, на основе которого создают научные теории и законы, юридические документы, выбирают нормы поведения в обществе.


Исходя из этого определения, мы можем сказать, что:

Принципы тестирования — это основы тестирования

Их нельзя изменить, отменить, понимать “частично” или поверхностно.

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

Давайте разбираться! 🧐


1️⃣ Тестирование демонстрирует наличие дефектов, а не их отсутствие

Дефекты найдены!

Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет.

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


Для лучшего понимания, разобьем первый принцип на 2 части:

  1. Тестирование может показать, что дефекты присутствуют
  2. Тестирование не может доказать, что дефектов нет

и посмотрим на каждую из них в отдельности.

Тестирование может показать, что дефекты присутствуют

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

Мы проводим тестирование и находим 20 багов.

В этом случае тестирование показало, что в изначальном варианте сайта было 20 дефектов.

Дальше, мы исправляем все ошибки и после следующего тестирования не находим ни одного бага. О чем это говорит?

Повторное тестирования показало, что мы исправили 20 багов и не нашли новых.

Это факт — мы нашли и исправили 20 дефектов в ПО.

Тестирование не может доказать, что дефектов нет

Предположим, что принцип не правильный.

Q: Тестирование МОЖЕТ доказать, что дефектов нет — что для этого необходимо?
A: Как минимум, знать все “места”, где находятся все дефекты, чтоб тестировщик смог их проверить после исправления ошибки.

Q: А можем ли мы каким-то образом узнать о всех “местах”?
A: Короткий ответ — нет!

Для нахождения всех дефектов нужно будет проделать очень большой объем работы:

  • проверить каждую строку кода сайта на наличие ошибок (включая ВСЕ сторонние библиотеки)
  • проверить сайт на ВСЕХ возможных версиях ВСЕХ возможных браузеров
  • проверить сайт на всех возможных устройствах, системах, размерах экранов с шагом 1px
  • проверить работу сайта во всех странах мира
  • … (думаю, список можно продолжать практически до бесконечности)

И знаете что самое интересное?

Для ДОКАЗАТЕЛЬСТВА, что дефектов нет — эту проверку нужно будет делать КАЖДЫЙ раз после ЛЮБОЙ правки, внесенной в сайт, после ЛЮБОГО обновления ЛЮБОГО браузера, после выхода на рынок ЛЮБОГО телефона, часов, нового экрана и т.д. и т.п.

А учитывая количество и скорость изменений “систем”, окружающих сайт — нужно будет проводить десятки тысяч сложнейших тестов ежедневно, чтоб доказать, что дефектов нет, и надеяться, что вы учли все…

Именно из-за ОГРОМНОЙ сложности и ОБЪЕМА всей системы, в которой создается и работает сайт, мы не можем узнать ОБЩЕЕ КОЛИЧЕСТВО дефектов.

А не зная общего количества дефектов — мы никогда не докажем, что их нет.

Поэтому, запоминаем:

Тестирование демонстрирует наличие дефектов, но не доказывает их отсутствие.

2️⃣ Исчерпывающее тестирование недостижимо

Рост количества тестов в процессе анализа задачи

Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо (за исключением тривиальных случаев).

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


Предположим, у нас есть сайт.
На сайте есть форма, в которой есть поле для ввода возраста.

Q: Какое общее количество комбинаций вводов существует для этого поля?
A: 

Если это поле — без ограничений и валидации — мы можем писать туда что угодно: числа, символы, буквы любого алфавита, emoji 😇, да еще и текст любой длины.

Если предположить, что максимальная длина строки для этого поля должна быть 3 символа (вряд-ли кто-то живет больше 999 лет), то максимальное количество всех возможных комбинаций (учитывая, что UTF-8 поддерживает 2,164,864 доступных символов) будет равно:

Х = 2,164,864³ =10 145 929 857 329 004 544

Можете представить, сколько комбинаций будет у поля для ввода текста с ограничением по длине в 10,000 символов 😅

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

3️⃣ Раннее тестирование сохраняет время и деньги

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

Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения.


Для простоты примера можно рассмотреть процесс исправления дефекта, найденного в требованиях к ПО и дефекта, найденного клиентом.

Дефект, найденный в требованиях к ПО — исправляется очень быстро.

Например, кнопка “Оплатить” в требованиях называется “Sell” , а должна называться “Pay”. Это дефект. Исправление — замена текста “Sell” на “Pay”, занимает 2 секунды и стоит $0,05.


Теперь посчитаем стоимость исправления этого же дефекта, найденного клиентом.

Тут — сложнее.

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

Пусть это занимает 30 минут времени команды, которая стоит $100 / час (правка в дизайне, в коде, тестирование, создание релиза, заливка…) Итого — $50.

Дальше, мы оцениваем “ущерб” от потерь репутации.

  • Сколько клиентов отказались покупать товар из-за недопонимания текста на кнопке?
  • Сколько клиентов подумало, что “если наш сервис не может нормально называть кнопки, как он может качественно делать продаваемый товар?” и ушло с формы заказа.

Грубо предположим, и будем сильно надеяться, это еще $50 😔

Таким образом, стоимость исправления ошибки, найденной клиентом — $100. Это в 2000 ❗️ раз больше, чем исправление ошибки в требованиях.


Числа, приведенные в примерах — сильно “обобщенные”. Компании HP и IBM делали исследования на эту тему, их результаты можно посмотреть здесь:

  1. DEFECT PREVENTION: REDUCING COSTS AND ENHANCING QUALITY
  2. The True Cost of a Software Bug: Part One
  3. Why Should Testing Start Early in Software Project Development?

Если очень приблизительно, то стоимость исправления ошибки в зависимости от этапа разработки следующая:

  1. Требования — х1
  2. Дизайн — х5
  3. Разработка — х15
  4. Тестирование — х25
  5. Production — x100+

4️⃣ Кластеризация дефектов

Баги живут здесь

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

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


Код пишут люди. Люди ошибаются. Одни — ошибаются чаще, чем другие и это не исправить.

То же самое применимо и к системам. Одни — проще, другие — сложнее. Чем сложнее система— тем больше вероятность возникновения ошибки и так будет всегда.

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

Все эти факторы приводят к одним и тем же последствиям — дефекты “собираются” в “кучки” в определенных частях системы.


Любой тестировщик, который занимался тестированием в команде разработки с более чем одним разработчиком на протяжении длительного отрезка времени “чувствует” это.

Он знает, что за Васей нужно проверять по 2 раза, а Саша — все делает хорошо, в большинстве случаев.

Также, он знает, что баги на сайте А — возникают очень редко, так как его делает команда опытных разработчиков. А вот с сайтом Б — не все так гладко, потому что там разработчики менее опытные.


Свойство дефектов к “группированию” нужно учитывать при планировании тестирования.

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

5️⃣ Парадокс пестицида

Automation Test Run #428421 — ALL PASSED!

Если одни и те же тесты будут выполняться снова и снова, в конечном счете они перестанут находить новые дефекты.

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


Предположим, у нас есть набор тестов, которые проверяют некий функционал, в котором есть 3 дефекта.

Пройдя тесты, мы находим 2 дефекта и исправляем их, а один дефект останется “незамеченным”.

Проходя одни и те же тесты снова и снова — мы всегда будем видеть одну и ту же картину: PASS / Пройдено.

Но, по факту, один дефект будет оставаться в системе и текущие тесты НИКАК не смогут его найти.

Для определения дефекта придется:

  • либо изменять существующие тесты
  • либо изменять тестовые данные, которые “покажут” ошибку

Чаще всего парадокс пестицида проявляется в автоматизированном тестировании изменений (регрессионном тестировании).

Постоянно “зеленые” тесты создают иллюзию “все работает”, но, как мы уже знаем, на самом деле они перестают находить новые ошибки, а ошибки со временем начинают накапливаться…

Именно поэтому ручное тестирование НИКОГДА не исчезнет 🥳😎

Название принципа происходит от “эффекта пестицида”, так как пестициды через некоторое время больше не эффективны при борьбе с вредителями (как и тесты — с нахождением новых дефектов).

*я пытался найти информацию об этом “эффекте” в Google — и ничего не нашел 🙂 Не Fake ли это??? (Если у кого-то есть ссылка на описание этого эффекта в природе — поделитесь, пожалуйста, в комментариях)

6️⃣ Тестирование зависит от контекста

Тестирование выполняется по-разному в зависимости от контекста.

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


Предположим, нам нужно проверить простой сайт, который состоит из 5 страниц.

Вы пишете некий простой чек-лист (функционала нет, тест-кейсы не нужны, не тратим время) и проверяете сайт.

Все супер, залили, ничего критического нет, вы молодец! 🥳🥳🥳


Дальше, вам отдают на проверку другой сайт.

Но в этот раз не из 5, а из 45,000 страниц, с сложным функционалом, админками и т.д. и т.п.

  1. Как вы думаете, сможете ли вы проверить этот сайт по уже готовому чек-листу?
  2. Как на счет “нагуглить” какой-то чек-лист в интернете — и проверить сайт по нему?

Надеюсь, что вы ответили — нет на оба вопроса! 😍


Тестирование всегда зависит от контекста!

  • Для сайта из 5 страниц — подход один
  • Для сайта из 45,000 — другой
  • Для онлайн-магазина — третий
  • Для посадочной страницы — четвертый
  • Для мобильного приложения todo-list— пятый
  • Для мобильного приложения банка — шестой

Поэтому, перед тем как начинать что-то проверять, нужно сделать анализ и продумать стратегию и план тестирования.

И только после этого приступать к написанию тестовой документации и тестированию!


7️⃣ Заблуждение об отсутствии ошибок

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

Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех системе.

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


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

Важно не отсутствие ошибок, а критичностьскорость реакции и исправления!

Более того, не все ошибки нужно исправлять!

Если ошибка встречается на окружении, которым пользуется 0,002% ваших пользователей, которые приносят $5 прибыли в год и на ее исправление нужно будет потратить $50,000 и пол года разработки — вы будете ее исправлять? Сильно сомневаюсь 😏

Почитайте про Zero Bug Policy, лучший процесс работы с багами, по моему мнению.


Резюме

В статье мы подробно рассмотрели 7 принципов тестирования:

  1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
  2. Исчерпывающее тестирование недостижимо
  3. Раннее тестирование сохраняет время и деньги
  4. Кластеризация дефектов
  5. Парадокс пестицида
  6. Тестирование зависит от контекста
  7. Заблуждение об отсутствии ошибок

Попробуйте пройти тест и узнайте, насколько хорошо вы разобрались.

Желаю удачи в ваших проектах и начинаниях!

🔥 Присоединяйся к 4,845
тестировщикам в Телеграм!