Пошаговое тестирование веб приложений

Каждый раз, тестируя веб приложения, я задаюсь вопросом: «Делаю ли я это эффективно и вообще, достаточно»?

Немного объясню, почему меня это вообще беспокоит. Тестирование любого приложения состоит не только из общих практик вроде видов тестирования и тест дизайна, которые можно применить к любому ПО, но и из конкретных особенностей каждого вида приложения. К примеру, веб приложение используется только в браузере. И работает веб приложение только при наличии доступа к интернету.

Веб приложение – это по сути HTML страница, которую мы (юзеры) запрашиваем через браузер (он здесь в качестве пользователя) у сервера. Браузер получает ответ от сервера и рендерит нам HTML страницу в том виде, как мы привыкли видеть.

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

ШАГ 1. Тестируем HTML.

Вообще говоря, знание HTML – это must have для тестировщика, и здесь могут быть первые ошибки, в разметке страницы. Поэтому можно начинать с того, что проверить ресурс на соответствие стандартам HTML5, например. Типичные ошибки разработчиков могут быть такие:

• использование устаревшего HTML, что может сильно усложнить разметку (речь идет о тегах),

• использование HTML не только для описания контента, а и для его отображения,

• создание страниц с полезным контентом при полном отсутствии данных для поисковиков.

И, кстати, есть ресурсы, которые помогают нам в этом. Поэтому можно глазами пробежаться по каждой строчке страницы, а можно довериться сервису, например, https://whatwg.org/validator/.

Это, кстати, очень удобный инструмент. Вставил в соответствующее поле адрес нужного ресурса – и смотри отчет по строкам.

ШАГ 2. Тестируем CSS.

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

Как тестировщик, я отмечаю два момента:

– изменения элементов,

– взаимодействие с браузером.

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

Попробуйте воспользоваться валидатором CSS. Ведь можно автоматически проверить описание стилей, правильность названий стилей, значения стилей… Стандарты CSS можно найти на ресурсе http://www.w3.org/TR/CSS2, это текущий стандарт, либо так называемый «живой» стандарт - http://www.w3.org/TR/CSS. А вот проверить, совместимы ли с различными версиями браузеров те элементы или конструкции CSS, что используются на тестируемом сайте, можно на сайте https://caniuse.com/. Сайт полезен как для тестировщиков, так и для разработчиков. Выбирая конструкцию, можно увидеть наглядно, на каких браузерах она поддерживается. Наверное, лучше показать. Проверяю конструкцию «@font-face Web fonts», это способ отображения шрифтов, загруженных с сайтов. И вот что видим:

Есть версии браузеров, не поддерживающие ее.

Если известно, что ваши пользователи будут часто пользоваться старыми версиями браузера, и вы точно знаете, какими, то имеет смысл отталкиваться от этого. Тогда я пошла бы другим путем, и при помощи сайта http://css3test.com/ проверила бы поддерживаемые конструкции таблиц стилей по стандарту. Для этого достаточно в выбранном браузере ввести в командную строку данный сайт. На странице появится результат. И можно проверить страницу сайта на соответствие стандарту при помощи CSS-валидатора, а именно https://jigsaw.w3.org/css-validator/.

Начало положено, что же дальше? А дальше просто – информационные ресурсы имеют много (или мало) текста. Отсюда и следующий этап.

ШАГ3. Проверка текстов на ошибки. Где текст, там и ошибки. Не знаю как вам, а мне «режут глаз» ошибки-описки, особенно, некоторые.

Ошибки (грамматические, орфографические, пунктуацию) можно проверять глазами, просто вчитываясь в текст. А можно обратиться к помощникам. Я выбрала для себя расширения браузера Google Chrome, их достаточно много, но эти я считаю самыми удобными:

– yandex speller,

– language tool.

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

1. Поддержка языка приложением (меняется ли язык по умолчанию на тот, который выбираем нажатием соответствующей кнопки, идет ли переход именно на выбранный язык).

2. Правильность перевода. Хотя, конечно, если язык вы не знаете, то лучше данную часть работы доверить переводчику, иначе баг все равно не заметите.

3. Перевод надписей на картинках в локали.

4. Ссылки ведут ли на версию с выбранным языком.

5. Языковые стандарты отображения времени, дат, валют, направление текста….

ШАГ4. Проверка ссылок. То, что ссылка ведет хоть куда-то, можно проверить автоматически. Опять-таки, есть помощники. Я, например, пользуюсь в браузере Google Chrome расширением LinkMiner. Это расширение анализирует, ведут ли ссылки на ресурсе хоть куда-то, и выдает отчет по количеству ссылок на всем ресурсе и по количеству битых ссылок. Иногда он ошибается, поэтому я перепроверяю помеченные сервисом ссылки. И это гораздо меньше работы, чем могло бы быть – и спасибо ему за это.

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

Тема статьи (особенности тестирования веб приложений) напомнила мне клубок ниток – HTML, CSS, ошибки, ссылки и т.д., но я думаю, что с этого списка точно можно начать.

Надеюсь статья была вам полезна, буду благодарна за комментарии и советы):

Наталья Олейник