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