Сценарий тестирования сайта пример

Сайт с багами – горе для бизнеса. Всего одна 404-я или 500-я ошибка может лишить вашу компанию солидной суммы денег и хорошей репутации. Но есть способ избежать этого: тестировать сайт. О том, как это сделать, расскажет данная статья. Прочитав её, вы узнаете, как тестировать код на Django, создать своего пользователя-тестировщика и много чего ещё. Добро пожаловать под кат.

UPD:
Часть 2. JavaScript и русский текст на английских страницах
Часть 3. Отправка результата на почту, TestExplorer и декоратор tag

Что вы делаете, когда пишете тесты?

Как бы вы ответили на этот вопрос? Я бы сказал – кайфую. У каждого разработчика есть своё мнение на счёт тестов. Лично мне этот процесс безумно нравится. Благодаря ему я могу не только писать более надёжный код, но и начинаю лучше разбираться в своих и чужих программах. А вишенкой на торте является чувство, испытываемое, когда все тесты становятся зелёными. В этот момент моя шкала перфекционизма достигает своего апогея.

Иногда при тестировании меня затягивает так, будто я прохожу Half-Life. Я начинаю проводить за этим процессом всё рабочее и свободное время. Конечно, со временем тесты надоедают, и тогда приходится делать перерыв. После чего опять можно стать ноулайфером на несколько недель, будто Valve выпустила новую часть. Если у вас также, то вы понимаете, о чём я. Но хватит разговоров, перейдём к делу!

Тестирование бэкенда

Наш сайт написан на Django, поэтому примеры кода указаны для этого фреймворка.

Перед началом советую ознакомиться со списком рекомендаций, которые структурируют и делают более комфортным процесс написания тестов. Я сформировал их за счёт советов других программистов и личного опыта.

• Файлы с тестами хранятся в папке tests внутри приложения;

• тесты моделей, вьюх и форм лежат в файлах test_models.py, test_views.py и test_forms.py соответственно;

• название тестового метода начинается с префикса test_ (например, test_get_sum или test_status_code);

• название класса, содержащего тесты, имеет вид: ТестируемаяСущностьTests (например, TrialTests или FeedbackFileTests).

Тестирование моделей

Создадим приложение my_app и заполним файл models.py следующим кодом:

from django.db import models

class Trial(models.Model):
    """Простая модель пользовательского триала"""

    email = models.EmailField(
        verbose_name='Электронная почта',
        max_length=256,
        unique=False,
    )

    def __str__(self):
        return str(self.email)

    class Meta:
        verbose_name = 'Триал'
        verbose_name_plural = 'Триалы'

Эта модель – упрощённая версия нашей модели Trial. Вот, что мы можем у неё проверить:

1. У поля email параметр verbose_name – «Электронная почта».

2. У поля email параметр max_length – 256.

3. У поля email параметр unique – False.

4. Метод str возвращает значение параметра email.

5. Параметр verbose_name модели – «Триал».

6. Параметр verbose_name_plural модели – «Триалы».

От некоторых программистов мне приходилось слышать мнение, что тестирование моделей – бесполезная трата времени. Но мой опыт подсказывает, что это мнение ошибочное. Приведу простой пример. Для поля email мы указали максимальную длину – 256 (в соответствии с документом RFC 2821). Случайно удалить последнюю цифру – не большая проблема. Если такая оплошность вдруг произойдёт, то пользователь с почтой my_super_long_email@gmail.com (29 символов) получит ошибку и не сможет отправить запрос на триал. А значит, компания потеряет потенциального клиента. Конечно, можно написать дополнительную валидацию, но лучше быть уверенным, что и без неё программа успешно работает.

Перейдём к тестам и сначала решим, где они будут находиться. Вы можете писать все тесты в одном файле tests.py (Django добавляет его при создании приложения) либо последовать рекомендациям выше и разделить их.

Если второй вариант вам импонирует больше, то удалите tests.py. Затем создайте папку tests с пустым файлом __init__.py. При запуске тестов он скажет Python, где их искать. Сюда же добавляем еще 3 файла: test_forms.py, test_models.py и test_views.py. Содержимое директории приложения будет примерно таким:

Открываем файл test_models.py и добавляем в него следующий код:

from django.test import TestCase

from my_app.models import Trial

class TrialTests(TestCase):
    """Тесты для модели Trial"""

    def test_verbose_name(self):
        pass

    def test_max_length(self):
        pass

    def test_unique(self):
        pass

    def test_str_method(self):
        pass

    def test_model_verbose_name(self):
        pass

    def test_model_verbose_name_plural(self):
        pass

У Django для тестирования есть специальный модуль django.test. Один из самых важных его классов — TestCase. Именно он и позволяет писать тесты. Чтобы это сделать, нам нужно просто наследовать наш класс от TestCase.

Все наши тесты – это методы класса TrialTests. Пока они ничего не делают, но это ненадолго. Каждый из них будет тестировать по одному условию из списка выше.

Разберёмся с запуском тестов. Чтобы разом выполнить все тесты вашего сайта, введите эту команду в консоли:

python manage.py test

Для запуска тестов конкретного класса, например TrialTests, пишем:

python manage.py test my_app.tests.test_models.TrialTests

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

Из него видно, что за 0.001 секунду проверено 6 тестов. «OK» в конце вывода говорит об их успешном выполнении.

Теперь напишем настоящие тесты. Чтобы это сделать, нам придётся обращаться к параметрам объекта модели Trial. Значит, нужно создать этот объект. И тут важно знать, что для тестов Django использует отдельную чистую базу. Перед прогоном тестов она создаётся, после — удаляется. На скриншоте выше об этом говорят первая и последняя строчки. Если вдруг по какой-то причине база не смогла удалиться, Django скажет об этом и придётся снести её вручную.

Чтобы работать с этой базой, можно использовать 3 метода:

1. setUp – выполняется перед запуском каждого теста;

2. tearDown – выполняется после завершения каждого теста;

3. setUpTestData – выполняется перед запуском всех тестов конкретного класса.

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

class TrialTests(TestCase):
    """Тесты для модели Trial"""

    @classmethod
    def setUpTestData(cls):
        """Заносит данные в БД перед запуском тестов класса"""

        cls.trial = Trial.objects.create(
            email='test@gmail.com'
        )
        cls.email_field = cls.trial._meta.get_field('email')

Теперь при запуске тестов класса TrialTests в новой базе будет создаваться объект trial. После прогона он будет удаляться.

Напишем тест параметра verbose_name.

def test_verbose_name(self):
    """Тест параметра verbose_name"""

    real_verbose_name = getattr(self.email_field, 'verbose_name')
    expected_verbose_name = 'Электронная почта'

    self.assertEqual(real_verbose_name, expected_verbose_name)

Из поля email_field мы извлекаем значение параметра verbose_name. Затем применяем метод assertEqual из класса TestCase. Он сравнивает два параметра – реальное и ожидаемое значения verbose_name. Если они равны, тест отработает удачно. В противном случае – упадёт.

Напишем такие же тесты для параметров max_length и unique.

def test_max_length(self):
    """Тест параметра max_length"""

    real_max_length = getattr(self.email_field, 'max_length')

    self.assertEqual(real_max_length, 256)

def test_unique(self):
    """Тест параметра unique"""

    real_unique = getattr(self.email_field, 'unique')

    self.assertEqual(real_unique, False)

Тут всё так же, как и с verbose_name.

Кстати, в тесте параметра unique мы проверяем, что значение равно False. Можно сделать это проще с помощью команды assertFalse. Перепишем код этого теста.

def test_unique(self):
    """Тест параметра unique"""

    real_unique = getattr(self.email_field, 'unique')

    self.assertFalse(real_unique)

Код немного уменьшился и стал более читабельным. Кстати, у Django много таких полезных assert-ов.

Теперь проверим строковое отображение объекта.

def test_string_representation(self):
    """Тест строкового отображения"""

    self.assertEqual(str(self.trial), str(self.trial.email))

Тут всё просто. Проверяем, что строковое отображение объекта равно его электронной почте.

И последнее – это тесты полей модели:

def test_model_verbose_name(self):
    """Тест поля verbose_name модели Trial"""

    self.assertEqual(Trial._meta.verbose_name, 'Триал')

def test_model_verbose_name_plural(self):
    """Тест поля verbose_name_plural модели Trial"""

    self.assertEqual(Trial._meta.verbose_name_plural, 'Триалы')

Через _meta обращаемся к полям модели Trial и сравниваем их значение с ожидаемым.

Если сейчас запустить тесты, то они успешно отработают, как и раньше. Но ведь так неинтересно! Давайте что-нибудь сломаем. Пусть нашей жертвой станет параметр verbose_name модели Trial. Откроем её код и поменяем значение этого поля с «Триал» на «Что-то другое». Прогоним тесты.

Как видим, один из тестов упал. Django говорит об этом и о том, что реальное значение поля («Что-то другое») не равно ожидаемому («Триал»).

Миксины – полезные ребята

Тесты моделей – однотипны. Поэтому, когда у вас много сущностей, тестировать их не самая приятная рутина. Я попробовал несколько упростить данный процесс с помощью миксинов. Мой способ неидеален, и я не настаиваю на его использовании, но, возможно, он вам будет полезен.

Думаю, вы заметили, что при тестировании полей verbose_name, max_length и unique прослеживается некоторое дублирование кода. Мы получаем значение поля объекта и сравниваем его с ожидаемым. И так во всех трёх тестах. А значит, можно написать общую функцию, выполняющую эту работу.

def run_field_parameter_test(
        model, self_,
        field_and_parameter_value: dict,
        parameter_name: str) -> None:
    """Тестирует значение параметра для всех объектов модели"""

    for instance in model.objects.all():
        # Пример 1: field = "email"; expected_value = 256.
        # Пример 2: field = "email"; expected_value = "Электронная почта".
        for field, expected_value in field_and_parameter_value.items():
            parameter_real_value = getattr(
                instance._meta.get_field(field), parameter_name
            )

            self_.assertEqual(parameter_real_value, expected_value)

Разберёмся с параметрами. С model, думаю, всё понятно. self_ нужен только для вызова метода assertEqual. Поскольку self — это ключевое слово в Python, то мы добавляем к нему _, чтобы не произошло недопонимания. field_and_parameter_value — это словарь с полем и значением его параметра. Например, если мы проверяем параметр max_length, то можно в эту переменную передать email и 256. Если проверяем verbose_name, то передаём email и «Электронная почта». parameter_name — это тестируемый параметр: max_length, verbose_name и т.д.

Теперь обратимся к коду. Вначале мы получаем все объекты модели и проходимся по ним. Дальше обходим словарь с полями и ожидаемыми значениями параметров. После получаем реальные значения параметров, обращаясь к объекту. А затем сравниваем их с ожидаемыми. Код очень похож на ранее написанный в тестах. Только теперь это всё в одной функции. Кстати, если бы её имя начиналось с префикса test, Django принял бы её за реальный тест и пытался бы выполнить вместе с остальными.

Напишем миксины. Для каждого поля должен быть свой миксин. Для примера возьмём поля verbose_name и max_length.

class TestVerboseNameMixin:
    """Миксин для проверки verbose_name"""

    def run_verbose_name_test(self, model):
        """Метод, тестирующий verbose_name"""

        run_field_parameter_test(
            model, self, self.field_and_verbose_name, 'verbose_name'
        )

class TestMaxLengthMixin:
    """Миксин для проверки max_length"""

    def run_max_length_test(self, model):
        """Метод, тестирующий max_length"""

        run_field_parameter_test(
            model, self, self.field_and_max_length, 'max_length'
        )

Мы создаём нужный метод и в нём вызываем нашу общую функцию с соответствующими параметрами. self.field_and_verbose_name и self.field_and_max_length берутся из класса, который наследуется от миксина. А именно – из метода setUpTestData класса TrialTests.

@classmethod 
def setUpTestData(cls): 
    # ...
    cls.field_and_verbose_name = {
        'email': 'Электронная почта',
    }

    cls.field_and_max_length = {
        'email': 256,
    }

Наследуем класс TrialTests от наших миксинов.

class TrialTests(TestCase, TestVerboseNameMixin, TestMaxLengthMixin):
    # ...

Если у вас будет много миксинов – их можно объединить, например, в кортеж и при наследовании распаковывать его.

MIXINS_SET = (
    TestVerboseNameMixin, TestMaxLengthMixin,
)

class TrialTests(TestCase, *MIXINS_SET):
    # ...

Теперь можно переписать наши тесты:

def test_verbose_name(self):
    """Тест параметра verbose_name"""

    super().run_verbose_name_test(Trial)

def test_max_length(self):
    """Тест параметра max_length"""

    super().run_max_length_test(Trial)

Когда у вас много тестов для разных моделей, этот способ оказывается весьма полезным.

Тестирование логики

Перейдём к тестам кода из views.py. Возьмём для примера функцию получения домена из имейла.

def get_domain(email: str) -> str:
    """Возвращает домен имейла"""

    try:
        _, domain = email.split('@')
    except ValueError:
        domain = ''

    return domain

Таким может быть её тест:

from django.test import TestCase

from my_app.views import get_domain

EMAIL_AND_DOMAIN = {
    'test1@gmail.com': 'gmail.com',
    'test2@wrong_email': 'wrong_email',
    'test3@mail.ru': 'mail.ru',
    'test4@@wrong_email.com': '',
}

class FunctionsTests(TestCase):
    """Класс с тестами функций"""

    def test_get_domain(self):
        """Тест функции get_domain"""

        for email, expected_domain in EMAIL_AND_DOMAIN.items():
            real_domain = get_domain(email)

            self.assertEqual(real_domain, expected_domain)

В константе хранятся имейлы и их реальные домены. В тесте мы по ним проходимся, получаем домен с помощью тестируемой функции и сравниваем с ожидаемым.

Теперь немного поговорим про одну полезную конструкцию. Давайте как-нибудь изменим наши имейлы. Например, исправим test1@gmail.com на test1@habr.com, а test2@wrong_email на test2@habr. Запустим тесты.

Они ожидаемо упали. Но почему мы видим, что некорректен только один имейл, хотя мы меняли два? Дело в том, что по умолчанию Django не будет продолжать тестирование, если произошёл фейл. Он просто прекратит прогон тестов, будто команда break, вызванная внутри цикла. Этот факт вряд ли может порадовать, особенно если у вас тесты такие же долгие, как вечерняя поездка по МКАД. Но, к счастью, есть решение. Нам поможет конструкция with self.subTest(). Она указывается после объявления цикла.

# ...
for email, expected_doamin in EMAIL_AND_DOMAIN.items():
    with self.subTest(f'{email=}'):
        real_domain = get_domain(email)

        self.assertEqual(real_domain, expected_doamin)

В скобках метода subTest мы указываем строку, которую хотим вывести, когда тест упадёт. В данной ситуации это проверяемый имейл.

Теперь при любом фейле Django сохранит отчёт о нём и пойдёт дальше. А после завершения прогона выведет информацию по всему, что упало.

Разберём тест ещё одной функции. При получении от пользователя промокода мы преобразовываем его в более удобный вид – убираем символы «#» и пробелы. Для этого у нас есть функция get_correct_promo:

def get_correct_promo(promo: str) -> str:
    """Возвращает промокод без # и пробелов"""

    return promo.replace('#', '').replace(' ', '')

Так может выглядеть тест для неё:

from django.test import TestCase

from my_app.views import get_correct_promo

PROMO_CODES = {
    '#sast': 'sast',
    '#beauty#': 'beauty',
    '#test test2': 'testtest2',
    'test1 test2 test3': 'test1test2test3',
}

class FunctionsTests(TestCase):
    """Класс с тестами функций"""

    def test_get_correct_promo(self):
        """Тест функции get_correct_promo"""

        for incorrect_promo, correct_promo in PROMO_CODES.items():
            real_promo = get_correct_promo(incorrect_promo)

            self.assertEqual(real_promo, correct_promo)

В константе хранятся некорректные и корректные промокоды. В тесте мы по ним проходимся, и сравниваем промокод, полученный с помощью функции get_correct_promo и действительно корректный промокод.

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

Тесты форм

Тесты форм похожи на тесты моделей. В них мы также можем проверять поля и методы.

Создадим форму модели Trial:

from django import forms

from my_app.models import Trial

class TrialForm(forms.ModelForm):
    """Форма модели Trial"""

    class Meta:
        model = Trial
        exclude = ()

Одним из примеров тестов для неё может быть этот код:

from django.test import TestCase

from my_app.forms import TrialForm

class TrialFormTests(TestCase):
    """Тесты формы TrialForm"""

    def test_field_labels(self):
        """Тест лейблов полей"""

        form = TrialForm()
        email_label = form.fields['email'].label

        self.assertEqual(email_label, 'Электронная почта')

В нём мы создаём объект нашей формы и сравниваем label поля с ожидаемым. Примерно так можно писать тесты для форм. Но мы их почти не используем. Для этого есть более эффективный способ, о котором я расскажу в следующей части.

Свой пользователь-тестировщик

Итак, backend-часть вашего сайта протестирована. Но вдруг на одной из его страниц вы заметили 404-ю ошибку. Написанные тесты не нашли её. Они также не помогут, например, при поиске битых ссылок на страницах. Эти тесты просто не рассчитаны на баги такого рода. Но как тогда их отлавливать? Для этого нужны тесты, имитирующие действия пользователя. Можно использовать django.test.Client, но он позволяет запускать тесты только на самом сервере сайта, а это не всегда удобно. Поэтому обратимся к Python библиотеке requests.

Данные тесты обычно получаются объёмными, поэтому их лучше вынести в отдельный файл (или файлы), например test_requests.py.

Проверка статус-кодов

Для проверки статус-кода страницы нужно:

1. Зайти на страницу;

2. Получить её статус-код;

3. Проверить, что статус-код равен 200.

У библиотеки requests много полезных методов. В выполнении 1-го и 2-го пунктов нам поможет head. С его помощью мы будем отправлять HEAD-запрос на страницы сайта.

from requests import head

Нам достаточно передать в него лишь URL-адрес, чтобы получить ответ со всей нужной информацией о странице. А из этой информации можно извлечь статус-код:

response = head('<URL-адрес страницы>')
print(response.status_code)

Теперь перейдём к написанию теста. Создадим константу с тестируемыми страницами. Для простоты возьмём домен только русской версии.

DOMAIN = 'https://pvs-studio.com/ru/'

PAGES = (
    '',
    'address/',
    'pvs-studio/',
    'pvs-studio/download/',
    # ...
)

PAGES = (DOMAIN + page for page in PAGES)

Конечно, в идеале относительные пути страниц лучше брать из базы. Но если такой возможности нет – можно обойтись обычным кортежем.

Добавим класс PagesTests вместе с тестом test_status_code:

from django.test import TestCase

class PagesTests(TestCase):
    """Класс с тестами страниц"""

    def test_status_code(self):
        """Тест статус-кода"""

        for page in PAGES:
            with self.subTest(f'{page=}'):
                response = head(page) # (1)

                self.assertEqual(response.status_code, 200) # (2) и (3)

В тесте на каждую страницу мы отправляем HEAD-запрос и сохраняем ответ в переменной response. После этого проверяем, равен ли статус-код страницы 200.

Проверка ссылок на страницах

Проверить ссылки можно так:

1. Отправить на страницу GET-запрос и получить её контент;

2. С помощью регулярного выражения получить из контента все ссылки;

3. Отправить по каждой ссылке HEAD-запрос и проверить, что статус-код ответа – 200.

Для поиска ссылок будем использовать метод findall батарейки re. Для отправки GET-запроса – метод get всё той же библиотеки requests. И не забудем о методе head.

from re import findall

from requests import get, head

Далее переменные. Для этого теста нам понадобится константа PAGES, объявленная ранее, и переменная с регулярным выражением для ссылки.

LINK_REGULAR_EXPRESSION = r'<a[^>]* href="([^"]*)"'

И, наконец, напишем сам тест.

def test_links(self):
    """Тест ссылок страниц"""

    valid_links = set()

    for page in PAGES:
        page_content = get(page).content # (1)
        page_links = set( # (2)
            findall(LINK_REGULAR_EXPRESSION, str(page_content))
        )

        for link in page_links:
            if link in valid_links:
                continue

            with self.subTest(f'{link=} | {page=}'):
                response = head(link, allow_redirects=True)

                if response.status_code == 200:
                    valid_links.add(link)

                self.assertEqual(response.status_code, 200) # (3)

На каждую страницу отправляем GET-запрос и из полученного ответа извлекаем контент. Далее с помощью регулярного выражения и метода findall получаем все ссылки, находящиеся на странице. Их заносим в set, чтобы убрать дубли. Последний этап – уже знакомая нам ситуация: обходим все ссылки, отправляем на них HEAD-запрос и проверяем статус-код. Если переменная link – редирект, то параметр allow_redirects укажет, что мы можем его выполнить. По умолчанию его значение – False. Также добавляем валидные ссылки в set, чтобы в дальнейшем не отправлять на них запрос.

Кстати, иногда на странице можно встретить относительные ссылки. Например, «/ru/pvs-studio/faq/». Сайт к ним подставляет URL-адрес, но тест этого не делает и, как следствие, не может выполнить запрос.

Чтобы этого избежать, создадим такую функцию:

SITE_URL = 'https://pvs-studio.com'

def get_full_link(link: str) -> str:
    """Возвращает полную ссылку (с URL-адресом сайта)"""

    if not link.startswith('http'):
        link = SITE_URL + link

    return link

Если полученная ссылка – относительная, функция добавляет к ней URL-адрес сайта. Теперь в тесте при получении ссылки мы будем использовать эту функцию:

# ...
for link in page_links:
    link = get_full_link(link)
# ...

Бывают ситуации, когда тест выдаёт не настоящий статус-код страницы. Обычно он либо 403, либо 404. Например, для этой страницы, используемый нами метод head, вернёт статус-код 404. Так происходит, потому что некоторые сайты не хотят выдавать роботам данные о странице. Чтобы этого избежать, нужно использовать метод get, а также для большей уверенности в тесте, добавить заголовок User-Agent.

from requests import get

head_response = head(link)
print(head_response.status_code) # 404

get_response = get(link, headers={'User-Agent': 'Mozilla/5.0'})
print(get_response.status_code) # 200

Тесты редиректов

Ещё один вариант тестов с помощью requests – тесты редиректов. Чтобы их проверить, нам нужно:

1. Перейти по ссылке и получить ответ;

2. Сравнить URL-адрес ответа с ожидаемым.

Следовательно, нам пригодятся два URL-адреса. Первый – ссылка-редирект, на которую жмёт пользователь. Второй – URL-адрес страницы, на которую посетитель в итоге перешёл. Как и в примере со статус-кодами, лучше получать эти URL-ы из базы. Если такой возможности нет, то рекомендую использовать словарь.

REDIRECT_URLS = {
    '/ru/m/0008/': '/ru/docs/',
    '/en/articles/': '/en/blog/posts/',
    '/ru/d/full/': '/ru/docs/manual/full/',
}

Не забудем про переменную SITE_URL, созданную ранее.

SITE_URL = 'https://pvs-studio.com'

И напишем сам тест.

def test_redirects(self):
    """Проверяет правильность редиректа"""

    for link, page_url in REDIRECT_URLS.items():
        with self.subTest(f'{link=} | {page_url=}'):
            page_response = head(
                SITE_URL + link, allow_redirects=True
            ) # (1)

            expected_page_url = SITE_URL + page_url

            self.assertEqual(page_response.url, expected_page_url) # (2)

Первым делом по ссылке мы отправляем HEAD-запрос. При этом разрешаем использовать редиректы. Из полученного ответа берём URL-адрес страницы и сравниваем его с ожидаемым.

Библиотека requests позволяет выполнять много разных проверок сайта. Основные методы для тестов, как вы могли заметить – head и get. Но есть и другие. Они тоже могут пригодиться. Всё зависит от ваших задач.

Заключение

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

Расскажу вам историю о том, как непродуманный интерфейс помешал мне сделать покупку.

Однажды знакомый посоветовал почитать книгу Робертса “Шантарам”, он так ярко и красочно рассказывал, что заинтересовал меня не на шутку. Придя домой, я стал искать книгу в интернет-магазине Лабиринт. Вот только незадача — я не записал название и забыл, как правильно оно пишется. В голове крутилось то ли “Шантрам”, то ли “Шанторам”, то ли “Шонтарам”. Искать по фамилии автора я даже не пытался — писателей с фамилией “Робертс” ни один десяток.

Я ввел в поисковой строке “Шантрам” и получил коллекцию книг про “шатры”. Это меня озадачило.

Попробовал “Шанторам” — опять мимо. Думаю вы уже догадались, что и третья попытка провалилась. Я расстроился. Что делать? То ли я не то ввожу, то ли в магазине книги нет. Но я упорный. Так просто не сдаюсь.

Я открыл еще несколько книжных интернет-магазинов и попробовал ввести в каждом “Шантрам”. Бинго! Из трех магазинов, один нашел “Шантарам” Робертса, несмотря на то, что я переврал название. Как я был рад. Времени на поиски потратил много, но в итоге нашел желаемое и купил книгу.

А в Лабиринте, кстати, книга была, просто поиск у него работает так, что если ошибешься, то ничего не найдешь. Такое часто встречается в интернет-магазинах.

В целом интерфейс Лабиринта хорош, но казалось бы проблема в поисковом алгоритме привела к потере клиента и падению конверсии. Обидно, досадно! Этого можно было бы избежать, если провести юзабилити-тестирование на пользователях и исправить обнаруженные проблемы.

Юзабилити-тестирование — один из самых эффективных методов проверки удобства интерфейса. К участию в таком исследовании привлекают реальных пользователей продукта. Этот метод действенный и показательный, потому что никто не найдет проблемы в интерфейсе лучше, чем те, кто им пользуются.

Тестирование организует юзабилити-специалист, который планирует исследование, проводит сессии тестирования, анализирует результаты и пишет отчет.

Мы в компании “Ю-эксперт” специализируемся на юзабилити-услугах и особое место среди них занимает юзабилити-тестирование. В этой статье мы познакомим вас ближе с этим методом и подробнее расскажем как он работает.

Что можно узнать благодаря юзабилити-тестированию

Где применяют юзабилити-тестирование

Для каких продуктов подходит

Тестировать можно любые продукты, с которыми работают пользователи и это не только компьютерные интерфейсы:

В каких отраслях применяется

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

Юзабилити-тестирование используется для:

Виды юзабилити-тестирований:

Качественное — в таком исследовании участвует по 6-8 человек на каждый сегмент целевой аудитории. Основная задача исследования — найти проблемы и их причины, определить потребности пользователей и способы их удовлетворения. В качественном тестировании всегда участвует модератор (юзабилити-специалист), он голосом дает пользователю задания и общается с ним в процессе тестирования.

Качественное тестирование проводят:

Количественное — в таком исследовании обычно участвует более 50 респондентов, часто число достигает 200 и более. Основная задача такого тестирования — проверить как часто пользователи сталкиваются с теми или иными проблемами в интерфейсе. Здесь сложно получить ответ на вопросы “почему” и “каким образом”, зато узнаете насколько проблемы критичны и как часто встречаются. Каждое такое тестирование проходит без непосредственного участия модератора. Пользователь самостоятельно заходит в программу для тестирования и последовательно выполняет задания, которые выводятся на экране. После каждого задания участник отвечает на несколько вопросов. Дополнительно ведется запись экрана, а иногда даже голоса респондента. Количественное тестирование обычно проводят через специальный сервис.

Количественное тестирование никогда не заменит качественное и наоборот. Они гармонично дополняют друг друга отвечая на разные вопросы. Качественное — на вопросы “почему, каким образом, в чем заключается проблема”, а количественное — “как часто, насколько критично”.

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

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

Плюсы юзабилити-тестирования:

Минусы юзабилити-тестирования:

Этапы проведения юзабилити-тестирования

Интервью с бизнесом

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

На встрече с бизнесом обсуждаем:

Примеры вопросов бизнесу

Пример: сервис доставки пиццы

Представьте, что нужно провести юзабилити-тестирование сервиса доставки пиццы и роллов. У компании есть сайт, мобильная версия сайта и мобильное приложение. Бюджет и время ограничены, поэтому нужно выбрать только один интерфейс для тестирования. Посмотрев аналитику сайта (yandex или google), специалист увидел, что наиболее востребован мобильный сайт, поэтому с него он будет начинать тестирование.

На встрече с бизнесом были обозначены три основные задачи для тестирования:

Подбор и рекрутинг участников тестирования

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

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

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

Сколько человек приглашать на юзабилити-тестирование

Якоб Нильсен, один из основоположников юзабилити, писал, что 5 пользователей находят 85% проблем в интерфейса. Мы склоняемся к тому, чтобы приглашать по 8 человек из каждой целевой группы, так как это позволит обнаружить 95% проблем.

Если тестирование проводится для двух и более сегментов целевой аудитории, то из каждого приглашают по 4-6 человек, в зависимости от того, насколько сильно они отличаются. Например, если группа 1 никогда не работала с продуктом, а группа 2 состоит из опытных пользователей, то из каждой нужно взять минимум по 5-6 человек.

Пример: каких пользователей пригласить на тестирование сервиса доставки пиццы

Теперь заказчику нужно определиться с целевой аудиторией. Если в компании есть специалисты, которые непосредственно общаются с пользователями, то они могут помочь с портретами клиентов. Также хорошим подспорьем будет статистика на сайте. Требования к участникам тестирования прописываются в “скринере”.

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

Можно пригласить 4 опытных пользователей, которые хотя бы 1-2 раза в месяц заказывают еду через мобильный сайт и 4 неопытных пользователей, которые делают заказы реже раза в месяц.

В случае с пиццерией достаточно 8 пользователей:

Вознаграждение респондентам

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

Самое банальное — деньги. Обычно за участие в тестировании мы платим 1000-1500 руб. Но это не всегда лучший вариант, так как можно попасть на пользователей, которые будут тестировать только в целях заработать.

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

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

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

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

Сценарий тестирования

Важный этап исследования — это создание сценария тестирования. Его могут называть по-разному и “скрипт”, и “гайд” и “сценарий”, и “вопросы тестирования”.

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

Основные разделы сценария

Пример сценария для тестирования сервиса доставки пиццы

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

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

Вводные вопросы:

Сформулируем первую задачу сценария

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

Зададим вопросы после выполнения задания

Далее замеряем метрики, после задания

Подробнее мы рассмотрим метрики далее, а в данном случае замерим следующие:

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

Завершающие вопросы

После тестирования сервиса доставки пиццы у пользователя можно спросить:

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

Метрики в юзабилити-тестировании

Обычно во время юзабилити тестирования специалист замеряет несколько метрик. В зависимости от конкретного проекта и типа тестирования они варьируются. Но есть одна метрика, которая замеряется всегда — успешность.

Успешность — удалось ли пользователю выполнить задание. Обычно она отмечается как 1 для ответа “Да” и как 0 для ответа “Нет”.

Время выполнения. Время с одной стороны понятие объективное — его можно измерить секундами, минутами, часами. С другой стороны субъективное, так как один и тот же промежуток времени может показаться человеку длинным или коротким.

В юзабилити тестировании в зависимости от задачи можно измерять объективное и/или субъективное время. В некоторых случаях и задачах время вообще не измеряется. Например, если мы имеем дело с игрой. Задача игры — это убить время и/или потратить время на то, чтобы расслабиться, поэтому измерять время здесь можно только на этапе регистрации и не более того.

Когда применяется объективное время и как оно измеряется:

Когда применяется субъективное время и как оно измеряется:

Сложность. Это субъективная метрика, которая определяет, насколько было сложно или легко выполнять задание. Пример вопроса:

“Насколько сложно было выполнять это задание? Оцените по пятибалльной шкале, где 1 — очень легко, а 5 — очень сложно”.

В зависимости от продукта и целей исследования вопросы можно задавать тем или иным образом.

В отдельных исследованиях мы используем SUM (Single Usability Metrics). Идея данной оценки — свести все юзабилити-метрики к одной и таким образом получить инструмент для сравнения. В этой оценке учитываются метрики разной размерности — время (в секундах), показатель ошибок (в штуках), завершенность задания (бинарный показатель), усредненный показатель удовлетворенности (баллы Ликера). Чтобы не складывать секунды со штуками, основатель этой системы Джеф Соро предлагает привести все показатели к безразмерной шкале. Для вычисления SUM используется специальный калькулятор (его можно найти в интернете или скачать специальный файл excel).

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

Пример: сервис доставки пиццы

Для тестирования мобильной версии сайта сервиса доставки пиццы мы выбрали следующие метрики.

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

Самая важная метрика — успешность. В идеальной ситуации, все 8 пользователей должны выполнить задание. Если хотя бы 1 респондент не справился с заданием, интерфейс нужно дорабатывать.

Вторая важная метрика — сложность. Если сложность получилась между 1 и 2, то все хорошо, но если она больше 2, то на интерфейс нужно обратить внимание. Если сложность колеблется между 4 и 5, то нужно обратить на эту задачу пристальное внимание.

Третья по важности метрика — время. Если субъективное время находится между 1 и 2, то это хороший знак, если оно больше 2, то стоит обратить внимание.

Пилотное тестирование

После того, как сценарий написан и утвержден бизнес-заказчиком важно провести пилотное тестирование. У него есть несколько целей:

К “пилоту” желательно привлекать пользователя из целевой аудитории, тогда оно будет наиболее приближено к реальному тестированию. Если такой возможности нет, то можно тестировать коллегу или знакомого, который наиболее близок к целевой аудитории.

Иногда во время пилота выясняется, что нужно:

Таким образом, пилотное тестирование — необходимая часть процесса.

Проведение тестирований на пользователях

После пилотного тестирования и рекрутирования нужно составить график тестирований. Для комфорта пользователя и качественных результатов каждая сессия тестирования должна длится не более часа. Однако, на каждое тестирование нужно закладывать 1,5-2 часа, так как пользователь может опоздать к началу или сессия тестирования затянуться.

В случае очного тестирования заказчик может наблюдать процесс из соседней комнаты, если тестирование удаленное, то он подключается к zoom или skype, а также может посмотреть тестирование в записи.

Пример: юзабилити тестирование сервиса доставки пиццы

Юзабилити тестирование сервиса доставки пиццы было решено проводить на мобильном телефоне, так как мобильной версией сайта пользуется больше половины клиентов. Тестирование проводится удаленно на мобильном телефоне респондента.

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

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

Модератор созванивается с пользователем и просит его расшарить экран телефона через приложение, а также включает запись.

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

Анализ результатов

После завершения сессий юзабилити-тестирования специалист работает с данными, полученными на тестировании, и пишет отчет. Для этого он:

Пример: усредненные метрики после тестирования сервиса доставки пиццы (8 участников тестирования)

В этом тестировании измерялись:

Успешность (1 — выполнил, 0 — не выполнил). В таблице обычно отмечают, сколько респондентов справилось с заданием.

Субъективное время по 5-балльной шкале, где 1 — потратил очень мало времени, 5 — потратил очень много времени.

Сложность по 5-балльной шкале, где 1 — было очень легко, 5 — было очень сложно.

Примеры цитат пользователей из тестирования:

“Я бы никогда здесь не стала заказывать пиццу. Вот как заказать сет? Я не понимаю. Тут просто название пиццы “Деревенская”. А что в нее входит? Не понятно. И главное не нажать никуда и не посмотреть. Честно говоря у меня нет времени искать ее в каталоге и смотреть состав. Я бы уже на другой сайт ушла”

“Ой, я нажала на сеты роллов и суши, а он мне тут игральные карты и туалетную бумагу предлагает. Вот умора. Я бы уже ушла с сайта, честное слово”

Отчет о тестировании

После анализа видеозаписей и метрик специалист пишет отчет о тестировании, который состоит обычно из следующих разделов:

Рассмотрим подробнее разделы отчета на примере тестирования сервиса заказа пиццы.

Пример: отчет о юзабилити-тестировании сервиса заказа пиццы

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

Кратко описывается сценарий тестирования: вводные вопросы, на которые пользователь отвечал до начала тестирования, а также перечисляются задачи.

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

Затем слайд с общими выводами о юзабилити-тестировании сервиса. Здесь вкратце описываются наиболее критичные проблемы и приводится таблица с метриками.

Далее в отчете подробно описываются проблемы, возникшие при выполнении каждого из заданий. Дается подробная разбивка по экранам. Для каждой проблемы специалист выставляет критичность от 1 до 3, где 1 — низкая критичность, 2 — средняя, 3 — высокая. Критичными считаются проблемы, которые могут привести к отказу от покупки и возникают у большинства пользователей. Их нужно устранять в первую очередь.

Заключение

Юзабилити-тестирование помогает найти проблемы в интерфейсе, “побывать в голове пользователя” и понять, как он работает с продуктом. Нужно иметь в виду, что по результатам исследования юзабилити-специалист не сможет перепроектировать интерфейс, он даст советы, как это сделать, а дальше нужно привлекать проектировщиков, дизайнеров и программистов.

К юзабилити-тестированию стоит относиться как диагнозу, который дает врач, а дальше начинать “лечение продукта” в соответствии с рекомендациями.

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

Для большего погружения в юзабилити-тестирования советую почитать книгу Стива Круга “Не заставляйте меня думать”, пройти курс по юзабилити на одном из порталов онлайн-обучения или обратиться в юзабилити-агентство, которое проведет тестирование за вас.

В случае, когда нет возможности провести юзабилити-тестирование (например, нет времени или не хватает бюджета), мы советуем заказать юзабилити-экспертизу интерфейса. Она поможет найти основные проблемы в продукте и получить рекомендации, как их устранить.

Полезные материалы по теме

Юзабилити-аудит сайта: полный гид + примеры

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

• Создание тестовых сценариев обеспечивает полное покрытие тестами
• Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
• Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
• Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
• Для изучения сквозного функционирования программы, тестовый сценарий имеет решающее значение.

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
• Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

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

• Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
• Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
• Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
• Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
• Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

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

1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
6. Проверить Забыли пароль работает как положено
7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска

Зачем нужно тестирование?

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

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

➀ О чем эта статья

В статье «Как протестировать сайт. Подробное руководство»‎ хотелось бы поделиться информацией для тех, кто собирается тестировать сайты. В статье содержится информация о том, как можно быстро протестировать любой сайт. Дается информация о том, как сделать так, чтобы протестировать сайт быстро, не упустив самого главного, а также о том, как максимально подробно протестировать сайт, чтобы ни о чём не забыть, ничего не упустить.
Конечно, осветить все моменты и нюансы в одной статье вряд ли возможно, поэтому в процессе будут даваться ссылки на другие страницы и источники, чтобы можно было ознакомиться с ними по мере необходимости. Статья построена таким образом, что Вы можете обратиться к нужному пункту и изучить именно ту информацию, которая волнует Вас в данный момент времени.

➁ Для кого эта статья

Кому может быть полезна статья «Как протестировать сайт. Подробное руководство»‎:
❄ Вебмастер / разработчик сайта только что сделал новый сайт или доработку и хочет получить информацию, как протестировать сайт, чтобы оперативно исправить ошибки и проблемы.
❄ Менеджер проекта столкнулся с проблемой, что пользователи быстро уходят с сайта, хочет узнать, как тестируют сайты, и что можно улучшить на сайте, чтобы повысить лояльность клиентов.

❄ Тестировщик, который хочет структурировать и систематизировать свои знания по веб-тестированию.

➂ Экспресс-тестирование сайта

Представьте, что Вам сейчас предстоит быстро протестировать сайт. Составим пункты, как провести экспресс-тестирование сайта:
➀ Изучить сайт, выписать структуру и всю необходимую информацию для тестирования.
➁ Составить план тестирования, выбрать только самые главные страницы и критично важную функциональность, без которой невозможно представить работу сайта, определить объём работ и достаточно маленький срок.
➂ Провести тестирование с использованием методик и техник тестирования.
Существует так называемый временной подход, который мы используем — это выделение определенного количества времени на экспресс-тестирование — это могут быть короткие сессии тестирования по 5, 10 минут, N минут… Главное — это успеть найти хотя бы несколько ошибок, своего рода приключение и вызов для тестировщика. А заказчику — полезная информация об ошибках, чтобы понимать, какие могут быть проблемы у пользователей при первом знакомстве с сайтом.

➂.➀ Плюсы экспресс-тестирования:

☑ Быстрая оценка работы сайта, быстрая обратная связь от тестировщика по общему состоянию сайта.
☑ При серьёзных проблемах возможность понять серьёзность ситуации.
☑ Это вызов для специалиста, возможность проверить свои навыки в сжатых временных рамках и условиях.

➂.➁ Минусы экспресс-тестирования:

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

✖ Снижается объективность тестирования в целом, когда проверяется сразу и много, снижается точность и качество тестирования.

➃ Подробное тестирование сайта

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

➃.➀ Изучение сайта

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

➃.➁ План тестирования

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

➃.➁.➀ Для чего нужен план тестирования (тест-план)?

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

➃.➁.➁ Тест-план может состоять из следующих разделов:

❄ Исходная информация. Что известно о сайте и собрано на этапе изучения сайта: информация о компании, заказчике, целевая аудитория, что заказчик ожидает от тестирования сайта.
❄ Страницы и функциональность. Список страниц с приоритезацией (самые важные, средней важности, менее важные). Функциональность (критически важная, важная, менее важная). В общем всё то, что именно будет тестироваться. Стоит также указать те страницы и функциональность, которые не будут входить в план тестирования и не будут тестироваться.
❄ Виды тестирования: функциональное тестирование, тестирование мобильной версии и другие виды тестирования.
❄ Окружения, на которых будет производиться тестирование.
❄ Анализ рисков. Обдумывание: что может пойти не так в процессе тестирования и мер по предотвращению этих рисков.

❄ Сроки проведения тестирования.

➃.➂ Виды тестирования

Существуют различные классификации видов тестирования. Выделим, на наш взгляд, наиболее часто используемые виды веб-тестирования:

➃.➂.➀ Функциональное тестирование. Скачать пример отчета

➃.➂.➁ Тестирование вёрстки.

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

➃.➂.➂ Кроссбраузерное тестирование.

Примеры ошибок:
❄ В Internet Explorer 11 не отображается слайдер с картинками.
❄ В Mozila Firefox не видна кнопка для заказа товара.

➃.➂.➃ Тестирование удобства использования.

Примеры ошибок:
❄ Неудобно листать список товаров.
❄ Для регистрации на сайте требуется заполнить огромное количество полей.

➃.➂.➄ Автоматизированное тестирование.

Примеры работ:
❄ Написание Selenium-тестов для покрытия главной страницы.
❄ Создание коллекции с тестами для API в Postman.

➃.➂.➅ Тестирование безопасности.

Пример: сканирование сайта на уязвимости.

➃.➂.➆ Нагрузочное тестирование.

Пример: имитация большого количества посещений.

➃.➃ Инструменты тестировщика

Для проведения тестирования веб-приложений используются различные инструменты:
❄ Chrome DevTools: показывает ошибки в консоли и многое другое.
❄ Fiddler: помогает анализировать запросы.
❄ Pixel Perfect: помогает выявлять ошибки в вёрстке.
И многие другие..

➃.➄ С чего начать тестирование сайта

Сначала можно начать общее тестирование сайта, например, если у Вас уже есть общий чек-лист для проверки сайта, Вы можете пройтись по его пунктам. Если такого чек-листа нет, можно его придумать. К примеру, самой первой проверкой может быть — а открывается ли вообще сайт? Какой отдается код ответа? Дальше генерируем идеи и записываем, что было проверено.

➃.➅ Что тестировать на сайте

Опытный тестировщик обладает знаниями и опытом. В ответе на вопрос «‎Что тестировать?» могут хорошо помочь техники тест-анализа, которые помогают исследовать сайт таким образом, чтобы выделить необходимые для тестирования объекты сайта. Примеры техник тест-дизайна: тестирование переходов и состояний, структурирование элементов системы в интеллект-карту и другие.
В простом случае — попробуйте выделить объекты на Вашем сайте и выпишите их в каком-нибудь виде для дальнейшего анализа.
А лучше — пройти курсы по техникам тест-анализа / изучить материалы по этой теме, разобраться в этой теме и тогда на вопрос «‎Что тестировать?» Вы всегда будете знать ответ при тестировании любых сайтов.

➃.➆ Как тестировать сайт

Когда стало понятно, что именно тестировать — это может быть, например, форма обратной связи на сайте или меню сайта — самое время задать вопрос «‎А как же всё это тестировать?». Ответить на этот вопрос могут опыт, знания тестировщика. Т.е. чем больше тестировщик тестирует сайты, тем больше у него опыта. Ответить на этот вопрос может теория тестирования. Техники тест-дизайна помогают в генерации и придумывании тест-кейсов и различных сценариев. Примеры техник тест-дизайна: разбиение на классы эквивалентности, выделение граничных значений и многие другие.

➃.➆.➀ Как будем тестировать сайт?

У нас уже есть список страниц и модулей, которые нужно протестировать в первую очередь.
Берем первую самую важную страницу, выделяем главные модули на странице и проверяем их в первую очередь. Затем проверяем второстепенные модули и так далее.
Можно поступить по-другому. Начинаем смотреть на сайт сверху вниз и проверяем каждый элемент, каждый модуль на сайте, так тестирование получится более полным.
Каждый модуль и элемент на сайте нужно смотреть с разных сторон, настоящий тестировщик может увидеть то, что другие не заметят, за это больше всего и ценятся тестировщики. Поэтому старайтесь идти до конца, никогда не останавливаться, нужно всегда пытаться найти то, чего другие не увидят.
Так действуем до тех пор, как страница не проверена полностью.
А дальше проверяем все остальные страницы согласно плану.

➃.➆.➁ А что по техникам тест-дизайна?

По поводу техник тест-дизайна: в простом случае — попробуйте взять каждый из объектов на Вашем сайте и разобрать его по полочкам, проанализировать и представить, какие могут быть проблемы в данном конкретном объекте. Затем нужно проанализировать несколько объектов, попытаться провести между ними связи. После анализа нескольких объектов переходите к анализу других объектов. Затем анализируйте группы объектов и связи между ними.
А лучше — пройти курсы по техникам тест-дизайна / изучить материалы по этой теме, разобраться в этой теме и тогда на вопрос «‎Как тестировать?» Вы всегда будете знать ответ при тестировании любых сайтов.

➃.➆.➂ Кажется, уже всё протестировано..

Когда кажется, что всё уже протестировано, и больше идей нет, можете поискать готовые чек-листы для тестирования сайтов в разных источниках. Можете посмотреть примеры чек-листов ниже.
Для случая, когда кончились идеи, мы создали специальный сервис «‎Генератор идей для тестирования веб-сайта», можете ознакомиться с ним ниже.

Подытожим

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

➃.➇ Как искать ошибки на сайте

Говорят, что поиск ошибок на сайте — это целое искусство. Но на самом деле, при наличии опыта и знаний в тестировании сайтов, при наличии знаний о техниках тест-дизайна и тест-анализа, эвристиках — искать ошибки становится проще и быстрее. Ну и чутьё тестировщика никто не отменял, нужно быть внимательным, скурпулёзным и всегда иметь огонь в глазах, чтобы находить даже самые неочевидные вещи. Что но же делать, если Вы не являетесь тестировщиком?
В таком случае, попробуйте пройти курсы по тестированию, получить нужные знания в этой области, станьте тестировщиком, практикуйтесь и совершенствуйтесь в этом деле.
Если становиться тестировщиком не хочется, можно попросить помощи у тестировщиков.
Если тестировщиков нет, попробуйте почувствовать себя обычным пользователем сайта и использовать те рекомендации, которые мы описали выше.

➄ Полезные материалы для тестирования сайта

В данном разделе приведены полезные материалы для тестирования веб-сайтов.

Идеи для тестирования сайта.

➄.➀ Идеи для тестирования сайта

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

➄.➁ Чек-лист тестирования сайта

Чек-лист — это список проверок, что нужно проверить. В зависимости от сайта, чек-лист может быть разным. Тестировщики в процессе тестирования пишут свои чек-листы, но можно воспользоваться готовыми чек-листами.

Примеры чек-листов.