Принципы тестирования ПО

За последние примерно 50 лет существования отрасли разработки ПО были выделены 7 принципов тестирования технических систем. Тестирование не стоит на месте, на момент написания статьи в разных источниках можно найти и бОльшее количество принципов. И всё же давайте начнём с основных, которые, к слову, закреплены в актуальной версии (от 2018 года) официального конспекта базового уровня ISTQB.

Принцип 1 – Тестирование демонстрирует наличие дефектов, но (!) не гарантирует их отсутствия

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

Принцип 2 – Исчерпывающее тестирование недостижимо

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

Принцип 3 – Раннее тестирование

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

Принцип 4 – Скопление дефектов

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

Принцип 5 – Парадокс пестицида

Если одни и те же тесты будут прогоняться много раз, то со временем этот набор тестовых сценариев перестанет находить новые дефекты, а в конечном счете перестанет быть информативным. Это происходит по нескольким причинам:
1) Часть продукта/системы может в какой-то момент приостановиться в развитии. Это не обязательно означает, что в этой части (модуле, конкретном функционале и т.п.) уже всё исправлено и хорошо. Просто ранее найденные баги уже известны, а новые - не будут обнаружены, так как и сам функционал, и тесты, которыми мы тестируем этот функционал не изменились. То есть, чтобы получить новую информацию о зафиксированном функционале необходимо изменить сами тесты.
2) Система со временем меняется, стало быть и тестовые сценарии должны меняться. Иначе они просто устареют и не будут соответствовать актуальному функционалу. При этом вполне возможна ситуация, когда устаревший тест не заблокирован изменениями в программе, но результаты теста (успешное или неуспешное прохождение теста) - не только не несут информацию, но являются ложными. И, таким образом, усложняют и замедляют работу команды.
3) Если процесс разработки и управления качеством выстроен нормально, то система с каждой итерацией (от релиза к релизу) должна становиться всё более качественной. То есть те дефекты, которые ранее отлавливались каким-то тестовым набором, со временем будут исправлены, а значит зафиксированный набор тестов будет давать 100% успешный результат. Возможно, это и будет являться признаком достаточного качества. Но чтобы продолжать улучшение продукта, есть смысл дополнить тестовый набор дополнительными сценариями и постораться найти новые, ранее не обнаруженные, дефекты.
Чтобы преодолеть этот “парадокс пестицида”, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения или системы, и найти как можно больше дефектов.

Принцип 6 – Тестирование зависит от контекста

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

Принцип 7 – Отсутствие ошибок - не главное

Этот принцип в РуНете часто называют так: "Заблуждение об отсутствии ошибок". Мне кажется, такое название далековато от оригинала ("Absence-of-errors fallacy") и не отражает суть принципа.
Итак, отсутствие ошибок, а конкретнее - несоответствий программы заложенным требованиям, не поможет стать программе успешной, если сами требования ошибочны, созданная система не подходит пользователю и не соотносится с ожиданиями и потребностями аудитории и рынка.