Тестирование программного обеспечения - относительно молодая сфера деятельности. Вместе с тем тестирование появилось тогда, когда появились первые программы. Кстати, из-за ошибок в программах было очень много случаев когда компании, государство, граждане несли большие финансовые потери, и даже были случаи нанесения вреда здоровью. Но об этом в следующей статье.
А эта статья посвящена Аксиомам тестирования.
Вы наверняка сталкивались в Интернете с кучей предложений пройти курсы и стать тестировщиком. И каждый тестировщик должен прежде всего знать те правила в тестировании, которые не требуют доказательств.
Разберём подробнее:
Тестирование показывает наличие дефектов
Тестирование может показать что в программе есть ошибки, но не может показать что их нет! Из этого следует следующая аксиома.
Исчерпывающее тестирование невозможно
Эта аксиома означает что нельзя протестировать всё! Так как затраты на тестирование увеличивают деньги и время на проект. Иначе можно увлечься до такой степени, что этап тестирования будет дороже этапа разработки программы.
Раннее тестирование
Чем раньше будет найдена ошибка тем лучше. Существует зависимость между моментом обнаружения ошибки и стоимостью её исправления. И даже небольшой баг порой на поздних этапах разработки исправить становится невероятно дорого. Поэтому процесс тестирования начинается сразу как только будет что тестировать. Кстати, иногда сначала пишут тесты, а потом программу для этих тестов. Это называется TDD (test-driven development) - Разработка через тестирование.
Скопление дефектов
Парадокс пестицида
Если повторять те же тесты снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты. Почему это происходит? По аналогии с обработкой полей пестицидами - после обработки значительная часть вредителей погибает, но некоторые выживают, потому что их организмы оказались наиболее устойчивы к действию яда. То есть повторное применение тех же тестов оставляет в программном продукте именно те дефекты, против которых эти методики и тесты неэффективны. Поэтому необходимо пересматривать тест-кейсы, составлять разнообразные тесты для разных модулей системы
Тестирование зависит от контекста
Разные системы требуют различные уровни тестирования и связаны с разным уровнем риска. Например мы можем тестировать ПО для мединского оборудования или простой сайт. Одни проблемы связаны с большой потерей денег, репутации, времени, а порой даже вопрос жизни и смерти, а другие ошибки в ПО тривиальны - например форма регистрации на сайте не воспринимает дату 29 февраля в високосный год. При этом проблема (риск), связанная со значительным ущербом, может иметь незначительную вероятность, и, наоборот, риск с небольшим ущербом может иметь достаточно большую вероятность. Уровень риска влияет на выбор методологий, техник и типов тестирования.
Заблуждение об отсутствии ошибок
Если постоянная система неудобна для использования пользователями и не соответствует их нуждам и ожиданиям, нахождение и исправление дефектов в ней бесполезно.
На самом деле заказчикам всё равно сколько ошибок в ПО. Им важно чтобы система работала и эффективно справлялась со своими функциями. Поэтому отсутствие ошибок вовсе не означает что с системой все в порядке.