Денежный тур (The Money Tour)

Предисловие

У туристов должна быть веская причина поехать в конкретное место. В Лас-Вегасе это казино и стрип-клубы, в Амстердаме — кофейные магазины и улица красных фонарей, в Египте — пирамиды. Уберите эти достопримечательности, и туристы уйдут тратить деньги в другое место.

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

Тестировщик денежного тура:

• ходит на демонстрации,
• смотрит продающие продукт видеоролики,
• общается с Заказчиками.

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

Мощная вариация тура — Тур Скептичного Заказчика (Sceptical Customer Tour). Выполняем Денежный Тур, но представляем, что Заказчик постоянно останавливает демонстрацию и спрашивает "Что, если..?".

• Что, если я захочу сделать так?
• Как я должен делать это?

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

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

В Дадате пользователи платят за:

1. Стандартизацию данных через файл или API.
2. Подсказки.

Начнем со стандартизации.

Проверяем все, что связано с деньгами? Пополним счет, обработаем файл и проверим списание средств? Неверно! Туристы приезжают посмотреть на пирамиды, а не отдать деньги экскурсоводу. Конечно, будет печально, если их не пустят внутрь, так как сломался аппарат приема денег. Но это не главное в туре. Нет пирамид — неважно, работает денежный аппарат или давно сломался.

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

Итак, какая проблема у пользователя? Есть клиентские данные, записанные абы как. Необходимо привести их к единому виду и исправить опечатки.

Пользователь платит за то, что:

• Данные стандартизируются — нужно побольше разных кейсов придумать, в каком виде эти данные могут поступать. Например, в исходной системе на форме ввода адресов надо вводить отдельно город, отдельно улицу и т.д. Для обработки в Дадате система склеивает адрес из кусочков. Это могут быть разные разделители (точки, запятые, пробелы), могут быть разные обозначения полей “ул. Московская”, “улица Московская”, “Московская улица”. И я как пользователь хочу платить деньги, зная, что Дадата справится с моим форматом выгрузки.
• Данных может быть много в ширину — Ну вот мои пользователи заводят по 10 адресов и 10 телефонов! Дадата должна их обработать, а не отрезать “лишние” колонки.
• Данных может быть много в высоту —200 тысяч разных данных в одном файле тоже не должно стать проблемой при наличии денег.

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

Не путайте денежный тур с туром оплаты. Лучше вспомните о вариации скептичного Заказчика:

— А что, если я загружу файл txt, но в формате csv?
— Мы все обработаем, смотрите! *демонстрация*

— А что, если у моих пользователей по 5 адресов? Вы можете осилить только один?

— Нет, что вы, ограничений пока нет, загружайте все!

— А что, если в фамилии мои операторы часто опечатываются?

— Мы исправляем большинство опечаток, давайте посмотрим на вашей тестовой выборке?

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

И только после проверки функционала стоит убедиться, что пользователи смогут за него заплатить. Теперь обратим взор непосредственно на деньги:

— Можно пополнить баланс из личного кабинета.

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

— Скидки работают, но не применяются внутри одного файла (если обработали 120 тысяч, цена 9 коп начнется со следующего файла)

Функционал проверили, деньги проверили. На этом всё.

Теперь перейдем к подсказкам.

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

И опять начинаем с функционала. Нам не нужны хитрые классы эквивалентности “а что, если ввести китайские иероглифы, спецсимволы…?”. Думайте о позитивных сценариях. Думайте о том, что будете показывать на демонстрации, чем будете гордиться? “А еще мы умеем так и вот так!”. Если вы разрабатываете продукт, вы наверняка знаете о том, что он умеет.

Но если вы пришли на середине проекта, и у вас нет идей, то вспомните о скептичном Заказчике и попробуйте ответить на все его “а что, если…”:

— А что, если я введу короткое имя? У меня в классе училась девочка Янг!

— А что, если я введу составное имя?

— А что, если я знаю только название организации? Понятия не имею об ИНН, ОГРН и прочих вещах?

— А что, если я не помню точное название улицы?

— А что, если… ?

И только проверив тот функционал, за который стоит платить, убедитесь, что за него можно заплатить. Пожалуй, все! Хотя задачка не для пары часов, а для нескольких сессий! А ведь казалось бы, просто денежный тур…

<< Тур по путеводителю. The Guidebook Tour

>> Тур по ориентирам. The Landmark Tour

Вернуться к полному списку туров

PS: Статья написана в помощь студентам моих курсов по тестированию. Изучайте новое, не стойте на месте!

PPS: Статья сохранена на Testbase, чтобы не потерялась ссылка.