Грязная посуда: тестирование web-проектов

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

ТЕСТИРОВЩИК – ЭТО ПОСЛЕДНЯЯ ИНСТАНЦИЯ. ЕСЛИ ТЫ НЕ НАЙДЕШЬ БАГ,
ТО ЕГО УЖЕ НИКТО НЕ НАЙДЕТ, - ПЕРВОЕ НАСТАВЛЕНИЕ ТЕХНИЧЕСКОГО ДИРЕКТОРА.

И вот web-система готова. Тестировщик приступает к поиску багов. Тестирование сайта можно разбить на три этапа: тестирование на соответствие ТЗ и Стандартам, тестирование верстки и попытки поломать web-систему.

Тестирование на соответствие ТЗ и Стандартам

Это основной этап тестирования. Первая проблема, которая встает перед тестировщиком – разобраться в ТЗ. Вот фрагмент ТЗ, описывающий календарь событий на сайте
www.5chka.com (сайт сети магазинов «Пятерочка»):

ОТДЕЛИТЬ КАК-ТО ВИЗУАЛЬНО

«Сущности «Событие» на сайте соответствует подраздел «IR Events Calendar» в разделе «Investor Relations». Его индексная страница является списочной, на ней размещаются: календарь событий на текущий месяц и список кратких описаний событий.
Календарь представляет собой таблицу чисел текущего месяца. Если для некоторого числа месяца существует событие с датой, соответствующей данному числу, то данное число месяца является ссылкой на:

- страницу полного описания данного события, если в системе существует только одно событие с такой датой;
- на индексную страницу подраздела «IR Events Calendar» со списком кратких описаний событий на выбранную дату.

Также календарь содержит ссылки для переключения на следующий/предыдущий месяцы. 

В списке кратких описаний выводятся только активные (не скрытые) события в хронологическом порядке. По умолчанию выводятся 10 первых по дате событий, начиная с текущей даты. Каждый блок краткого описания содержит:

- дату события;
- заголовок события;
- ссылку на страницу полного описания данного события (если поле «текст» данного события не пусто)».

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

Или более сложный пример. Есть интернет-магазин. Его каталог имеет следующую структуру: существуют каталоги и подкаталоги в них (вложенность неограниченная), в каталогах и подкаталогах существуют группы товаров, в группах товаров – товары, у товаров – параметры. При этом ни одна из вышеперечисленных сущностей (кроме товаров и параметров) на сайте не выводится. А выводятся на сайте образ каталога (2 уровня вложенности) и образы групп товаров. Из каких побуждений так сделано – вопрос десятый, а запутаться здесь очень легко.

Но допустим, что ТЗ адекватно, и тестировщик разобрался во всех его тонкостях. Тогда данный этап тестирования становится достаточно банальным. На примере с календарем тестирование выглядит так:

• идешь в раздел investor relations / ir events calendar;
• читаешь, что «календарь представляет собой таблицу чисел текущего месяца», и смотришь, есть ли описанная таблица, правильно ли она составляется (проверяешь, например, количество дней в феврале в високосном/не високосном году);
• проверяешь, правильно ли формируются ссылки на числа месяца (при этом «только одно событие» означает либо «всего одно событие», либо «одно активное событие»);
•  проверяешь, как работает переключение между месяцами (особое внимание нужно уделить переключению «январь года x» на «декабрь года x-1» и обратно)
• и далее по тексту...

В ТЗ описаны все сущности, работа с ними и то, как они должны выводиться на сайте (во «front`е»). В разных web-системах бывают разные сущности, и работа с ними происходит по-разному. Так же ТЗ описывает возможности админа: можно ли добавлять новые страницы в структуру сайта, можно ли их редактировать, менять порядок их следования и тому подобное. Аналогично происходит проверка Стандартов. 

Вот реальный пример одного из Стандартов. «Для всех flash-роликов на сайте должен присутствовать статичный не-flash блок (заглушка), который отображается пользователю, если у него не установлен flash-плеер нужной версии. Обычно проверка на наличие flash-плеера и его версию осуществляется с помощью JavaScript. В данный момент существует специальная программа Flash-switcher, позволяющая пользователю выбирать, какую версию flash-плеера будут использовать браузеры. Задача тестировщика - поставить версию заведомо ниже той, которая указана в Стандарте, и проверить наличие и работоспособность заглушки».

В Стандартах описаны те аспекты работы web-системы, которые одинаковы для всех проектов.

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

Тестирование верстки, в свою очередь, разбито на два этапа: верстка динамического и статического контента. Верстка динамического контента (то есть вывод сущностей) тестируется на предыдущем этапе (на соответствие ТЗ). Верстку же статического контента можно назвать «общей» версткой, так как к ней относится и общий графический обвес сайта.

Тестирование верстки (статической ее части) представляет собой просмотр сайта на разных разрешениях экрана (от 800x600 до 2048x1536) и в разных браузерах. Список браузеров обычно определен в Стандартах, но иногда клиенты выдвигают особые требования. Вот «классический» список браузеров:

• Internet explorer версии 5.0 и выше
• Mozilla Firefox 1.0.1 и выше
• Mozilla 1.3 и выше
• Opera 7.54 и выше (крайне редко opera 6.0)

Еще полгода назад в этом списке присутствовал Netscape 7.0, а иногда клиенты (особенно европейские и международные компании) требуют Safari. Верстка в разных браузерах может отличаться разительным образом. Простой пример: FireFox и Internet Explorer (два самых популярных браузера на сегодняшний день) по-разному обрабатывают внутренний и внешний отступы элементов страницы.

При тестировании верстки очень удобно пользоваться так называемыми, «валидаторами» (от англ. validate – сверять). Валидаторы проверяют корректность верстки по стандартам W3C – общепринятым стандартам в WWW (отсюда и W3). Подробнее о стандартах можешь узнать на сайте
www.w3.org. Наиболее удобный валидатор - TIDY HtmlValidator, являющийся расширением (плагином) FireFox. Он проверяет страницу в процессе ее отображения. Выглядит это следующим образом. В статусной строке браузера отображается иконка TIDY, принимающая три различных вида (в зависимости от количества и типа найденных ошибок). При наведении курсора мыши появляется более детальная информация, а после двойного щелчка открывается исходный код с описанием ошибок.

Зачастую валидатор позволяет выявить скрытые ошибки, которые могут проявиться только при определенном стечении обстоятельств. Например, для новостей выводятся Заголовок, Картинка и Анонс. И при длине анонса первой новости более 300 символов картинка второй новости куда-нибудь «уезжает».

Тестирование верстки одновременно представляет собой и тестирование дизайна, так как верстальщики обычно руководствуются не ТЗ, а дизайн-макетами. Если дизайнер нарисовал что-то лишнее или забыл нарисовать что-то нужное – это, естественно, баг.

Попытки поломать web-систему

Есть легенда о тестировщице. Девушка устраивалась тестировщицей в некую компанию, и ее попросили продемонстрировать способности к тестированию. Девушка подошла к настольной лампе, выключила ее из розетки, поставила выключатель в положение между «включено» и «выключено» и воткнула вилку обратно в розетку. Лампа перегорела, и девушку взяли на работу. У хорошего тестировщика должен быть дар ломать все, к чему он ни притронется. Потому что если у web-системы есть слабое место, легкий удар в которое «уронит» ее, то этот удар обязательно произойдет.

На данном этапе тестирования нужно делать с web-системой все: в CMS задавать предельные значения для сущностей (например, в текст новости вставить три тома «Войны и Мира»), в динамический контент вставлять длинные строки без пробелов (браузер переносит текст, используя в качества места разрыва пробел, следовательно, длинная строка без пробела будет растягивать сайт), вставлять в динамический контент различные «нехорошие» данные (например, JavaScript или спецсимволы &, ‘, ` и “ – они могут вызвать ошибку при работе с базой данных) и т.д. Это первое, что приходит в голову. Список этот можно продолжать очень долго, и именно в этом заключается талант тестировщика.

Тестовый контент

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

1. Тестовый контент должен быть корректен с морально-этической точки зрения - он не должен содержать слов и выражений на грани цензуры, и тем более нецензурных (чем нередко грешат разработчики и тестировщики). В идеале, тестовый контент должен лишь показывать, что он собой представляет. Например, для новости стоит задавать параметры следующего вида. Заголовок – «я заголовок новости», Анонс – «а я - ее анонс», Текст – «а я текст новости, я должен быть мало-мальски длинным, потому что так оно обычно и бывает...» и все в таком духе. Естественно, с некоторыми вариациями, чтобы отличать одну новость от другой.
2. Тестовый контент должен явно отличаться от реального контента. Приведенный пример с новостью в этом плане не очень хорош. Он не бросается в глаза. Вопрос о том, как выделить тестовый контент, решается «по ситуации». Например, если у новости есть еще и поле Картинка, то достаточно всем тестовым новостям задать яркую картинку (явно выделяющуюся из дизайна) с надписью «test». Или можно просто начинать все поля префиксом «AHTUNG! TEST!» или подобным.

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

Систематизация багов, bug-tracking

И вот, наконец, все баги найдены. Теперь нужно их систематизировать. Для этого существуют так называемые «баг-трекеры» – программы, ведущие историю багов. Чаще всего баг-трекеры представляют собой web-системы, устроенные по принципу форумов или блогов. Разберемся в систематизации багов на примере баг-трекера
Mantis.

Первый уровень систематизации багов – это проекты (сайты). Вполне логично отделять баги одного сайта от багов другого сайта. К проекту «привязаны» баги, которые имеют еще несколько уровней систематизации. На них остановимся подробнее.

Статус бага дает представление о том, какие меры по исправлению были приняты. При добавлении бага его статус определяется как «новый». Разработчик исправляет баг и определяет его статус как «решен». После этого тестировщик проверяет, действительно ли решен баг. И если баг решен, определяет его статус как «закрыт».

Категория бага – очень важное свойство для оптимизации трудозатрат. Для каждого проекта тестировщик может задать произвольный набор Категорий. Чаще всего используются:

• Программирование
• Верстка
• Дизайн (в основном баги о несоответствии дизайн-макетов тз)
• Flash (все, что касается flash-роликов)
• Контент (все, что касается динамического контента: опечатки, орфографические, стилистические ошибки и т.п.)
• Правка тз (ошибки в тз)
• Вопрос (вопросы к продюсеру проекта)
• Не баг (в эту категорию попадают «памятки» и предложения оптимизации)

Правильно определенная категория бага значительно сокращает время на «поиск крайнего», но это не такая простая задача, как кажется на первый взгляд. Категории «Flash», «Контент», «Правка ТЗ», «Вопрос» и «Не баг» определяются без проблем. В категорию «Дизайн» баги, как правило, переходят из категории «Верстка». Трудности возникают при выборе между «Программированием» и «Версткой». Дело в том, что программист должен корректно вывести данные, а верстальщик – оформить их.

Пример 1: Новости должны выводиться в хронологическом порядке, но они выводятся хаотично – явный баг программирования.

Пример 2: Заголовок новости должен быть выделен жирным шрифтом, а он выделен курсивом – явный баг верстки.

Пример 3: Для новостей должен выводиться анонс, но он не выводится. Возможно, программист забыл вывести анонс, а возможно, верстальщик неправильно его оформил и вследствие ошибки на уровне HTML анонс не отображается. 

И если ошибиться с категорией, то разработчик потратит некоторое время на поиски несуществующей ошибки. А теперь умножь «некоторое время» на количество багов... Вывод очевиден.

Баг-трекер Mantis также позволяет добавлять комментарии к багам (что бывает весьма полезно), назначать баги конкретным разработчикам (что бывает полезно при работе в группе), следить за багами (получать уведомления обо всех изменениях бага, что полезно для продюсеров). 

Типичные баги

Для начала немного статистики. Независимые статистические исследования в компании DEFA Gruppe выявили несколько интересных фактов:

1. Отношение количества багов ко времени,
   затраченному на разработку сайта, у
   программистов и верстальщиков совпадает
   до сотых! То есть верстальщики и
   программисты «плодят» баги с одинаковой
   скоростью.
2. Количество багов по одному проекту
   прямо пропорционально объему работ по
   этому проекту, а отнюдь не сложности
   работ.
3. У каждого третьего бага с категорией «программирование»
   или «верстка» категория менялась.
4. Баги исправляются в порядке стека. То
   есть баг, добавленный первым, будет
   исправлен последним.

Топ типичных багов

1. Причина львиной доли багов – это
   невнимательность разработчиков при
   чтении тз. Эти баги легко обнаруживаются
   и быстро исправляются. 
2. На втором месте по популярности идут
   баги верстки, связанные с некорректным
   отображением страниц сайта в отличных от
   internet explorer`а браузерах. Эти баги связанны с
   тем, что у верстальщиков просто не
   хватает времени просмотреть сайт во всех
   браузерах. Такие баги тоже легко
   обнаруживаются, но уже не так легко
   правятся.
3. Третье место за нестандартными багами.
   Это баги, которые сложнее всего
   обнаружить и достаточно сложно исправить.
   Пример из жизни. В списке новостей
   выводится 10 последних новостей. Три раза
   перезагружаем страницу – все корректно.
   На четвертый раз новости исчезают. Такие
   баги, как правило, связаны с логическими
   ошибками программистов или с багами
   браузера. Например, известный баг internet
   explorer`а: при определенной вложенности
   тегов <div>, internet explorer создает
   дополнительный вертикальный отступ в три
   пикселя, от которого очень тяжело
   избавиться.
4. Существуют также баги «юзабилити»,
   встречающиеся на каждом шагу. Но понятие
   юзабилити (ака user friendly, ака дружественный
   интерфейс) – очень субъективное понятие.
   Такие баги решаются либо по согласованию
   с продюсером, либо по согласованию с
   клиентом. Но чтобы исправить баг, его
   нужно найти! И вот тут тестировщик должен
   включать у себя в голове «лимитатор iq» и
   входить в роль домохозяйки,
   придирающейся к каждому пикселю.
   Например, удобно ли организованно меню,
   очевидны ли функции пиктограмм типа «написать
   письмо», «на главную» и тому подобное.
5. Особняком стоят баги, связанные с
   ветвлением сайта на различные контент-версии:
   различные языковые версии, версия для
   печати, версии с различным графическим
   обвесом и т.п. как правило, для языковых
   версий забывают что-нибудь перевести, а в
   версии для печати (и различных
   графических версиях) остаются ненужные
   элементы графического обвеса.

Немаловажно и количество тестов сайта. Сайт должен быть в среднем протестирован четыре раза. Первый тест проводится, когда web-система готова. Второй тест проводится после того, как все баги исправлены (потому что правим программную часть – отваливается верстка, правим верстку – отваливаются Java-скрипты). Третий тест проводится, когда сайт заполнен реальным контентом. И четвертый тест (беглый) проводится после того, как сайт открыт на реальном хостинге и на него хлынул поток пользователей.

Два слова об автоматизации процесса тестирования. Ни одна программа не способна протестировать сайт. Тестирование – это творческий процесс. Единственное, что можно автоматизировать – это проверка верстки на соответствие стандартам W3C. Ну и, пожалуй, тестирование уязвимости сайта (SQL-инъекции, DoS-атаки и т.п.).

И в заключение народная мудрость: если тебя не любят разработчики, значит, ты - хороший тестировщик!