♛ FORTRESS-DESIGN

Разработка сайта: итоговое тестирование

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

Работая менеджером проекта со стороны заказчика и хорошо понимая, что сейчас происходит в агентстве, которое выступало подрядчиком, я каждый день наблюдала, как директор по маркетингу бегала по потолку с криками: «Они нас кинут!». Это вам, господа профессионалы, маленькая иллюстрация того, что чувствует человек, ответственный за бюджет, после того, как он вам этот самый бюджет отдал.

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

Через две-три недели после того, как вы утвердили дизайн, вам пришлют ссылку на сайт. На ваш сайт… У него будет не тот адрес, который вы планировали, но он будет (пусть и не полностью) работать. Сайт нужно оттестировать.

В теории все звучит хорошо. Однако практика от теории несколько отличается. В теории предполагается, что сайт передается заказчику сразу и весь. В реальности передача происходит постепенно. Делается это, потому что агентству хочется, во-первых, как можно быстрее показать результат, а во-вторых, сэкономить на тестировании. Часть багов заказчик способен выловить и сам. Значит, сотрудники агентства потратят меньше своего времени.

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

Как же быть менеджеру проекта со стороны заказчика?

Не стоит показывать первые версии своему руководству. Тестируйте сами. Привлекайте друзей. Директоров с промежуточными результатами лучше не знакомить. Потому что промежуточные результаты всегда далеки от того, что предполагалась в начале, и точно также они далеко от конечного продукта.

Если сайт сдают по частям, как тогда их тестировать?

  1. Вспоминаете все свои пометки, которые вы планировали посмотреть после сборки. Сделано ли то, что было запланировано?
  2. ТЗ, как вы помните, должно было быть написано помодульно. Отдельно в нем же должны был быть описана схема доступа, а также функционал системы администрирования (CMS). Именно на этапе общего тестирования вы начинаете понимать, зачем вы так долго и подробно описывали все моменты. Потому что, имея на руках документацию и результат, вы можете их сравнить.
  3. Вы одновременно работаете с ТЗ, дизайн-шаблонами и итоговым сайтом. Все расхождения заносите в отдельный файл, который называется баг-трекинг.

На что стоит обращать внимание:

1. Работающие/не работающие элементы

2. Доступ: все ли функции по разграничению прав на редактирование различных страниц реализованы?

3. Кросс-браузерность

Есть специальные программы, которые позволяют тестировать сайт в различных версиях браузеров. Но это как раз та часть тестирования, которую должно обеспечить агентству. Вам будет достаточно поставить себе Internet Explorer 6.0 или 7.0 (одновременно они ставятся, но очень трудно), Opera 9 и третий Firefox и по очереди протестировать сайт в каждом из них.

4. Система администрирования

5. Общее оформление

6. Реализация функционала

Как описывать и как передавать найденные ошибки агентству?

Составьте единый документ, в который вы будете вносить все ошибки, найденные на сайте. Выглядеть он будет примерно так:

Этот документ вы перешлете агентству. Агентство ошибки исправит. Вы оттестируете сайт по новой, обращая внимания прежде всего на те моменты, которые были указаны в баг-трекинге. В процессе повторного тестирования вылезут новые баги… Таких итераций обычно около трех. Но бывает и больше.

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

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

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

Источник: «Вебпланета»