Баг или фича? Вот в чём вопрос!
Серьезный тестировщик
В интернете много статей про приоритизацию (Priority) и серьезность (Severity) багов, но совершенно нет примеров. А что такое баг-то? А когда это запрос на новую фичу (”фича-реквест”, “улучшение”)? Практически у всех новичков возникает вопрос “а как вообще определить что баг, а что фича на живом проекте?”
Баги бывают разные — визуальные (некрасиво!), баги дизайна (неудобно!), функциональные (не работает!), баги в логике (работает неправильно!), баги безопасности (палим что не надо кому не следует!) и т.п. и все они могут попасть в разные градации серьезности.
Приоритеты меняются от проекта к проекту и даже в рамках самих проектов. Если нет чётких критериев что фича, а что ошибка, стоит обращать внимание на признаки косвенные и руководствоваться здравым смыслом.
Например, некрасивая опечатка или картинка котика вместо логотипа компании на странице-визитке (созданной для привлечения новых клиентов) сильно бьёт по имиджу компании. У потенциального покупателя возникнут вопросы: стоит ли нести свои деньги ребятам, которые не переживают за свой веб-сайт? А будут ли они “париться” о проблемах клиентов, если нет времени/желания проверить на опечатки свой собственный продающий сайт и залатать дырки от инъекций? В то же время, опечатка во внутренней админке проекта (куда доступ ограничен авторизацией или открыт только для “белого” списка IP адресов) совсем некритична, даже если это “Здратуйте” на главной странице.
Я искренне считаю, что если баг найден — он должен быть зафиксирован. Будут ли его чинить или посчитают исправление нецелесообразным (например, неоправданно дорогим для проекта)— решать ответственным за проект, но если проблема обнаружена, то она должна быть описана.
Зачем отличать баги от фич?
Часто про баги рапортуют одной команде, а запросы отправляют в другую. Или баги исправляют в текущем спринте, а фича-реквесты отправляют в бэклог в светлое будущее. И если определение типа запроса сделано неверно, он может в̶ы̶з̶в̶а̶т̶ь̶ ̶п̶р̶и̶г̶о̶р̶а̶н̶и̶е̶ ̶с̶т̶у̶л̶ь̶е̶в̶ потеряться или остаться без должного внимания. Давайте посмотрим на реальные примеры.
Это баг, если:
– работало, но вдруг перестало;
– работает, но неправильно;
– реализация не соответствует описанию и в задаче в явном виде не зафиксированы корректировки;
– нужно изменить название кнопки/страницы/раздела, потому что в них есть опечатка или “Отменить отмену” (классика!);
– опечатки в принципе (легко может иметь разный приоритет в зависимости от целей и задач проекта);
– после сохранения информация не появляется на странице, даже если в консоли 200 ОК;
– не все указанные при сохранении поля отображаются на странице, но поля неизменно показываются при редактировании;
– при нажатии на кнопку “УДАЛИТЬ ВООБЩЕ ВСЕ ДАННЫЕ КЛИЕНТА” нет модального окна с подтверждением Да/Нет, да и сделать это может любой пользователь без авторизации, который нашел ссылку;
– по переходу по прямой ссылке на услугу не проверяется какой пользователь сейчас авторизован и таким образом можно посмотреть чужие профили или детали услуг, если подобран валидный id;
– можно cURL’ом заказать услугу другому клиенту или в Elements через DevTools изменить стоимость в корзине (не проворачивайте такие сценарии не на своих рабочих проектах);
– информация торчит за границами своего блока или “наслаивается” на другой (ж-ж-ж-жуть, но на некоторых проектах этим можно легко пренебречь);
– страница очень долго открывается, ну о-о-очень долго — секунд 30 на стабильном интернете (взбешённый клиент гарантирован);
– система делает что-то, что она не должна делать согласно изначальной задумке. Например, закрытие аккаунта не только переводит его в статус “Закрыто”, но и возвращает клиенту все деньги, которые он принёс проекту за всё время сотрудничества за уже оказанные услуги (о-о-ой!);
– неудобно пользоваться. Например, чтобы посмотреть детали услуги клиента, нужно зайти на три вкладки вглубь аккаунта, а смотреть нужно 2–3 раза в день. Или неудобно копировать информацию со страницы, а по рабочим вопросам это нужно делать несколько раз в день — это баг интерфейса и он должен быть исправлен.
Это фича-реквест, если:
– нужно изменить название кнопки/страницы/раздела, потому что есть ощущение, что оно не отражает действительности;
– фичу сделали, но после использования видно, что есть простор для существенных улучшений. Например, по услуге не хватает мониторинга или статистических данных по использованию, а за перерасход может взиматься дополнительная плата — клиент точно будет несчастлив в неведении;
– знаете как улучшить ту или иную часть системы, чтобы было удобней. Например, меню необоснованно занимает 30% ширины экрана, а полезная информация ютится на оставшихся 70%;
– пользователь регулярно делает рутинные монотонные действия, которые можно автоматизировать. Например, копировать однотипную информацию с 12 страниц пагинации, когда простая выгрузка бы решила проблему;
– изобретаете велосипед из действующих фич продукта, чтобы добиться желаемого результата;
– на странице не хватает какой-то информации или возможности её добавить;
– на странице не хватает фильтров и пагинации, когда информации много и трудно найти нужное или отображение 1000+ элементов существенно сказывается на скорости загрузки страницы;
– пользователь ведёт дополнительную отчетность в блокноте/экселе, когда проблему можно решить выводом ID на странице и несколькими фильтрами.
Хорошо если в команде есть UX/UI дизайнер, а если нет? Тестировщику стоит различать что в дизайне баг, который может привести к печальным последствиям, а что запрос на улучшение, который сделает взаимодействие пользователей с системой более гладким и удобным, но может быть реализован позднее.
Поговорите с Главным По Проекту, узнайте кто ваш пользователь, спросите про критичные для пользователя и бизнеса фичи, запишите что будет “шоу-стоппером” для релиза (кроме очевидных “ничего-не-работает-памагити”), скорректируйте свои проверки в соответствии с этими знаниями и не бойтесь предлагать улучшения.
Оригинал статьи: https://medium.com/@mermoon/