1.4 Принципы тестирования
1. Тестирование показывает наличие дефектов.
В процессе тестирования мы снижаем вероятность наличия дефектов, но даже если дефекты не обнаружены, мы не можем говорить о том, что дефектов нет вообще. Как показывает практика, баги в продукте есть всегда.
2. Исчерпывающее тестирование невозможно.
Протестировать абсолютно все невозможно. Всегда есть риски и приоритеты. Чтобы минимизировать риски, используют тест-дизайны чтобы спроектировать все так, чтобы покрыть как можно больше тестовых случаев.
Тестовые активности должны начинаться как можно раньше.
Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения. [ISTQB CTFL]
4. Скопление дефектов (Кластеризация дефектов).
В небольшом количестве модулей содержится наибольшее количество дефектов. То есть в 20% модулей находиться 80% дефектов. Наибольшее количество дефектов сконцентрировано не во всем приложении, а в какой то определённой функциональности.
Например, при тестировании модулей регистрации, авторизации и создания профиля пользователя большая часть дефектов сконцентрирована в модуле авторизации.
Прогоняя одни и те же тесты вновь и вновь, сталкиваешься с тем, что они находят все меньше и меньше ошибок. Чтобы преодолеть этот парадокс нужно корректировать тесты для того, чтобы они соответствовали новому состоянию системы.
Для борьбы с эффектом пестицида можно использовать следующие примеры:
- Обновление тест-кейсов
- Обновление тестовых данных
- Смена ответственного за тестирование определенной функции
6. Тестирование зависит от контекста.
Выбор техники или метода тестирования зависит от природы самой программы. Например, ПО для медицины требует более тщательную проверку, чем игра. Сайт с большей посещаемостью должен пройти через более серьезное тестирование для того, чтобы показать производительность во время серьезной нагрузки. Тестировщик должен ответственно подходить к выбору среды тестирования и документации. Если продукт сложный - лучше выбрать тест-кейсы, а не чек листы.
7. Заблуждение об отсутствии ошибок.
Не стоит полагать, что если тестирование не обнаружило ошибок - то программа готова к релизу. Даже если мы уверены, что багов нет, они все равно будут, так как приложение может не совпадать с ожиданиями пользователя. Этот принцип не привязан к количеству проверок.
Например, тщательное тестирование всех указанных требований и исправление всех обнаруженных дефектов может привести к созданию системы, которая будет трудной в использовании, не будет соответствовать потребностям и ожиданиям пользователей или будет хуже по сравнению с другими конкурирующими системами. [ISTQB CTFL]
Перефразирую на человеческий язык. Компания разработала интернет-магазин для страны, в которой часть населения не может использовать онлайн-оплату. В итоге, конечные пользователи не смогли приобрести желаемый товар, перестали пользоваться приложением и занизили его рейтинг. В данном случае при сборе требований компания не учла все кейсы, разработчики создали программу, которая соответствует предоставленным им требованиям, однако не соответствует нуждам пользователя.