Чтобы разработчик мог исправить баг на сайте, сначала он должен его воспроизвести. Мало сказать программисту: «Я не могу войти на сайт». Нужно объяснить как именно вы пришли к ошибке и что вы ошибкой считаете.
Разработчик должен пройти по тем же шагам, что и вы, и получить такой же результат. Это называется воспроизводимостью проблемы. Тогда вероятность её быстрого исправления максимальна.
Простой шаблон для описания любой проблемы
Он универсален и работает не только в IT сфере, но и в жизни.
1. Действия по шагам, в результате которых вы обнаружили проблему.
Важна максимальная конкретика — на какие страницы входили, что вводили в формы, в каком браузере работали и т.п.:
- шаг 1;
- шаг 2;
- шаг 3 и т.д.
2. Что получили в результате?
Разработчику важно понять что для вас оказалось проблемой.
3. Что ожидали получить?
Удивительно, но часто то, что вы считаете очевидным, для других людей таковым не является. Это справедливо и для программиста: многие вещи, которые он считает простыми и очевидными для всех, для вас будут откровением.
Пример правильно описанного бага
Захожу на сайт в браузере Хром под MacOS, в режиме инкогнито.
Нажимаю на вход через Facebook, вижу форму входа на FB, ввожу туда свой логин и пароль, нажимаю Enter.
В результате меня перекидывает обратно на главную страницу сайта и ощущение такое, что я на нем не залогинился.
Я ждал что будет показано уведомление об успешном входе на сайт и где-то в шапке появится имя пользователя и/или моя фотография из FB.
Такая формулировка займет у вас не одну минуту, а пять, зато сэкономит разработчику полчаса-час на то, чтобы понять в чём же, собственно, была проблема и как вы её получили.
Пример неправильного подхода
А вот как можно было написать о той же проблеме так, что разработчик ничего не решит или сделает совершенно не то, что нужно:
Я не могу войти на сайт! Почините уже вход, совершенно невозможно работать!!!
Что делает разработчик? Правильно, входит используя свой логин и пароль и даже не подозревает, что пользователь пытался авторизоваться через Facebook.
Наш программист отвечает пользователю: «А у меня всё ок, я вхожу на сайт и не вижу проблемы. Что у тебя не так-то?». На что пользователь ему снова отвечает обрывком информации: «Я пытаюсь входить и не вижу уведомление о том, что я вошёл на сайт».
Программист опять идёт проверять (и снова входит через логин/пароль) и видит уведомление. Может оно слишком маленькое, думает он? И увеличивает раза в 3 шрифт в нём. А затем говорит пользователю, что проблема решена.
В результате:
- оба потратили кучу времени на переписку;
- баг не починили;
- изуродовали внешний вид уведомления;
- пользователи «тупые», а программисты «ленивые».
Не воспроизводимые проблемы
К сожалению, встречаются и такие. Бывает, что у вас проблема видна, а разработчик, делая то же самое, получает совершенно другой результат. Или же ошибка «плавающая» — то появляется, то исчезает (самый неприятный для программиста вариант).
Фактически подобное означает, что никто не понимает реальных условий при которых появляется баг. В этом случае есть три рабочих стратегии.
Делать «методом тыка». Пытаться вслепую изменить хоть что-то, связанное с проблемным функционалом, чтобы ошибка перестала появляться. Худший вариант, я считаю, потому что не способствует пониманию проблемы. Мы как были в тумане в начале, так и останемся в тумане, даже если проблема вроде как исчезнет. А если проблема пропала совсем не потому, что мы что-то поправили и может вернуться опять?
Ставить заплатку (патч). По-сути, заставлять систему среагировать именно так, как нужно, не понимая при этом что привело к возникновению проблемы. Такое допускается только в качестве временного решения действительно критичной проблемы. Часто порождает новые баги и проблемы.
Наблюдать и искать новые закономерности. Путь более долгий, но самый правильный. Нужно изучать проблему до тех пор, пока не будет понятна её причина. Иногда это затягивается, но в результате позволяет исправить проблему гарантированно и с пониманием того, что делаем.