Семь принципов тестирования

Давайте рассмотрим эти 7 принципов тестирования в точки зрения их применения.

1. Тестирование показывает наличие дефектов (а не их отсутствие)

По-английски: Testing shows presence of defects (not their absence).

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

На практике это означает, что мы можем утверждать о том, что только часть программы проверена (никогда 100%), и сообщить, какие баги там выявлены. И никогда не сможем утверждать, что дефектов больше нет.

Это подводит к следующему принципу.

2. Все протестировать невозможно

По-английски: Exhaustive testing is not possible.

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

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

3. Отсутствие ошибок – обманчиво

По-английски: Absence of errors is deceptive.

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

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

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

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

По-английски: Defect clustering.

Есть такое эмпирическое (основанное на опыте) правило Парето, которое гласит, что если объектов в системе очень много, то около 20% от них порождают около 80% последствий для всей системы. Например, 80% продаж приходится на 20% самых лояльных покупателей. Это называют еще правилом 20/80, хотя 20 и 80 – это примерные числа, в жизни бывает и 10/85, и 25/90, и т.д.

Правило Парето справедливо и для тестирования, а именно: 80% дефектов обычно скрываются в 20% кластерах программы (кластер – это части, на которые можно условно поделить код/модули/процедуры ПО).

На практике это означает, что если в каком-то кластере мы нашли несколько багов (больше, чем ожидалось), то его следует еще внимательнее проверить на наличие других дефектов – с большой долей вероятности мы их там найдем.

А еще на практике это означает, что чтобы провести оптимальное тестирование, то нам надо найти (предположить на основании оценки рисков) наиболее дефектоопасные кластеры и в первую очередь работать с ними. Для этого проводят тест-анализ, на основании которого составляют стратегию тестирования и план тестирования.

5. Тестирование зависит от контекста

По-английски: Testing is context dependent.

Метод, которым вы тестируете сайт для Интернет-магазина на декстопе, будет отличаться от тестирования приложения для знакомств на смартфоне.

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

6. Парадокс пестицида

По-английски: Pesticide paradox.

Здесь прямая аналогия с багами (жуками): Если все время использовать один и тот же пестицид (яд для защиты растений от насекомых), то у жуков постепенно разовьется к нему иммунитет. Если все время использовать один и тот же метод тестирования, то многие дефекты можно и не заметить.

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

7. Раннее тестирование экономит деньги

По-английски: Early testing saves money.

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

На практике это означает, что тестирование следует начинать как можно раньше в жизненном цикле разработки. Даже еще до собственно кодирования. И даже еще до дизайна. Например, сразу после описаний бизнес-требований к ПО.

Резюме

Каждая уважающая себя онлайн-школа тестировщиков учит студентов этим принципам. Опытные QA-специалисты знают их в совершенстве и умеют применять на практике. Поэтому не удивляйтесь, если на собеседовании Вам зададут по ним вопросы. Прочитав эту статью, Вы уже будет готовы ответить на них по существу.