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

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

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

Сразу оговорюсь: я мало знаю о профессиональном тестировании. Но здесь много и не нужно, главное — уловить принцип. Мне хватило бесплатной вводной из курса «Инженер по тестированию» от Яндекс.Практикума. Я действительно проходила её из интереса, а навыки неожиданно пригодились в создании интерактивного отчёта. Чем тесты могут помочь визуализации читаем дальше.

1. Предварительная проверка

Допустим отчёт готов, и можно добавлять фильтры. Они не всегда обязательны, но если нужны, добавлять их стоит с умом. Помните: заказчик не будет описывать каждый ползунок в деталях. И слава богу! Как специалисту, нам проше определить внешний вид самим. Затем готовый фильтр нужно проверить. Сразу. Возможно, у вас в отчёте десяток фильтров, но проверять каждый из них нужно после добавления.

Убедитесь всего в двух вещах:

  1. Фильтр вообще работает
  2. и вроде как надо

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

Вам поможет тикет: там собрано подробное описание ожиданий заказчика. Что нужно фильтровать и как? А что не нужно? Иногда хотят что-то нестандартное, не из коробки. Ведь заказчик человек, а не база данных — мнения об удобстве у них разные.

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

2. Тест-кейсы до и после публикации

Чтобы объяснить идею, нужно определение:

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

из вводной части курса «Инженер по тестированию», Яндекс.Практикум

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

  • описание шагов, которые нужно пройти,
  • и Ожидаемый Результат. Так называемый ОР.

Если ОР не достигнут после всех шагов, тест провален. У вас ошибка.

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

Почему так? Слышали про «ожидания vs реальность»?

Отчёт в Tableau будет не совсем торт после публикации на сервере. Даже скорость применения фильтров может меняться. Поэтому тест-кейсы постфактум важнее предварительных, ведь так отчёт увидит заказчик. Но и про ранние тесты забывать не стоит. Они экономят ваше время и нервы.

Помните список хотелок, который мы собирали в пункте один? По каждому пожеланию составьте гипотетический тест-кейс. Как нужно, чтобы работал фильтр? А как не нужно? Определите шаги и ожидаемый результат. Затем пройдите каждый тест-кейс руками. Неудобно? Исправляем. Если уж вам не нравится, представьте, что будет с неискушённым заказчиком. То-то и оно.

3. Тест-сьюты по сценариям

Когда всё в отчёте работает как надо, осталось только прогнать базовые сценарии. Хорошо, когда в голове уже есть понимание, что такое тест-сьют. Всё просто:

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

из вводной части курса «Инженер по тестированию», Яндекс.Практикум

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

Пример Customer Journey Map для мобильного приложения

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

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

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

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

Уверена, что в тестировании есть ещё масса идей. Их можно применить где угодно, где есть продукт. И пусть я вряд ли уйду в тестировщики, никто не мешает тестировать там, где это нужно.

Опубликовано Дарья Гришко

Data-аналитик в ivi, амбассадор Яндекс.Практикума.

%d такие блоггеры, как: