Чтобы разработчик мог исправить баг на сайте, сначала он должен его воспроизвести. Мало сказать программисту: «Я не могу войти на сайт». Нужно объяснить как именно вы пришли к ошибке и что вы ошибкой считаете.

Как правильно описать ошибку или баг?

Чтобы разработчик мог исправить баг на сайте, сначала он должен его воспроизвести. Мало сказать программисту: «Я не могу войти на сайт». Нужно объяснить как именно вы пришли к ошибке и что вы ошибкой считаете.

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

Простой шаблон для описания любой проблемы

Он универсален и работает не только в IT сфере, но и в жизни.

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

  • шаг 1;
  • шаг 2;
  • шаг 3 и т.д.

2. Что получили в результате?
Разработчику важно понять что для вас оказалось проблемой.

3. Что ожидали получить?
Удивительно, но часто то, что вы считаете очевидным, для других людей таковым не является. Это справедливо и для программиста: многие вещи, которые он считает простыми и очевидными для всех, для вас будут откровением.

Пример правильно описанного бага

Захожу на сайт в браузере Хром под MacOS, в режиме инкогнито.

Нажимаю на вход через Facebook, вижу форму входа на FB, ввожу туда свой логин и пароль, нажимаю Enter.

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

Я ждал что будет показано уведомление об успешном входе на сайт и где-то в шапке появится имя пользователя и/или моя фотография из FB.

Такая формулировка займет у вас не одну минуту, а пять, зато сэкономит разработчику полчаса-час на то, чтобы понять в чём же, собственно, была проблема и как вы её получили.

Пример неправильного подхода

А вот как можно было написать о той же проблеме так, что разработчик ничего не решит или сделает совершенно не то, что нужно:

Я не могу войти на сайт! Почините уже вход, совершенно невозможно работать!!!

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

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

Программист опять идёт проверять (и снова входит через логин/пароль) и видит уведомление. Может оно слишком маленькое, думает он? И увеличивает раза в 3 шрифт в нём. А затем говорит пользователю, что проблема решена.

В результате:

  • оба потратили кучу времени на переписку;
  • баг не починили;
  • изуродовали внешний вид уведомления;
  • пользователи «тупые», а программисты «ленивые».

Не воспроизводимые проблемы

К сожалению, встречаются и такие. Бывает, что у вас проблема видна, а разработчик, делая то же самое, получает совершенно другой результат. Или же ошибка «плавающая» — то появляется, то исчезает (самый неприятный для программиста вариант).

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

Делать «методом тыка». Пытаться вслепую изменить хоть что-то, связанное с проблемным функционалом, чтобы ошибка перестала появляться. Худший вариант, я считаю, потому что не способствует пониманию проблемы. Мы как были в тумане в начале, так и останемся в тумане, даже если проблема вроде как исчезнет. А если проблема пропала совсем не потому, что мы что-то поправили и может вернуться опять?

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

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