Советы Джоеля Спольски (Joel Spolsky) из одного из его постов

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

2. Помните, что закрыть ошибку может только тот, кто её открыл. Кто угодно может решить её; но только тот, кто первым увидел ошибку, может быть уверен, что то, что он видел — исправлено.

3. Существует много способов разрешить ошибку. Например, можно сделать это следующими способами: исправлена, не подлежит исправлению, отложено, не воспроизводится, повторная, особенность дизайна.

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

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

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

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

8. Если вы программист, и некоторые из ваших коллег не используют базу данных учёта ошибок, начните назначать им ошибки через базу. В конце концов, до них дойдёт.

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

10. Избегайте соблазна добавить новые поля в базу данных. Примерно раз в месяц кому-нибудь в голову приходит «светлая» идея добавить к базе данных новое поле. Вам приносят самые разные мудрые идеи, например: указывать файл, в котором обнаружена ошибка; или вести учёт, в каком проценте повторов ошибка воспроизводится; вести учёт версий всех DLL, которые были запущены на компьютере, когда произошла ошибка; и так далее. Очень важно не поддаваться этим идеям. Иначе рано или поздно экран ввода информации об ошибке будет представлять собой форму с тысячью полей, которые необходимо заполнить, и никто не будет вводить эту информацию. Чтобы база данных учёта ошибок приносила толк, ее должны использовать все. И если ввод информации об ошибке будет требовать слишком больших усилий, люди найдут обходные пути.

Так же порадовал совет из этого же поста:

Каждое хорошее описание ошибки должно содержать ровно три вещи:

  • Какие шаги привели к ошибке
  • Что вы ожидали увидеть
  • Что вы в самом деле увидели

*****

На основе статьи Джоеля Спольски «Работа над ошибками малой кровью» аж 2000 года

http://russian.joelonsoftware.com/Articles/PainlessBugTracking.html

Comments are closed.