Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Ранее я писала, как убедиться, что вы действительно нашли баг, прежде чем его заводить; как исследовать баг; и как написать баг-репорт, когда баг исследован. Но я никогда не писала о том, как добиться, чтобы баг исправили. Даже если вы зарепортили тщательно детализированный и внятно описанный баг, разработчик или команда все же могут решить, что он не достоин исправления. В этой статье мы разберем пять вещей, которые можно предпринять, чтобы помочь багу исчезнуть.

Первое: не распыляйтесь по пустякам

Возможно, это кажется алогичным, но если вы яростно боретесь за исправление каждого найденного вами бага, то можете вообще утратить внимание своей команды. Команды разработки всегда будут оставлять какие-то баги за бортом – или в качестве технического долга, чтобы исправить когда-нибудь потом, или как баги с пометкой "исправлен не будет". Вместо того, чтобы биться за каждый баг, выбирайте наиболее важные из них.

Как определить, какие из них наиболее важные? Подумайте о двух факторах: во-первых, о влиянии бага на пользователя. Баг, где кнопка подтверждения съехала от центра на пару пикселей, не шибко повлияет на пользователя. Однако баг, при котором пользователь вообще не может отправить форму, повлияет на него куда сильнее. Во-вторых, подумайте о вероятности столкновения пользователя с багом. Если шаги воспроизведения бага включают нажатие кнопки "Назад" двадцать раз, двойное изменение масштаба окна браузера, а затем его обновление – вряд ли пользователь наткнется на этот баг. Однако баг, при котором клиент не может ввести данные банковской карты, с шансами заметят сразу. Баги, за исправление которых надо бороться – это баги, с которыми может столкнуться пользователь, и которые могут сильно на него повлиять.

Второе: покажите баг в действии

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

Третье: поделитесь пользовательским опытом

Эту технику можно использовать совместно с предыдущей или письменно. Демонстрируя или описывая баг, подчеркните, что будет думать пользователь, проходя по этим шагам. К примеру, "Пользователь хочет что-то удалить из корзины. Меняя количество на ноль и сохраняя, он ожидает, что предмет из корзины исчезнет. То, что предмет еще там, путает и раздражает его".

Четвертое: поделитесь обратной связью от пользователей, столкнувшихся с похожей проблемой

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

Пятое: подчеркните потенциальное влияние бага на команду

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

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

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

Обсудить в форуме