5. Контроль качества

Контроль качества (QA). Здесь необходимо отследить и исправить все недочеты: орфографические ошибки, осиротевшие и некорректные гиперссылки, неправильно расположенное содержимое и т.д.

Процедур для контроля качества:

 Упрощенная проверка. Проверка без определенного заранее плана.

 Альфа-тестирование. Первое испытание сайта после завершения производства и настройку функциональности, но до общественного показа.

 Юзабилити-тестирование. Анализ взаимодействия пользователя с интерфейсом через действия в конкретных пользовательских задачах.

 Проверка контента. Подтверждает правильность его размещения, правописание и синтаксис.

 Бета-тестирование. Заключительная проверка перед запуском.

 Проверка загрузки. Используются специальные программы, которые моделируют одновременную работу на сайте многочисленных пользователей, чтобы определить пределы возможностей сервера.

 Проверка функциональности. Подтверждает соответствие фактических функциональных возможностей запланированным техническим требованиям.

 Проверка модулей. Проверка отдельных компонентов веб-страницы для подтверждения их правильного функционирования.

 Регрессивное тестирование. Подтверждает, что старый код работает как положено и во время устранения ошибок не внесено никаких новых проблем.

 Проверка безопасности. Подтверждает, что БД и информация транзакций защищены от неавторизованных пользователей или хакеров.

Перед проведением QA желательно составить план контроля качества.

 Резюме всех целей контроля качества, включая его методологию, график проверок и распределение ресурсов;

 Список подлежащих проверке браузеров, платформ и ОС;

 Список подлежащих проверке вариантов скоростей связи;

 Список конкретных маршрутов или функций, которые должны быть проверены;

 План проверки устраненных ошибок до запуска сайта;

15. Процесс разработки web-узла. Запуск и сопровождение.

1. Передача сайта

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

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

 Все многослойные файлы Photoshop/Fireworks;

 Шрифты (или информация о том, где их приобретать);

 Все иллюстрации и фотографию (включая информацию об авторских правах);

 HTML-страницы и шаблоны;

 Руководство по стилю оформления в HTML-формате;

 Технические спецификации;

 Корневой каталог сайта и другие необходимые файлы.

2. Запуск

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

Задолго до даты запуска необходимо продумать стратегию анонсирования сайта. Будет ли этим заниматься только внешняя команда разработчиков или это задачи и внутренней команды? Будут ли привлекаться рекламные агентства?

Ручная регистрация в ключевых поисковых системах более эффективна для продвижения сайта.

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