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

Действительно, большинство пользователей свободного ПО получили его бесплатно. Однако, это не означает, то за него не следует платить, ведь за каждой программой стоит труд людей.

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

Инженер компании Lucid Software Маккей Кристенсен считает, что один из лучших способов помочь проекту — найти ошибку и оправить программистам подробный отчёт. Очевидно, что польза от этого обоюдная. Разработчики смогут улучшить своё приложение, а пользователи избавятся от некоторых проблем.

Но составление баг-репортов — дело непростое. Маккей Кристенсен предлагает разбить всю работу на несколько относительно простых шагов.

Шаг 1. Воспроизведение ошибки

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

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

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

Шаг 2. Проверка существующих баг-репортов

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

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

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

Шаг 3. Составление отчёта

Хороший отчёт увеличивает вероятность исправления ошибки. Поэтому его составлению следует уделить особое внимание. Как правило, разработчики заранее готовят для пользователя некую форму, которая для них максимально удобна. В общем случае она должна состоять из следующих пунктов.

Общее описание. Самое простое и правильное краткое описание ошибки должно примерно совпадать с поисковым запросом, который использовался в предыдущем шаге. Если её понял Google, то наверняка поймёт и разработчик.

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

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

Также не следует забывать, что работу над свободным ПО чаще всего ведут интернациональные команды, не все участники которых владеют английским в совершенстве. Кстати, собственное знание языка тоже не стоит переоценивать.

И наконец — краткость. Всю необходимую информацию следует вместить в одно предложение.

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

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

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

Более того, в ряде случаев разработчики могут решить, что никакой ошибки нет, а есть только пожелание пользователя. Очевидно, что приоритет задачи сразу будет понижен.

Фактическое поведение. Этот пункт — основной. В нём следует максимально подробно изложить суть проблемы. Особенно важно уделять внимания деталям — это поможет разработчикам быстрее найти причину ошибки.

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

Не исключено, что при этом он обнаружит другие недостатки приложения. В этом случае целесообразно написать столько баг-репортов, сколько ошибок было найдено. Так можно интегрироваться в проект в качестве активного тестера, что чрезвычайно полезно — реакция разработчиков сразу станет значительно более оперативной.

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

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

Например, нельзя писать «открыть меню» — в данном случае следует использовать фразу «один щелчок по значку „меню“». Именно поэтому и применяется термин «листинг» — изложение должно не допускать двойных толкований.

Демонстрация ошибки. Это пункт полезен, поскольку одновременно решает несколько задач:

· помогает воспроизвести ошибку;

· служит доказательством, что она действительно имеет место;

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

Демонстрировать ошибку может набор скриншотов с аннотациями или видеозапись экрана в формате GIF. Разумеется, она не должна быть слишком длинной, а то разработчики уснут на половине сеанса.

Шаг 4. Контроль исполнения

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

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

Чтобы этого не произошло, надо постоянно отслеживать текущий статус задачи, отвечать на вопросы и при необходимости предлагать свою помощь в тестировании возможных решений. Open Source — всегда сотрудничество разработчика и пользователя, нельзя про это забывать.