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

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

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

За 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, Usability).

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU