Фев. 06

Ничего не забыть: универсальная схема для тестирования веб-приложений

Вас часто посещает чувство что вы что-то забыли, особенно когда собираешься в спешке? Тогда вы точно поймете, о чем я говорю. Моя мама научила меня собираться по списку, который она заранее писала за несколько дней до поездки. Более того, этот список не выбрасывался, потому что обратно мы ехали и собирали вещи по этому же списку :) И должна вам сказать, мы практически никогда ничего не забывали и не теряли. После поездки список бережно сохранялся и в следующем году просто дополнялся или модифицировался. Я переняла эту привычку, и это работает! (спасибо маме).

За 12 лет в тестировании было изучено много различных техник, методик, опробовано множество инструментов, но меня не покидало чувство, что я могла что-то упустить, что можно было проверить глубже. И тут мне снова пригодилась «методика списков», только в этот раз меня на эту мысль натолкнул замечательный тестировщик и для меня — гуру тестирования, Алексей Лупан. В своем блоге он как-то поделился списками проверок некоторых функциональностей. С тех пор я веду собственные списки, каждый раз дополняя их новыми и новыми проверками, тестовыми случаями и т. д.

Уже несколько лет я обучаю тестировщиков и могу вам с уверенностью назвать три самых распространенных вопроса своих студентов:

сколько получают тестировщики?
каковы шансы, что меня возьмут на работу сразу после обучения?
какие технологии и инструменты я должен выучить?

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

Если ты Java, C#, .NET программист, тебе нужно знать Java, C#, .NET. Если ты тестировщик, тебе нужно знать теорию тестирования и то, что будет использоваться на твоем проекте.

Я сменила около 10 проектов, и все они были разными — веб, десктоп, игры, e-commerce. Каждый проект использовал различные технологии и требовал своих подходов. Поэтому приходилось учиться вместе с каждым проектом чему-то новому. Но у всех приложений есть что-то общее — это принцип работы и подход к тестированию.

Новички обычно бросаются тестировать бессистемно: кто начнет сразу ресайзить окна и смотреть не расползется ли верстка, кто-то начинает создавать аккаунт и лезет в дебри приложения. Есть у нас со студентами «разминка» из оперы «протестируйте карандаш». Так у меня родилась схема тестирования любого предмета и приложения. Ею, собственно, я и хочу поделиться.

Так, а при чем тут списки? — спросите вы. А при том, что если взять эту схему за основу, а потом «нанизать» на нее дополнительные проверки из списков — вы получите полноценное, разностороннее тестирование своего приложения и избавитесь от этого мучительного чувства, что ты что-то забыл.

Эту схему можно применить к любому приложению, но предлагаю сузить круг до тестирования веб-приложений.

GUI — >Functional — >Usability — >Security — >Performance (Load/Stress/Recovery) — >Configuration

Рассмотрим подробнее:

GUI

GUI — у любого тестируемого предмета и веб-приложения есть внешний вид, поэтому тестирование графического интерфейса или попросту, внешнего вида — это самое первое, что мы можем сделать. Сравнить его с требованиями и/или с макетом и все. Или не все? А как насчет верстки?

Верстка — размещение элементов веб-приложения (изображения, текст, кнопки, видео...) в соответствии с макетом или требованиями.

Проверяем:

наличие всех элементов;
их размер и цвет;
расположение относительно друг-друга.

Все? — Нет :) У верстки есть еще множество параметров и элементов, которые мы очень часто забываем проверить.

Сравнение с макетом — метод наложения готового эталонного макета (обычно psd-файл) на приложение в экране браузера, все несовпадения можно рассматривать как ошибки (для этого есть хороший инструмент Pixel Perfect).

Измерение размеров элемента — если это имеет значение, то померять размеры элемента и сравнить их со спецификацией можно с помощью, например Page Ruler.

Правильность шрифтов (название, размер, цвет) — WhatFont.

Цвета интерфейса — ColorZilla.

Контент — проверить на наличие орфографических и грамматических ошибок (SpellChecker).

Появление курсора — довольно часто мы забываем проверить, появляется ли вообще и как выглядит курсор в полях ввода, на кликабельных элементах.

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

Обозначение возможности переноса элементов.

Кодировка (UTF8...).

Стандарты HTML/CSS — достаточно неплохие решения для быстрой проверки предлагает W3C.

Заголовки по всему приложению должны быть приведены к одному стандарту (пример).

Title страницы — о нем мы тоже часто забываем, также как и разработчики :)

Back button — достаточно часто встречается ошибка при переходе на какую-то страницу и нажатии на браузерную кнопку Back, предыдущая страница крашится или возврат на нее вовсе не осуществляется.

Масштабируемость — особенно это важно при тестировании на смартфонах и планшетах. Где пользователь часто меняет масштаб экрана (Window Resizer), а также режим адаптивного дизайна (например в FireFox Developer Edition).

Кроссбраузерность — одна и та же страница может выглядеть по-разному в разных браузерах (пример).

Проверяем Scroll.

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

Проверить контент при отключенных (режим WebDeveloper) изображениях, flash, JavaScript.

Все? — Нет :)

Локализация — что мы знаем об этом? Обычно наши знания сводятся к невнятным «ну, это язык», «кодировка», «раскладка», еще реже «геолокация». Что еще мы так часто забываем проверять в рамках тестирования локализации?

Проверяем тестовый образец на правильность перевода — тут, конечно, хорошо бы подключить переводчика или носителя языка, но за неимением таких, берем тестовый образец и переводим через любой онлайн-переводчик (ну и все мы помним, как прекрасно и весело читать описание товаров на русском языке на AliExpress).
Длина переведенных слов — количество символов в переведенном слове может быть гораздо больше (пример), что может привести к «расползанию» интерфейса при переводе.
Сокращения/аббревиатуры — существуют правила, по которым их либо переводят, либо транслитерируют, либо оставляют как есть.
Валюта.
Параметры шрифта могут также значительно отличаться в зависимости от языка ввода.
Проверить работу поиска во всех локализациях — к примеру, на AliExpress результаты поиска одного и того же слова «смартфон» дают разный результат по количеству найденных товаров, причем разница исчисляется десятками тысяч.
Мета-информация (keywords/title/description) — столь незначительное для пользователя, невидимое, но такое важное для поисковых машин и продвижения сайта в гугле и других поисковиках.
RTL (right to left languages) — языки c обратным написанием (арабский, иврит) имеют свои особенности: числа пишутся слева направо, значки и иконки отзеркаливаются, названия программ не переводятся, нет переносов, кнопки редактирования Backspace и Delete работают наоборот.

Functional

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

Определить основные функции предмета или приложения достаточно просто — нужно понимать его назначение. Задайте себе вопрос — а для чего нужен карандаш? Занавеска? Интернет-магазин? Для чего нам на сайте нужна форма логина? Для чего нам кнопка «Купить»? И тогда все функции приложения открываются как на ладони.

Самый простой способ подготовиться к функциональному тестированию — это выписать список элементов вашего приложения и написать их целевое назначение («зачем?»).

Например:

Кнопка	Зачем?	После нажатия происходит какое-то действие.
Поле ввода		Для передачи какой-то информации и взаимодействия с приложением.
Поиск		Для того, чтобы пользователь мог быстро найти релевантную информацию.
Логин-форма		Чтобы пользователи могли иметь доступ к определенным функциям приложения (или наоборот, ограничить их доступ).
Календарь		Например, для выбора дат (билеты, бронирование и т. п.).
Дата и время		Например, расписание прибытия транспорта.
Сообщения об ошибках		Чтобы сообщить пользователю о том, что приложение работает некорректно, либо он делает некорректные действия.
Всплывающие окна и подсказки		Направить пользователя по нужному сценарию.

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

Но и тут мы можем кое-что забыть. Часто забываемые проверки функциональных элементов приложения:

Кнопки:

Enter должна срабатывать как submit;
Tab должен переводить курсор на следующий элемент.

Поля ввода:

trimming («убирание») пробелов в полях ввода;
пустота/пробелы в поле ввода;
все способы редактирования (Insert, Delete, Backspace, Ctrl+C/V/X/Z и т. д.);
дроби ( 1.5 | 1,5 | ⅕).

Поиск:

wildcard symbols (* | ?);
написание поискового запроса слитно | раздельно | через дефис должно вести к одному результату;
ввод текста в другой раскладке.

Сообщения об ошибках:

пробуем отключить в настройках браузера.

Календарь:

31 июня;
29 февраля + не высокосный год;
прошлое/будущее (например, купить билет на уже прошедшее число).

Время:

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

E-mail:

логин (63 символа) @ домен (253 символа (может быть ip)).

Всплывающие окна / подсказки:

пробуем закрыть разными способами (нажатие на кнопку (если есть), на «крестик», клавишей ESC, просто нажатием в другую область экрана);
рефреш страницы особенно в момент запроса на сервер (например, совершение транзакции по покупке) иногда может приводить к появлению ошибок.

Usability

За внешним видом и функциональностью следует удобство (Usability). Не менее важная часть, так как от нее зависит, будет ли востребован ваш продукт вообще. О каких моментах нужно помнить при тестировании usability веб-приложения?

Соответствует ли приложение ожиданиям конечного пользователя;
Логичность интерфейса;
Самое нужное «сверху»;
Продуманная навигация;
Локализация (да, да, она относится и сюда тоже);
Совместимость с другим софтом (соцсети) и железом;
Скорость работы приложения;
Информативность (сообщения / обязательные поля);
Возможность отмены действий пользователя;
Help — должна быть инструкция, как работать с приложением;
Возможность печати (если нужно).

Security

Тестирование безопасности:

Начинаем всегда с составления матрицы уровней доступа;
Конфиденциальность — никто не может получить доступ к данным несанкционированно;
Целостность данных:
а) возможность восстановить данные в полном объеме при их повреждении;
б) доступ на изменение информации только определенной категории пользователей.

Performance

Производительность:

Имитируем нагрузку пользователями (JMeter);
Пробуем загрузить большие объемы данных, файлы, медиа;
Нагружаем БД;
Понижаем скорость инета (NetLimiter);
Понижаем скорость передачи данных (Throttling);
Тестируем восстановление системы после падений.

Configuration

Конфигурационное тестирование. Тут все тоже просто:

Берем у разработчиков/заказчика список софта и железа, на котором и с которым должно работать наше приложение.
Думаем над тем, с чем еще взаимодействует приложение (например соцсети, почта, возможно, камера на телефоне и т. п.).
Выписываем это все в список (ОС, браузеры, их версии для ПК, мобильных телефонов, планшетов, также (если это важно) выписываем на каком разрешении или с какими настройками (например, для камеры съемка в режиме HD) нужно проводить тестирование).
Далее можем использовать метод классов эквивалентности, pairwise или просто руководствуемся тем, что есть в наличии, и настраиваем тестовое окружение с нужными конфигурациями.

Памятка

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

GUI	макет контент кодировка элементы (цвет, размер, расположение) локализация стандарты HTML/CSS масштабируемость курсор заголовки шрифты фавикон scroll кроссбраузерность
Functional	работа кнопок имейл регистрация/авторизация поля ввода время и дата сообщения об ошибках поиск всплывающие окна/подсказки формы заполнения календари взаимодействие всех модулей системы
Usability	навигация соответствие целям приложения печать логичность локализация help информативность совместимость с другими приложениями ожидания конечного пользователя скорость работы
Security	матрица уровней доступа протоколы передачи данных конфиденциальность информации протоколы криптования доступность информации авторизация
Performance	нагрузка имитация количества пользователей БД нагрузка стабильность «тяжелый» медиа-контент скорость выполнения запросов к БД стресс скорость интернета корректные сообщения об ошибках восстановление объем загружаемых файлов восстановление данных / системы
Configuration	сторонний софт «железо» совместимость с другими браузерами OS

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

Внешнее — > Внутренее — >Стойкость — >Взаимодействие

Внешнее — проверка внешнего вида и функций, которые доступны только обычному пользователю (GUI, Usability).

Внутреннее — все функции приложения (Functional).

Стойкость — сюда мы отнесем устойчивость приложения к нагрузкам и к попыткам нарушить его безопасность (Security, Performance (load/stress/recovery)).

Взаимодействие — работа приложения с другим софтом и железом (Configuration).

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