Принципы Тестирования 🔥
Существует 7 принципов тестирования:
- Тестирование демонстрирует наличие дефектов, а не их отсутствие
- Исчерпывающее тестирование недостижимо
- Раннее тестирование сохраняет время и деньги
- Кластеризация дефектов
- Парадокс пестицида
- Тестирование зависит от контекста
- Заблуждение об отсутствии ошибок
Именно принципы тестирования являются основой всех стандартов, книг, методов и техник тестирования.
Их понимание является фундаментом знаний тестировщика и позволяет работать быстрее, качественнее и эффективнее.
В статье подробно рассказываю и объясняю принципы тестирования программного обеспечения.
В конце вы сможете пройти тест и увидеть, на сколько хорошо вы разобрались. Рекорд — 7 правильных ответов за 17 сек 💪
🔥 Интересуешься тестированием и хочешь получать актуальную информацию?
👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!
Тебе не хватает практики по тестированию?
👉 Получи практическое задание!
Хочешь расти быстрей, как профессионал?
👉 Оставляй заявку на менторство!
Предлагаю начать с определения понятия “принцип”.
Принцип или основа, начало, первоначало (лат. principium, греч. αρχή, дословно первейшее) — постулат, утверждение, на основе которого создают научные теории и законы, юридические документы, выбирают нормы поведения в обществе.
Исходя из этого определения, мы можем сказать, что:
Принципы тестирования — это основы тестирования
Их нельзя изменить, отменить, понимать “частично” или поверхностно.
Они всегда были, есть и будут, и без их понимания тестировщик никогда не станет высокооплачиваемым профессионалом.
Давайте разбираться! 🧐
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 ❗️ раз больше, чем исправление ошибки в требованиях.
Теперь вы будете лучше понимать предназначение метрики “количество ошибок, пропущенных на production” и зачем она нужна 😉
Числа, приведенные в примерах — сильно “обобщенные”. Компании HP и IBM делали исследования на эту тему, их результаты можно посмотреть здесь:
Если очень приблизительно, то стоимость исправления ошибки в зависимости от этапа разработки следующая:
- Требования — х1
- Дизайн — х5
- Разработка — х15
- Тестирование — х25
- Production — x100+
4️⃣ Кластеризация дефектов
Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во время тестирования перед выпуском и отвечает за большинство эксплуатационных отказов.
Предсказанные кластеры дефектов и фактические наблюдаемые кластеры дефектов в ходе тестирования или эксплуатации являются важными входными данными для анализа риска, используемого для сосредоточения усилий по тестированию.
Код пишут люди. Люди ошибаются. Одни — ошибаются чаще, чем другие и это не исправить.
То же самое применимо и к системам. Одни — проще, другие — сложнее. Чем сложнее система— тем больше вероятность возникновения ошибки и так будет всегда.
Добавим сюда дедлайны. Чем ближе к дедлайну — тем больше нагрузка. Чем больше нагрузка — тем меньше времени разработчик уделяет “красоте” кода и перепроверке самого себя. Отсюда тоже берутся ошибки.
Все эти факторы приводят к одним и тем же последствиям — дефекты “собираются” в “кучки” в определенных частях системы.
Любой тестировщик, который занимался тестированием в команде разработки с более чем одним разработчиком на протяжении длительного отрезка времени “чувствует” это.
Он знает, что за Васей нужно проверять по 2 раза, а Саша — все делает хорошо, в большинстве случаев.
Также, он знает, что баги на сайте А — возникают очень редко, так как его делает команда опытных разработчиков. А вот с сайтом Б — не все так гладко, потому что там разработчики менее опытные.
Свойство дефектов к “группированию” нужно учитывать при планировании тестирования.
Это поможет вам, как тестировщику, лучше оптимизировать время на тестирование и помогать там, где это действительно необходимо.
5️⃣ Парадокс пестицида
Если одни и те же тесты будут выполняться снова и снова, в конечном счете они перестанут находить новые дефекты.
Для обнаружения новых дефектов может потребоваться изменение существующих тестов / тестовых данных или написание новых.
Предположим, у нас есть набор тестов, которые проверяют некий функционал, в котором есть 3 дефекта.
Пройдя тесты, мы находим 2 дефекта и исправляем их, а один дефект останется “незамеченным”.
Проходя одни и те же тесты снова и снова — мы всегда будем видеть одну и ту же картину: PASS / Пройдено.
Но, по факту, один дефект будет оставаться в системе и текущие тесты НИКАК не смогут его найти.
Для определения дефекта придется:
- либо изменять существующие тесты
- либо изменять тестовые данные, которые “покажут” ошибку
Чаще всего парадокс пестицида проявляется в автоматизированном тестировании изменений (регрессионном тестировании).
Постоянно “зеленые” тесты создают иллюзию “все работает”, но, как мы уже знаем, на самом деле они перестают находить новые ошибки, а ошибки со временем начинают накапливаться…
Именно поэтому ручное тестирование НИКОГДА не исчезнет 🥳😎
Название принципа происходит от “эффекта пестицида”, так как пестициды через некоторое время больше не эффективны при борьбе с вредителями (как и тесты — с нахождением новых дефектов).
*я пытался найти информацию об этом “эффекте” в Google — и ничего не нашел :) Не Fake ли это??? (Если у кого-то есть ссылка на описание этого эффекта в природе — поделитесь, пожалуйста, в комментариях)
6️⃣ Тестирование зависит от контекста
Тестирование выполняется по-разному в зависимости от контекста.
Например, программное обеспечение управления производством, в котором критически важна безопасность, тестируется иначе, чем мобильное приложение электронной коммерции.
Припустим, нам нужно проверить простой сайт, который состоит из 5 страниц.
Вы пишете некий простой чек-лист (функционала нет, тест-кейсы не нужны, не тратим время) и проверяете сайт.
Все супер, залили, ничего критического нет, вы молодец! 🥳🥳🥳
Дальше, вам отдают на проверку другой сайт.
Но в этот раз не из 5, а из 45,000 страниц, с сложным функционалом, админками и т.д. и т.п.
- Как вы думаете, сможете ли вы проверить этот сайт по уже готовому чек-листу?
- Как на счет “нагуглить” какой-то чек-лист в интернете — и проверить сайт по нему?
Надеюсь, что вы ответили — нет на оба вопроса! 😍
Тестирование всегда зависит от контекста!
- Для сайта из 5 страниц — подход один
- Для сайта из 45,000 — другой
- Для онлайн-магазина — третий
- Для посадочной страницы — четвертый
- Для мобильного приложения todo-list— пятый
- Для мобильного приложения банка — шестой
- …
Поэтому, перед тем как начинать что-то проверять, нужно сделать анализ и продумать стратегию и план тестирования.
И только после этого приступать к написанию тестовой документации и тестированию!
7️⃣ Заблуждение об отсутствии ошибок
Некоторые организации ожидают, что тестировщики смогут выполнить все возможные тесты и найти все возможные дефекты, но принципы 2 и 1, соответственно, говорят нам, что это невозможно.
Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех системе.
Например, тщательное тестирование всех указанных требований и исправление всех обнаруженных дефектов может привести к созданию системы, которая будет трудной в использовании, не будет соответствовать потребностям и ожиданиям пользователей или будет хуже по сравнению с другими конкурирующими системами.
Сейчас мы уже знаем, что все ошибки найти невозможно, исходя из принципа 1 и 2. Ошибки есть всегда. Они были и будут, вы с этим ничего не сделаете и это нормально.
Важно не отсутствие ошибок, а критичность, скорость реакции и исправления!
Более того, не все ошибки нужно исправлять!
Если ошибка встречается на окружении, которым пользуется 0,002% ваших пользователей, которые приносят $5 прибыли в год и на ее исправление нужно будет потратить $50,000 и пол года разработки — вы будете ее исправлять? Сильно сомневаюсь 😏
Почитайте про Zero Bug Policy, лучший процесс работы с багами, по моему мнению.
Теперь вы точно знаете 7 принципов тестирования:
- Тестирование демонстрирует наличие дефектов, а не их отсутствие
- Исчерпывающее тестирование недостижимо
- Раннее тестирование сохраняет время и деньги
- Кластеризация дефектов
- Парадокс пестицида
- Тестирование зависит от контекста
- Заблуждение об отсутствии ошибок
Попробуйте пройти тест и узнайте, насколько хорошо вы разобрались. Рекорд — 7 правильных ответов за 17 сек 💪
На этом у меня все 😉
Желаю удачи в ваших проектах и начинаниях!
🔥 Интересуешься тестированием и хочешь получать актуальную информацию?
👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!
Тебе не хватает практики по тестированию?
👉 Получи практическое задание!
Хочешь расти быстрей, как профессионал?
👉 Оставляй заявку на менторство!
*приведенные выше принципы — взяты из стандарта ISTQB Базовый уровень 2018 года (см. раздел 1.3)
