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

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

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

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

Похожие статьи:
Оператор мобильной связи Tele2 объявил о внедрении технологии HD-Voice в сетях 3G. Активация нового стандарта кодирования аудиосигнала...
Привіт! Мене звуть Роман Нога, я працюю Software Engineer у EPAM Ukraine (Львів). Вже не перший рік цікавлюся та слідкую за розробками...
«Якби ви могли заробляти „айтішні“ гроші у будь-якій іншій галузі, то що б обрали?» — понад 350 IT-фахівців відповіли...
Адам Леос — Senior Software Engineer в Roku. Пару лет назад он принял решение о релокации и в итоге выбрал своей целью США. Всего...
Корпорація Microsoft заявила про відбиття кібератаки на Україну з боку російського хакерського угруповання Strontium...
Яндекс.Метрика