Нет зависимостей между тестами
Поскольку тесты могут дополняться, меняться, терять свою актуальность и удаляться – как в таком случае поступать с тестами, на которые ссылались эти кейсы?
Аксиомы тестирования
Тестирование хоть и не является научной дисциплиной, но обладает своими аксиомами.
Тестирование показывает наличие дефектов
Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов нет.
Доказать, что чего-то нет, в принципе затруднительно. Сколько бы белых лебедей мы ни видели, это еще не служит основанием утверждать, что «все лебеди белые». Но если мы увидим хотя бы одного черного лебедя, мы может сказать, что «не все лебеди белые».
Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку. Но если мы нашли хотя бы один дефект, мы уже можем утверждать, что в данном ПО присутствуют дефекты.
Впрочем, это отнюдь не означает, что тестирование бесполезно и не может повысить наш уровень уверенности в качестве ПО. Тестирование уменьшает вероятность необнаруженных дефектов, которые остаются в ПО, но всегда нужно помнить, что даже если дефекты не найдены, это еще не доказательство того, что их нет.
Исчерпывающее тестирование невозможно
Этот принцип связан с вопросом: «сколько нужно тестировать?».
Какие вообще могут быть ответы на этот вопрос? Мы можем протестировать всё, ничего не тестировать или протестировать какую-то часть. Идеальным вариантом выглядит «протестировать всё», но стоит разобраться, можем ли вообще это сделать.
|
|
|
Сколько тестов нужно выполнить, чтобы полностью протестировать поле ввода, принимающее одну цифру? Зависит от того, что мы понимаем под словом «полностью». Есть 10 возможных валидных значений, но, кроме того, надо еще убедиться, что не валидные значения правильно обрабатываются. 26 заглавных латинских букв, 26 строчных букв, не менее 6 знаков пунктуации и пробел… Уже 68, а это мы еще не вспомнили о кириллице, спецсимволах и тому подобном.
Если мы посмотрим на более реалистичный пример, то всё ещё хуже. На практике, системы обычно имеют более одного поля ввода и поля эти имеют разный размер. А еще есть различные окружения, на которых нужно выполнить тесты… Если мы возьмем для примера один скрин, на котором 15 полей ввода, каждое из которых принимает 5 значений, то чтобы протестировать все валидные комбинации ввода, нам понадобится 30 517 578 125 (5 в 15-й степени) тестов. Очень маловероятно, что это уложится во временные рамки вашего проекта.
Объем тестирования в реальной жизни ограничен временными рамками и бюджетом, в то же время существует необходимость поставить техническое решение, которое отвечает требованиям заказчика. Заказчики и руководители проекта хотят возврата инвестиций (ROI) от времени, потраченного на тестирование (время – деньги). Например, предотвратить появление ошибок после релиза – исправлять их всегда дорого. Но полное тестирование они просто не могут себе позволить – даже если очень хочется…
|
|
|
Вместо попыток «протестировать всё» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта. Кроме того, тестирование должно обеспечивать
необходимую информацию, чтобы заинтересованные лица могли принимать информированные решения о релизе продукта или передаче заказчикам.
Раннее тестирование
В прошлом уроке мы уже обсуждали, что тестирование должно начинаться как можно раньше в цикле разработки, но «.Повторение, мать учения».
Этот принцип связан со стоимостью дефекта, на разных этапах разработки. О чем мы говорили в прошлом уроке. Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить.
|
|
|
Дефект, найденный в требованиях, обходится дешевле всего. Если дефект обнаружен на этапе разработки архитектурного решения, исправить его тоже не составляет большого труда. Если же дефект, внесенный еще на уровне требований, «дожил» до этапа системного или приемочного тестирования, исправление его будет очень дорогим – ведь придется внести изменения не только в код, но, возможно, и в архитектуру, и в требования. Кроме того, один дефект в требованиях может проявиться во множественных дефектах на уровне архитектуры и кода, а после внесения исправлений нужно вновь проводить тестирование.
Порой дефекты, обнаруженные на слишком поздней стадии, вообще не исправляются, потому что это обошлось бы слишком дорого.
Случается, и так, что ПО поставляется и формально соответствует согласованным требованиям, но не соответствует нуждам и потребностям пользователей. Это также вызывает целый ряд проблем – нежелание пользователей переходить на новую систему, сложности с продажей и внедрением и так далее. Это значит, что требования изначально были неполны, но этот изъян не был обнаружен.
|
|
|
Вот почему важно начинать тестирование как можно раньше, со статических техник.
Еще одно важное преимущество раннего тестирования – экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и
спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.
Скопление дефектов
Многие тестировщики наблюдали такой эффект – дефекты «кучкуются». Это может происходить потому, что определенная область кода особенно сложна и запутана, или потому, что внесение изменений производит «эффект домино». Это знание часто используется для оценки рисков при планировании тестов – тестировщики фокусируются на известных «проблемных зонах».
О том, где «кучкуются» дефекты, можно узнать еще на ранних этапах, когда проводится статическое тестирование (например, code review и анализ кода при помощи специальных инструментах). Когда дойдет дело до динамического тестирования, можно сфокусироваться на тех областях, где было обнаружено больше дефектов статическими методами.
Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
Парадокс пестицидов
Если повторять те же тесты снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Те скопления дефектов, о которых говорит 4-й принцип, имеют тенденцию перемещаться. Почему так происходит?
Эту аналогию ввел Борис Бейзер в 1983 г. Он привел пример обработки полей пестицидами. Поле обрабатывается неким пестицидом в первый раз, и значительная часть вредителей погибает, но некоторые все же выживают, потому что их организмы оказались устойчивы к действию яда. Если повторно обработать поле тем же пестицидом, то выжившие после первой обработки с большой вероятностью выживут и после второй. Повторное применение тех же тестов и тех же методик приводит к тому, что в продукте остаются именно те дефекты, против которых эти тесты и эти методики неэффективны.
Чтобы преодолеть «парадокс пестицидов», необходимо регулярно пересматривать существующие тест-кейсы и создавать новые, разнообразные тесты, которые будут выполняться на различных частях системы. Это позволит обнаружить больше дефектов.
Дата добавления: 2018-08-06; просмотров: 475; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!