Последние пара дней отличились интенсивностью общения с группой тестирования, что повлекло ряд мыслей...
Во-первых, какие задачи решают баг-репорты:
- Идентификационную. Если у нас есть какая-то штука, то мы должны уметь посмотреть на другую и сказать "она такая-же" или "она другая". Тут надо понимать, что имеется в виду не просто уникальная цифра, а именно возможность имея перед глазами какую-то картину, пусть и с затратами, понять сталкивались ли мы с этим раньше(хотя цифра тоже не лишняя: с ней мы изрядно экономим на трафике и длине логов в месенджерах).
- Документирующую ака историческую. В проекте всё должно быть записано. Потомки должны знать ошибки предыдущих поколений, и знать, что это ошибки, и иметь возможность их найти позже.
- Коммуникативную.
КрайнееОтветственное лицо должно узнать о том, что что-то "не так". Мало того узнав оно должно не бежать в соседнюю комнату или ждать пока к нему подойдут, чтобы потыкать пальцем в монитор. Оно должен после прочтения брать и воспроизводить проблему.
Далее, как метко подмечает товарищ Сartmendum основная боевая мощь живых тестеров сконцентрирована в двух фичах:
- Способности "смотреть по сторонам". То есть замечать окружение ошибки и передавать важные его особенности.
- Написании репортов на "человеческом языке". То есть рассказывать не что падает, а как падает.
А теперь, проникнувшись важностью процесса тестирования и благородной миссией людей его выполняющих, закрываем глаза и представляем баг из одного скриншота (в jpg кстати, но это другая история...) с обведённым в пейнте каким-то полем и комментарием типа: "Illegal status of nuclear fusion reactor"...
Грустно. Сколько задач решает такая штука? А сколько времени убивается на то, чтобы эти задачи всё-таки решить?
А сколько заняло бы создание нормального описания ошибки?
