Принципы тестирования программного обеспечения

В статье QA-эксперты «Точка качества» описали семь принципов тестирования ИТ-продуктов, которые будет полезно знать представителям бизнеса, ИТ-директорам, менеджерам ИТ-проектов и руководителям команд разработки, прежде чем начинать сотрудничество с командой обеспечения качества.

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

Необходимо, чтобы после тестирования ПО удалось достичь желаемого качества продукта. Но как понять, что команда QA-инженеров следует правильной стратегии обеспечения качества? Следует понимать ключевые принципы тестирования:

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

Подробнее о 7 принципах тестирования

1. Полное тестирование невозможно

Именно так. Полное тестирование — невозможно. Вместо этого необходим оптимальный объём тестирования, основанный на анализе рисков приложения, веб-сайта, системы и другого ПО. Но как же определить эти риски? Чтобы ответить на вопрос, давайте выполним небольшое упражнение: на ваш взгляд, какая операция с наибольшей вероятностью приведёт к сбою операционной системы? 

Наверняка большинство людей ответит: «Одновременный запуск 15 различных программ». Таким образом, если бы вы тестировали эту операционную систему, то поняли бы, что ошибки, скорее всего, будут заключаться в многозадачности и их необходимо тщательно протестировать.

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

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

2. Кластеризация (группировка) найденных ошибок

Кластеризация (группировка) дефектов утверждает, что небольшое число модулей содержит большую часть всех дефектов. Этот принцип — пример теории 80:20 (также называемого принципом Парето): 80% всех дефектов связаны всего с 20% кода. 

Это основано на исследовании, что 80% пользователей используют лишь 20% программного продукта. Но именно эти 20% ПО содержат наибольшее количество серьёзных дефектов. Этот принцип может помочь вашей команде сосредоточиться на приоритетной области, наиболее востребованной части ИТ-решения.

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

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

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

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

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

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

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

4. Тестирование демонстрирует наличие дефектов

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

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

Но что, если вы упорно трудитесь, принимаете все меры по улучшению качества ПО и создаёте на 99% бездефектное решение. А программное обеспечение всё равно не удовлетворяет потребностям и запросам клиентов после релиза. Это подводит к следующему принципу.
 

5. Полное отсутствие ошибок — это заблуждение

 
Бывает, что ИТ-продукт на 99% без ошибок, но всё же непригоден для использования и не удовлетворяет пользователей. Это может произойти в том случае, если система тестируется правильно, но не по тем требованиям.

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

Для решения этой проблемы необходимо применить ещё один принцип —  раннее тестирование ПО.  

6. Раннее тестирование

Как показывает практика, то, что стоит 100 рублей для исправления на этапе проектирования, может стоить 1500 рублей на этапе тестирования и 10 000 рублей, если проблемы будут обнаружены в производственной среде.

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

Исправление дефектов силами разработчиков на ранних стадиях тестирования обходится компаниям гораздо дешевле. Но насколько рано следует начинать тестирование? Рекомендуется начинать поиск ошибки с момента формирования требований на проекте. 
 

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

В тестировании IT-решений не существует единой стратегии, подходящей для всех решений. Например, стратегия тестирования сайта онлайн-кинотеатра будет отличаться от тестирования готового банковского приложения. 

Например, рассмотрим две компании, выпускающие набор из 10 батареек. Первая выпускает наборы премиум-класса по 1000 рублей, а вторая — по 100 рублей, то есть в 10 раз дешевле. Как вы считаете, имеет ли смысл обеим компаниям выстраивать одинаковым процессы контроля качества? Конечно, нет. Первая компания платит больше за качество и, следовательно, у неё более жёсткие стандарты и контроль качества.

Все ИТ-решения разные. В зависимости от типа можно использовать различные подходы, методологии и виды тестирования. Как и в жизни, тестирование любой платёжной системы продуктового магазина в корни будет отличаться от тестирования банкомата или системы видеонаблюдения.

Заключительные мысли