субота, 24 грудня 2011 р.

Boundary Values, Сага

В ходе холивара на кухне про то где-же проверять входные значения родился этот пост. Эта статья основана на опыте автора и приводятся некоторые статистические данные.

Будут расматриватся места где наиболее выгодно тестировать граничные условия. И это все будет расматриватся на примере пирамиды Маслоу и на примерах. Автор немножко модифицировал пирамиду для лучшей прозрачности и соотвествия MVC модели

Пример 1: Не идеальный мир черного ящика.
В основе лежит тестирование черного ящика, когда все сосредоточено на UI уровне. Также допустим в этом случае существуют Unit tests написаные разработчиками. Тогда картинка будет следующая
Это означает, что 80% ошибок при обработке граничных условий не будет покрыто (это называется скрытыми ошибками), и любая ошибка будет занимать много времени, так как значения проходять от UI уровня к Model уровню и не известно а каком из уровней возникло не соотвествие. Стоимость ошибки в даном случае очень высоко, качество продукта низкое, отвественость высока.

Пример 2: Мир среди дорог
В этом мире существует три прослойки общества.
Первая прослойка - это тестирование граничных условий на уровне пользовательского взаимодействия с системой (javascript, controllers)
В этом случае количество ошибок уменьшается до 60% в нижних слоях и до 10% на уровне дизайна. Если 10% ошибок приемлимо, то 60% скрытых ошибок оставляют большое время на их воспроизведение и не увеличивают качество.

Во второй прослойке, граничные условия тестируются еще ниже в архитектуре. Это тестирование называется интеграционным. Тесты на этом уровне обладают таким свойством, как быстрота и простота. При таком тестировании мы получаем 10% скрытых ошибок суммарно для JS&UI уровней и 40% скрытых ошибок на уровне Models. Качество продукта при такой модели довольно высоко и риски низки. Такое тестирование имеем место и можно на этом остановится, если мало ресурсов и нет времени для более глубокого иследования продукта.


Третяя прослойка, или высшее общество мира, тестирует граничные условия на уровне Model. При таком размещении любая проблема находится настолько быстро, насколько это возможно. Стоимость ошибки низка, качество высокое. Модель приближена к идеальной пирамиде маслоу, когда у нас очень много unit-tests и мало UI, так как достаточно проверять happy-path на этих уровнях

Но при такой моделе наблюдается небольшое увеличение сумарного количества скрытых проблем, которое составляет 20%

Пример 3: Економическое сообщество
Это идеальное общество, по мнению автора. Граничные условия тестируются на двух уровнях: Model & API
При такой модели количество скрытых ошибок суммарно составляет 10%, но качество продукта очень высоко, так что стоимость такой ошибки, если она обнаруживается ооочень низка. Также такой подход позволяет обнаруживать проблемы на очень раннем этапе разработки и доставлять готовый продукт закажчику быстро. Есть конечно минусы, когда большой процент тестирования ложится на разработчиков. Хотя последние тенденции говорят, что это лучший подход в Agile разработке

Пример 4: Идеальный мир
Такой мир существует, только при разработке очень критической функциональности (банковское ПО, самолеты, и тп).
В таком случае практически нет рисков, качество продукта на супер-уровне, все щастливы и свободны (но это не долго)

Подведем итоги:
Для того чтобы а) получить очень быстрый фидбек и б) сделать очень качественных продукт с в) малыми затратами необходимо использовать модель с Примера 3
Если у вас мало ресурсов, но все равно хотите быстро получать фидбек - используйте Пример 2.в


P.S. еще несколько пояснений:
- На картинках размер уровняя соотвествует количеству тестов на этом уровне.
- Приведеная статистика взята з глубин опыта и услышана от других колег, и автор не может дать ссылку на нее, но автор чуствует, что статискика правдива, хотя может быть немного не точна
- Автор открыт для дискусий.

Немає коментарів:

Дописати коментар