1. Теория тестирования
1.4. Семь принципов тестирования
За последние пятьдесят лет был предложен ряд принципов тестирования, которые являются общим руководством для тестирования в целом:
- Тестирование демонстрирует наличие дефектов, а не их отсутствие
- Исчерпывающее тестирование недостижимо
- Раннее тестирование сохраняет время и деньги
- Кластеризация дефектов
- Парадокс пестицида
- Тестирование зависит от контекста
- Заблуждение об отсутствии ошибок
1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, тестирование не доказывает его корректности.
Предположим, у нас есть сайт, который нужно проверить перед передачей заказчику.
Мы проводим тестирование и находим 20 багов. В этом случае тестирование показало, что в изначальном варианте сайта было 20 дефектов. Дальше, мы исправляем все ошибки и после следующего тестирования не находим ни одного бага. О чем это говорит?
1) Повторное тестирования показало, что мы исправили 20 багов и не нашли новых.
2) Это факт — мы нашли и исправили 20 дефектов в ПО
А для нахождения всех дефектов нужно будет проделать очень большой объем работы:
- проверить каждую строку кода сайта на наличие ошибок (включая ВСЕ сторонние библиотеки)
- проверить сайт на ВСЕХ возможных версиях ВСЕХ возможных браузеров
- проверить сайт на всех возможных устройствах, системах, размерах экранов с шагом 1px
- проверить работу сайта во всех странах мира
- …
- …
- … (думаю, список можно продолжать практически до бесконечности)
И знаете что самое интересное?
Для доказательства, что дефектов нет — эту проверку нужно будет делать каждый раз после любой правки, внесенной в сайт, после любого обновления любого браузера, после выхода на рынок любого телефона, часов, нового экрана и т.д. и т.п.
А учитывая количество и скорость изменений “систем”, окружающих сайт — нужно будет проводить десятки тысяч сложнейших тестов ежедневно, чтоб доказать, что дефектов нет, и надеяться, что вы учли все…
Именно из-за огромной сложности и объема всей системы, в которой создается и работает сайт, мы не можем узнать общее количество дефектов. А не зная общего количества дефектов — мы никогда не докажем, что их нет.
2. Исчерпывающее тестирование недостижимо
Полное тестирование с использованием всех комбинаций вводов и предусловий физически
невыполнимо, за исключением тривиальных случаев. Вместо попытки исчерпывающего
тестирования должны использоваться анализ рисков, техники тест-дизайна и расстановка приоритетов, чтобы сосредоточить усилия по тестированию.
3. Раннее тестирование сохраняет время и деньги
Для нахождения дефектов на ранних стадиях, как статические, так и динамические активности
по тестированию должны быть начаты как можно раньше в жизненном цикле разработки
программного обеспечения. Раннее тестирование иногда называют «сдвигом влево».
Тестирование на ранних этапах жизненного цикла разработки программного обеспечения
помогает сократить или исключить дорогостоящие изменения.
Для простоты примера можно рассмотреть процесс исправления дефекта, найденного в требованиях к ПО и дефекта, найденного клиентом.
Дефект, найденный в требованиях к ПО — исправляется очень быстро.
Например, кнопка “Оплатить” в требованиях называется “Sell” , а должна называться “Pay”. Это дефект. Исправление — замена текста “Sell” на “Pay”, занимает 2 секунды и стоит $0,05.
Теперь посчитаем стоимость исправления этого же дефекта, найденного клиентом.
Тут — сложнее.
Во первых, мы оцениваем стоимость технического исправления командой разработки.
Пусть это занимает 30 минут времени команды, которая стоит $100 / час (правка в дизайне, в коде, тестирование, создание релиза, заливка…) Итого — $50.
Дальше, мы оцениваем “ущерб” от потерь репутации.
- Сколько клиентов отказались покупать товар из-за недопонимания текста на кнопке?
- Сколько клиентов подумало, что “если наш сервис не может нормально называть кнопки, как он может качественно делать продаваемый товар?” и ушло с формы заказа.
- …
Грубо предположим, и будем сильно надеяться, это еще $50 ?
Таким образом, стоимость исправления ошибки, найденной клиентом — $100. Это в 2000 ❗️ раз больше, чем исправление ошибки в требованиях.
4. Кластеризация дефектов
Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во
время тестирования перед выпуском, или отвечает за большинство эксплуатационных отказов.
Предсказанные кластеры дефектов и фактические наблюдаемые кластеры дефектов в ходе
тестирования или эксплуатации являются важными входными данными для анализа риска,
используемого для сосредоточения усилий по тестированию.
Простыми словами, кластеризация дефектов — принцип, который предполагает, что небольшое количество модулей содержат в себе большинство багов. Это яркий пример применения в тестировании принципа Парето: 80% проблем таятся в 20% модулей.
Код пишут люди и они могут ошибаться, причем одни могут ошибаться чаще, чем другие.
То же самое применимо и к системам. Одни — проще, другие — сложнее. Чем сложнее система— тем больше вероятность возникновения ошибки и так будет всегда.
Добавим сюда дедлайны. Чем ближе к дедлайну — тем больше нагрузка. Чем больше нагрузка — тем меньше времени разработчик уделяет “красоте” кода и перепроверке самого себя. Отсюда тоже берутся ошибки.
Все эти факторы приводят к одним и тем же последствиям — дефекты “собираются” в “кучки” в определенных частях системы. Предсказанные на основе опыта кластеры дефектов и фактические наблюдаемые кластеры дефектов в ходе тестирования или эксплуатации являются важными входными данными для анализа риска, используемого для сосредоточения усилий по тестированию. Это поможет вам, как тестировщику, лучше оптимизировать время на тестирование и помогать там, где это действительно необходимо.
5. Парадокс пестицида
Если одни и те же тесты будут выполняться снова и снова, в конечном счете эти тесты больше не будут находить новых дефектов. Для обнаружения новых дефектов может потребоваться изменение существующих тестов и тестовых данных, а также написание новых тестов.
Повторное применение одного и того же пестицида для истребления насекомых со временем приведет к выработке у насекомых устойчивости к этому пестициду. То же касается и тестирования софта. Если есть некий набор повторяемых тестов, он будет бесполезен в определении новых дефектов.
Чтобы решить эту проблему, тест-кейсы должны регулярно просматриваться и обновляться, должны добавляться новые тест-кейсы, ориентированные на другую функциональность или тестирующие уже существующую под другим углом.
6. Тестирование зависит от контекста
Тестирование выполняется по-разному в зависимости от контекста. Это значит, что способ, которым вы тестируете сайт для e-commerce, будет отличаться от способа тестирования мобильного приложения. Софт бывает самый разный и подход к его тестированию тоже бывает самый разный. Необходимо применять разные подходы, методологии, техники и типы тестирования в зависимости от приложения. Тестирование POS-системы в ритейле отличается от тестирования АТМ-банкомата.
Предположим, нам нужно проверить простой сайт, который состоит из 5 страниц. Вы пишете некий простой чек-лист (функционала нет, тест-кейсы не нужны, не тратим время) и проверяете сайт. Все супер, залили, ничего критического нет, вы молодец! Дальше, вам отдают на проверку другой сайт. Но в этот раз не из 5, а из 45,000 страниц, с сложным функционалом, админками и т.д. и т.п. Надеюсь, что вы ответили — нет на оба вопроса! Тестирование всегда зависит от контекста! Поэтому, перед тем как начинать что-то проверять, нужно сделать анализ и продумать стратегию и план тестирования.
7. Заблуждение об отсутствии ошибок
Некоторые организации ожидают, что тестировщики смогут выполнить все возможные тесты и найти все возможные дефекты, но принципы 2 и 1, соответственно, говорят нам, что это невозможно. Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех системе. Например, тщательное тестирование всех указанных требований и исправление всех обнаруженных дефектов может привести к созданию системы, которая будет трудной в использовании, не будет соответствовать потребностям и ожиданиям пользователей или будет хуже по сравнению с другими конкурирующими системами.Также надо помнить такую аксиому – не существует какого-либо продукта без багов или ошибок. Даже готовый и хорошо протестированный продукт может оказаться не идеален, так как под каждого человека индивидуально его не подстроить. Дефекты однозначно будут. Но в тестировании и нет такой задачи, чтобы выявить 100% багов, т.к. мы уже знаем, что это невозможно, исходя из принципов 1 и 2.
Присутствует в тестировании и такой парадокс – не все ошибки нужно исправлять) На самом деле, все решают деньги. К примеру, если исправление бага не принесло бы компании никакой финансовой отдачи, но при этом отняло бы много времени и ресурсов, такую багу лучше отложить до лучших времен.
Главное здесь – найти наиболее критичные для проекта ошибки и, как вариант минимизирования пропущенных дефектов - пользоваться принципом о раннем тестировании.
Источники: ISTQB - силлабус, Семь главных принципов тестирования — testengineer.ru, Принципы тестирования: нас 7 / Хабр (habr.com), Принципы Тестирования (c Примерами) | BeQA.proДополнительные материалы: