1.1.6.4. Фаза выпуска продукта

Ввод в эксплуатацию проходит минимум в три фазы:

1) первоначальная загрузка информации;

2) накопление информации;

3) выход на проектную мощность.

Первоначальная загрузка информации инициирует довольно узкий круг ошибок — в основном это проблемы рассогласования данных при загрузке и собственные ошибки загрузчиков, то есть то, что не было отслежено на тестовых данных. Подобные ошибки должны быть исправлены как можно быстрее. Необходимо поставить отладочную версию системы. Если отладку «на живых» данных производить невозможно, то придется моделировать ситуацию, причем быстро.

В период накопления информации проявится наибольшее количество ошибок, допущенных при создании информационной системы. Как правило, это ошибки, связанные с многопользовательским доступом. Часто на этапе тестирования таким ошибкам не уделяется должного внимания — из-за сложности моделирования и дороговизны средств автоматизации процесса тестирования информационной системы в условиях многопользовательского доступа. Некоторые ошибки исправить довольно сложно, так как они являются ошибками проектирования. Ни один самый хороший проект от них не застрахован. Поэтому надо резервировать время на локализацию и исправление таких ошибок.

Вторая категория исправлений связана с тем, что пользователя не устраивает интерфейс. Здесь не всегда нужно выполнять абсолютно все пожелания пользователя, иначе процесс ввода в эксплуатацию не кончится никогда.

В период накопления информации можно столкнуться с падением базы данных. При самом плохом раскладе окажется, что СУБД не выдерживает потока информации. При хорошем — просто параметры конфигурации неверны. Первый случай опасен, так как повлиять на производителя СУБД довольно сложно. Решая проблему отказа СУБД придется менять схему, снижать поток запросов, менять сами запросы.

Выход системы на проектную мощность при удачном стечении обстоятельств — это исправление ряда мелких ошибок, и изредка – ошибок серьезных.

Когда продукт выпущен, процесс тестирования не должен останавливаться. В данном случае происходит тестирование не только тестовой версии, но и удаленное тестирование.

1.1.7. Обобщение аналитической части

Рисунок 3 - Фазы создания продукта

На рисунке 3 показаны фазы создания продукта, которые были подробнее рассмотрены выше. В большинстве случаев компании задумываются о процессе тестирования при непосредственном написание кода продукта (см. рисунок 4, метка 1), т.е. на стадии реализации.

Тестирование

Тестирование

1

2

Рисунок 4- Возможные варианты внедрения тестирования

Подобное внедрение несет за собой:

1. хаотичное, т.е. беспорядочное тестирование;

Это вытекает из неподготовленности группы тестирования: не изучены требования, не найдены их несоответствия, не подготовлены данные для тестирования, нет плана тестирования и т.д.

2. сложность анализа ошибок, возникающих в готовом модуле;

Так нет готовой базы и схем по требованиям, то сложно понять откуда возникла данная ошибка и какие модули она может затронуть.

3. невозможность покрытия большей части функциональности;

Опять же без анализа требований сложно понять область тестирования, которую необходимо затронуть.

4. в большинстве случаев – невозможность сдать готовый продукт вовремя;

Кусочное тестирование и пропуск каких-либо важных вещей, как правило не позволяет протестировать продукт качественно в срок.

5. снижение общего качества продукта;

Из всего сказанного выше вытекает некачественные и неконкурентоспособный продукт.

6. дополнительные затраты на поддержку и решение возникших проблем,которые можно было предотвратить;

При возникновение проблем и серьезных ошибок, продукту необходимо будет большее внимание технической поддержки, что ведет к общей затрате как ресурсов, так и денежных средств.

7. снижение доверия со стороны пользователя.

При возникновении множества нареканий к продукту, а так же большое число ошибок, которые будут висеть над разработчиками, не будут решаться в кратчайшие сроки – продукт не сможет вызывать доверия и получать положительные отзывы от пользоваетелей.

Чтобы решить все эти проблемы, необходимо как можно раньше внедрять процесс тестирования. Желательно это делать на стадии анализа и сбора требований (метка №2 см. рисунок 4). Так же необходимо заранее определять план тестирования, целью которого является:

1. определение стратегии тестирования;

2. оценку требований, необходимых для осуществления тестирования, например персонала и системны ресурсов;

3. составление графиков работ.

Тестирование – это непрекращающийся процесс, сопроваждающий все этапы разработки продукта. Процессу тестирования стоит уделять такое же важное внимание в компании, как и процессу разработки.

• Тестирование должно быть неотъемлемой частью рабочего процесса.

• Должна быть выработана четкая схема взаимодействия группы тестирования с остальными группами компании.

• Тестирование не должно быть хаотичным и неподготовленным.

В данной части были рассмотрены обобщенные понятия тестирования продукта и его внедрение на различных этапах. Стоит отметить, что такие общие понятия не всегда нужны тем, кто занимается разработкой электронных курсов. В своем большинстве им необходимо получить четкий план и четкие указания по тестированию именно этой специфической области. Но для того, чтобы перейти к процессу создания оптимальных методов тестирования именно для электронных курсов необходимо немного подробнее изучить понятия и виды создания электронных курсов.