"Джилл ввела информацию об ошибке в базу данных. Кстати, даже сам процесс записи информации об ошибке требует определенной дисциплины: бывают хорошие описания, а бывают и плохие...

Запомнить правила составления хорошего описания ошибки совсем нетрудно. Каждое хорошее описание ошибки должно содержать ровно три вещи: 1. Какие шаги привели к ошибке. 2. Что вы ожидали увидеть. 3. Что вы в самом деле увидели...

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

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

Понравилась статья Работа над ошибками малой кровью под авторством Джоэла Сполски. Джоэл является сооснователем и основателем Fog Creek Software, сделавшей Trello. Спасибо переводчику Александру Башкову и редактору Юрию Удовиченко. Заставили задуматься, что на работе мы не используем понятие "сборка". Например, мы не указываем сборку в отчётах о дефектах и сбоях. Похоже у меня также отсутствует возможность самостоятельно проверить номер сборки, которую сейчас проверяю. Необходимо выяснить, можно ли в рабочем проекте оперировать сущностью "сборка" и как это делать самостоятельно.

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

Джоэл Сполски в LinkedIn | Сайт Джоэла | Lurkmore про Джоэла

11.08.2017