- Testing shows the presence of defects, not their absence.
- Exhaustive testing is impossible.
- Early testing saves time and money.
- Defects cluster together.
- Beware of the pesticide paradox.
- Testing is context dependent.
- Absence-of-errors is a fallacy.
1. Тестирование показывает наличие дефектов
Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Тем не менее, важно составлять тест-кейсы, которые будут находить как можно больше багов. Таким образом, при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в программном обеспечении. В то же время, даже если дефекты не были найдены в процессе тестирования, нельзя утверждать, что их нет.
2. Исчерпывающее тестирование невозможно
Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключениям совсем уж примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО.
3. Раннее тестирование
Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения, и его усилия должны быть сконцентрированы на определенных целях.
4. Скопление дефектов
Разные модули системы могут содержать разное количество дефектов – то есть, плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.
5. Парадокс пестицида
Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают.
Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов.
6. Тестирование зависит от контекста
Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицинских нужд требует гораздо более строгой и тщательной проверки, чем, скажем, компьютерная игра. Из тех же соображений, сайт с большой посещаемостью должен пройти через серьезное тестирование производительности, чтобы показать возможность работы в условиях высокой нагрузки.
7. Заблуждение об отсутствии ошибок.
Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа готова к релизу. Нахождение и исправление дефектов будут не важны, если система окажется неудобной в использовании, и не будет удовлетворять ожиданиям и потребностям пользователя.
И еще несколько важных принципов:
— тестирование должно производиться независимыми специалистами;
— привлекайте лучших профессионалов;
— тестируйте как позитивные, так и негативные сценарии;
— не допускайте изменений в программе в процессе тестирования;
— указывайте ожидаемый результат выполнения тестов.
Это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, используемого оборудования и инструментальных средств, специальных знаний, а так же оценка рисков с вариантами их решения.
Это тестовый артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Сколько нужно тест кейсов для проверки функционала?
- Минимум один тест кейс.
Это документ, который описывает, какие функции должны быть проверены.
Это способ отражения связей между проектными данными в форме таблицы, например, между требованиями и компонентами системы, между требованиями и тест кейсами.
Это сущности, которые могут подтвердить корректность работы функциональной единицы или наличие дефекта (скриншот, видео).
Это тестовые артефакты в которых указываются все результаты процесса тестирования. Отчеты предоставляют информацию всем участникам и заинтересованным лицам проекта таким как: Project Manager, Test Manager, Buisness Analyst и другие.
Это вид тестирования, которое проводится с целью определения, как быстро работает вычислительная система или её часть под определенной нагрузкой.
- Тестирование производительности (Performance testing)
- Нагрузочное тестирование (Load testing)
- Стресс тестирование (Stress testing)
Это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана.
При таком тестировании используются только корректные данные.
Положительное тестирование всегда выполнятся в первую очередь.
это тестирование в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. Это может быть, например, исключительные ситуации или неверные данные.
При таком тестировании используется, как минимум, одно некорректное данное.