Что искать
Чаще всего сама команда лучше знает, что искать. Можно в поиске проблем быстро просмотреть узел (что не рекомендуется) или останавливаться на всех его элементах, от рисунков до программ (это гораздо лучше). Ниже предлагается обобщенный список элементов, в которых нужно проводить поиск ошибок.
Выполняйте поиск ошибок на более низком уровне, чем на это способен клиент. Все ли ссылки ведут туда, куда нужно? Все ли замещения отображают правильные рисунки?
Убедитесь, что страницы выглядят однообразно во всех современных броузерах. В последних версиях броузеров Internet Explorer и Netscape они должны выглядеть практически идентично.
В более старых броузерах должно быть не заметно значительного искажения страниц. Другими словами, функции, недоступные в более старых версиях, не должны вызывать ошибки, а на страницах не должно быть особо заметно, что что-то отсутствует. Если в старом броузере не заметно влияние отсутствия отдельных функций при загрузке страницы, это значит, что ее разработчик затратил время на тестирование разными броузерами.
Используйте функции именно для того, для чего они создавались. Например, зачем применять состояние Over While Down к кнопке, которая не имеет подчиненного меню?
Убедитесь, что конструкция не привязана жестко к каким-либо условиям. То, что хорошо смотрится на 21-дюймовом мониторе, может не работать на 17-дюймовом.
Убедитесь, что база данных оптимизирована. Удалите из нее те элементы, которые не используются.
Убедитесь, что динамические программы работают правильно. Например, проверьте, как распределяется текст описания продукции в динамическом текстовом Flash-поле таблицы.
Проверьте эффективность выражений SQL. Например, не рекомендуется выбирать из таблицы всю ее информацию. Это только замедляет процесс обработки запроса.
Проверьте, не используется ли JavaScript там, где более уместным было бы использование программ заднего плана. Очень многие для выполнения действия в форме используют конструкцию mailto:URL. Проблема здесь состоит в том, что не все могут использовать формы таким образом. Вместо такой конструкции лучше использовать дескриптор ColdFusion CFMAIL
Строгость проверки зависит от компании и состава проекта. Вот пять вопросов, на которые нужно обратить внимание после того, как клиент и бета-команда завершат свою работу.
Работает ли конструкция так, как планировалось? Заставьте дизайнеров еще раз пройтись по страницам узла в поиске размещенного в неподходящем месте текста или рисунка, допускающего неверную трактовку. Это нужно выполнить на компьютерах PC и Мае.
Выполняет ли программа HTML то, для чего создавалась? Проверьте наличие неправильно состыкованных таблиц, ссылок, которые нельзя идентифицировать как ссылки, и т.п. Эту операцию также следует выполнить на компьютерах PC и Мае.
Работает ли узел? Все ли функции, заложенные в Web-узел, соответствуют своей технической спецификации, определенной в начале производственного процесса? Если вы работаете над динамическим узлом, разместите его на сервере, на котором он предположительно будет опубликован.
Все ли материалы находятся на своем месте? Например, убедитесь, что заголовки выглядят как заголовки, а текст на странице разборчив и понятен.
Существует ли кто-либо на стороне клиента, кто способен препятствовать подписанию акта приемки узла? У каждого Web-дизайнера есть своя история о том, как был создан громадный по объему узел, который не был принят только потому, что исполняющий обязанности начальника отдела маркетинга его не хотел утверждать. А все произошло потому, что до последнего момента никто не знал, что последнее слово будет именно за ним.
Содержание раздела
