×Закрыть

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

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

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

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

LinkedIn

27 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Не зрозумів превірку:

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

А також чому

написание поискового запроса слитно | раздельно
должно вести к одному результату;

?

Достаточно полезная статья, спасибо!

Отличная статья, спасибо!

В июне 30 дней, а этим тестом проверяем есть ли валидация данных поступающих от пользователя.

В секьюрити отдельным пунктом можно добавить OWASP Top 10

берем тестовый образец и переводим через любой онлайн-переводчик (ну и все мы помним, как прекрасно и весело читать описание товаров на русском языке на AliExpress).

так собі практика. Вона лише призведе до появи перекладу як на алі.
Краще мати якийсь псевдобілд\знатийти назву стрінгу і таким чином перевіряти.

Спасибо за хорошую статья! :)

Ого. Полезно, спасибо.

Вот такие эксперты восстанавливают мою верю в КУА)
респект

Благодарю. Очень хотелось создать полезный материал.

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

Смущает ограниченность раздела Security — ни тебе sql injection, ни xss. Ни проверки на утечки sensitive данных в незащищенной форме. А ведь это поважнее pixel perfect в наше время. А так список полезный, пусть и не исчерпывающий.

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

Дочитал до писекль перфект и наложение псдэшки — загрустил )
Материал толковый, спасибо

Вы загрустили, а у меня подгорело

Я когда дочитал до pixel perfect вообще перестал читать дальше :)

Хорошая статья, детально все расписано но зачем было городить вот эту глупость?

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

Большое спасибо!
Есть где-то такое в переводе на английский(хочу дать почитать своим...) ^_^

думаю, можете перевести
тут пунктов много, но текста мало

А свои по-русски не понимают? :-)

Привет, достаточно давно есть схожий материал www.guru99.com/...​on-testing-checklist.html и его перевод software-testing.ru/...​ication-testing-checklist

После поездки список бережно сохранялся и в следующем году просто дополнялся или модифицировался

))) тоже грешу этим — частые командировки довели до списков и по сей день тьху-тьху всё учтено и возвращается домой.

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

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

Сама очень хотела бы послушать его мнение, правда даже думать об этому — очень волнительно :)

ух. спасибо за список.
тема слишком обширна для формата одной статьи :(
было бы круто зафигачить collaborative check list, что-то типа github.com/thedaviddias/Front-End-Checklist
жаль только, что оно настолько всё быстро меняется и так много сил надо — что не рационально :(

Подписаться на комментарии