Шаблон улучшения

Когда будете в следующий раз добавлять в багтрекер улучшения, ОДУМАЙТЕСЬ. Их же надо обосновать =)

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

Что предлагаем и зачем.

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

Можно сначала кратко проблему, потом что предлагаем. Можно наоборот, что предлагаем и почему. Но структурировано, кратко и наглядно.

Вот и все! А теперь нюансы.

1. Как везде — не значит круто

Распечатайте и повесьте на стену это правило.

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

Если на всех сайтах вводят баннеры — не надо бежать вводить их и у нас.

Если на всех сайтах, чтобы сделать заказ, надо пройти через 100 полей регистрации — не надо делать также!

Прочитайте сначала «Психбольница в руках пациента», потом заводите улучшения на usability.

См также:

Ваш лучший друг, анонимус — Развенчивание страха «Анонимные отзывы собирать нельзя, вас заспамят!». А ведь можно было бы ставить «улучшение» с запретом анонимов, но... Зачем?

2. Улучшение надо продумывать вплоть до тестов

А не оставаться на этапе идеи. Найти «классную возможность» и радостно поскакать заводить улучшение — удел джуниоров, которые не хотят учиться. Опытные тестировщики додумывают до конца, что они ожидают увидеть. Возможно, «овчинка выделки не стоит», а вы и не в курсе.

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

— Как вы будете тестировать ваше улучшение?

— Какие попутно кейсы сможете придумать для разных ситуаций?

— Как же надо себя вести системе?

Требования писать не так-то просто, но это очень помогает прокачать навык выявления недостатков в требованиях и белых пятен.

Пример с экселькой

Дадата — загружаешь файл с данными, она их обрабатывает.

Форма загрузки файла. Стоит ли улучшать?

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

Дадата определяет структуру файла, что в какой колонке лежит

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

Мы пускаем в Дадату студентов, начинающих тестировщиков. Иногда им приходит в голову светлая мысль улучшения — обрабатывать Excel с несколькими листами. Это кажется очень заманчивой идеей... Пока не начинаешь продумывать детали =)

— Вот смотрите, я скопировал данные с первого листа на второй. Получилось по 3 строки на каждой странице экселя. Так что на структуре я хочу видеть 6 строк!

— Что должна делать система, если на разных листах разная структура?

— Ээээ, нуууууу…

Безусловно, можно что-то придумать с этим «хитрым кейсом». Но тогда простая логика резко усложнится. Больше времени на разработку, больше костылей, больше багов… А главное — зачем? Стоит ли оно того? Нет. Но мы никогда не узнаем этого, если не попробуем продумать собственное улучшение.

Тестировщик должен уметь предусматривать подводные камни.

См также:

Пристрелите фичу— Как решить, делать улучшение или нет.
Мнемоники о заведении улучшения — СОПРАНО, ВРИ ВСЕМ и ЛУБОФФ. Отличные, придерживайтесь их!

3. Улучшение умрет при плохом описании

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

Стали думать, как избежать этого. Думали, думали, и придумали — ввести капчу! Ввел неправильно пароль — разгадывай ребус. Заводим улучшение: «Ввести капчу при входе в систему».

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

Время — очень дорогой ресурс. Его мало у PM-ов, которые разгребают баг-трекер и решают

— какую задачу;

— с каким приоритетом;

— кому и когда делать.

Поэтому всё, что можно выкинуть сразу — выкидывается. Не было же проблемы — что можно подобрать пароль брутфорсом. Было предложение капчи — неясно зачем. Его выкинут не читая, и это нормально.

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

4. Избегайте поп-апов

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

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

Пользователь ввел букву вместо числа, выводить ошибку → В поле А позволять вводить только числа, символы игнорировать (это когда клацаешь по буковкам, а в поле ничего не происходит).

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

Ввел небезопасный пароль, выводить ошибку → Выводить предупреждение в мире пользователя («с таким паролем у вас могут украсть все деньги») без необходимости лишний раз кликать «ок, отвали»

5. Забудьте про слово «добавить»!

В названии улучшения не надо писать глаголы типа «добавить»: и так понятно, что надо добавить, это же улучшение.

Добавить рекомендации по надежности пароля в форму регистрации.

↓

Рекомендация по надежности пароля в форму регистрации.

или 

Информировать пользователя о надежности пароля.

См также:
Багред — сервис проверки названий багов

Хватит нюансов, давайте пример!

Возьмем Дадату. При регистрации пользователь сам выбирает, какой пароль он хочет поставить. Хоть простейший "1", хоть гиперсложный.

Пароль «1» — не вопрос!

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

Стоит ли заводить на это баг?

=================================================

Регистрация с ненадежным паролем

Шаги для воспроизведения

1. Открыть форму регистрации — https://dadata.ru/#registration_popup
2. В поле «Почта» ввести свою почту, на которую еще не было регистрации. Например, gagaga@gmail.com
3. В поле «Пароль» ввести «1».
4. Нажать «Зарегистрироваться»

Результат

Успешная регистрация

Ожидаемый результат

Сообщение об ошибке — «Пароль должен содержать минимум 7 символов и 1 цифру»

=================================================

Или улучшение?

=================================================

Проверять надежность пароля при регистрации

При вводе пароля «1» при регистрации в https://dadata.ru/#registration_popup выводить сообщение об ошибке — «Пароль должен содержать минимум 7 символов и 1 цифру», чтобы защитить деньги пользователя.

=================================================

P.S. Заметили отличия в оформлении? Не надо использовать шаблон бага для улучшений

Так стоит заводить? Нет, не стоит, ни в виде бага, ни в виде улучшения — пользователи не любят запретов (см нюанс 1).

Но как же так? Пользователь ведь введет пароль «1», а потом у него украдут аккаунт, на котором лежат ВСЕ ДЕНЬГИ!!1 На самом деле это не так — Дадата не банк, много денег там хранить и не надо. Но, возможно, пользователь просто не подозревает о возможности взлома. Давайте его предупредим, но оставим право выбора (см нюанс 4)

Вспоминаем нюансы 2 и 3 и думаем, как оформлять. «Выводить подсказку при вводе ненадежного пароля»? А что такое «ненадежный»? Как вы будете тестировать задачу? И что должен сделать разработчик? Он поставит запрет на ввод «1», а пользователь введет «11» или «2». Надо уточнять, что такое «хороший».

Посмотрим на шаблон «Сначала зачем, потом как»

=================================================
Рекомендация по надежности пароля в форме регистрации

Во время регистрации в https://dadata.ru/#registration_popup  пользователь может ввести любой пароль (например, одну цифру). Такой пароль можно легко подобрать или угадать, и в итоге получить доступ к чужим данным и денежному балансу.

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

Это можно реализовать так:

1. Сделать под полем «Пароль» подсказку-рекомендацию о надежности пароля: «Чтобы пароль не украли, рекомендуем использовать минимум 8 символов, цифры, спецсимволы, заглавные и строчные буквы».

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

- общее количество символов;

- количество букв в разном регистре;

- количество цифр.

По мере ввода шкала заполняется от значения «Легко украсть» до «Сложно украсть». Так пользователь понимает, надежный ли пароль (см. «Пример реализации»).

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

=================================================

Но мне больше импонирует шаблон «Сначала как, потом зачем». Ведь вы можете возвращаться к задаче не один раз и уже знаете «зачем». А вот ответ на вопрос «как?» придется выискивать по тексту, пропуская давно ненужную информацию. И вообще для вопроса «зачем» обычно есть доп поля типа «Бизнес-обоснование», вот это удобно!

Но, если «как» очень длинное получается, то лучше сначала «зачем», хотя тут мнения могут и расходится. Давайте сравним:

=================================================
Рекомендация по надежности пароля в форме регистрации

В форме регистрации в https://dadata.ru/#registration_popup:  

1. Сделать под полем «Пароль» подсказку-рекомендацию о надежности пароля: «Чтобы пароль не украли, рекомендуем использовать минимум 8 символов, цифры, спецсимволы, заглавные и строчные буквы».

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

- общее количество символов;

- количество букв в разном регистре;

- количество цифр.

По мере ввода шкала заполняется от значения «Легко украсть» до «Сложно украсть». Так пользователь понимает, надежный ли пароль (см. «Пример реализации»).

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

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

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

=================================================

Включайте мозг! И выносите суть в заголовок

Улучшение должно улучшать систему, а не ухудшать © капитан очевидность.

Прежде, чем заводить улучшение на usability, прочитайте книги:

• Алан Купер, Психбольница.
• Дэвид Платт. Софт Отстой.
• Джеф Раскин. Интерфейс. (позануднее предыдущих)

Но если решились, заводите!

Продумайте:

1. Что именно надо сделать?
2. Как вы будете это тестировать?
3. Какие есть хитрые кейсы?
4. Точно ли это надо? Можно ли сделать проще (исправлять ошибку вместо вывода текста «ты осел»)?

Опишите внятно, что надо сделать и зачем. И суть, суть выносите в заголовок!

См также:

Багред → сервис проверки названий багов.

Шаблон бага → использовался в статье. Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.
Пристрелите фичу → Как решить, делать улучшение или нет.

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

PPS: статья сохранена на Testbase в навыке описания баг-репортов.