В этой модели происходят те же процессы, что и в модели водопада: определение задач, требований, дизайна, разработка, тестирование и т.д.
Но от версии к версии продукт меняется с фиксированием найденных ошибок, а также добавляются новые функции, опции, изменением дизайна и т.д., происходит развитием программного продукта.
Очень большой плюс данной модели в том, что не существует войны между временем и качеством. Для конкретного состояния продукта нет четких временных рамок. Возможно, есть рамки по выходу очередной версии в свет, но в каком состоянии должен находиться продукт, как он должен выглядеть – по срокам не оговаривается.
Это оптимальная модель для комфортной работы.
Качество со временем, конечно, повышается, повышается функциональность программного продукта, и он доводится до ума.
Но есть и большой минус.
Невозможно спроектировать и спланировать каждую версию программы, в каком виде, и к какому сроку она будет готова. А в наше время – время рыночной экономики, это очень важный параметр, т.к. конкуренты между собой очень сильно борются за выход программы к определенному сроку. Тот,
кто выпустит версию программы раньше, естественно, заработает больше денег.
Если же продукт выпускается внутри фирмы, для внутреннего пользования, то эволюционная модель выглядит предпочтительнее модели водопада. Нет никакой спешки, есть только желание улучшать качество продукта.
Для чего же нужен тестировщик в такой модели?
Его существование обусловлено тем, что ошибки обязательно будут.
И вопрос не в том, будут ли ошибки. Вопрос в том, сколько их будет!
Откуда же они возникают?
Существует множество источников ошибок.
- Новые вещи в программе, дополнительные функции и опции, нововведения.
- Переход на новые технологии.
- Переход на новый рынок или написание программы для нового заказчика – вследствие чего появляются новые требования, новый подход к разработке.
Консерватизм в этом плане для разработки программы лучше, но не бывает так, что продукт не развивается. В век информационных технологий нововведения – это ежедневные реалии.
- Напряженная и утомительная работа, когда продукт выпускается в свет в сжатые сроки. Особенно часто такая ситуация возникает при приближении к стадии выпуска продукта. С русским менталитетом получается такая ситуация, что на последнем этапе, когда уже по срокам должна выйти альфа-версия, не сделана еще и половина продукта. Естественно, программисты начинают задерживаться на
работе, соответственно, устают. Работа проходит в режиме постоянного напряжения, поэтому часто возникают ошибки – как по невнимательности, так и ошибки, характерные для обычного режима работы.
- Личные проблемы программистов. Человек - не машина, что откладывает отпечаток на его работу.
С этим ничего не поделаешь, это надо принимать как факт, как явление природы.
Надо понимать, что ошибки будут возникать, и будут возникать - всегда.
- Неправильное формулирование технического задания. Либо требования конфликтуют друг с другом, имеют противоречия.
- Разработка продукта без определенных требований, когда они четко не сформулированы или даже неизвестны вовсе.
- Неправильное понимание технического задания программистами.
- Следствие других ошибок. Часто бывают такие ситуации, когда ошибки связаны друг с другом, когда ошибка является триггером на другие ошибки. Тогда одна ошибка влечет за собой несколько других – цепочку ошибок. Причем обнаружена может быть любая из них: или она - инициатор других ошибок, или она сама была инициирована другой ошибкой.
- Слабые инструменты тестирования. Программы, которые тестировщик использует для проверки других программ, сами являются дефектными, когда инструменты тестирования сами содержат в себе ошибки, отчего тестирование происходит далеко некачественно. К слову, ручное тестирование в этом плане имеет преимущество.
Есть еще одна очень важная вещь, которая может повлечь за собой не то, чтобы сами ошибки, а возможность их появления в конечном продукте.
- Ошибка выбора тестовой стратегии, когда одна и та же тестовая стратегия используется от версии к версии, причем используются одни и те же тесты, когда используется один набор тестов в каждой версии. Это плохо потому, что выбран слишком узкий обзор программы. От версии к версии, кроме существующих тестов, необходимо выполнять новые, использовать другие методы, другие стратегии,
т.е. расширять область тестирования.
