Кодекс поведения по обеспечению качества

Question

Я не смог найти хороших ресурсов о кодексе поведения QA и хотел бы начать документировать это. Основной вопрос, который у меня есть, это действительно простые вещи, такие как:

• Кто-то сообщает, что «дизайн нарушен», когда реальная проблема заключается в том, что они используют IE6 и не обновили свой кэш.
• Член команды говорит, что вы сломали сборку, когда на самом деле они не получили последнюю версию из системы контроля версий.
• Кто-то жалуется, что его данные теряются при переходе на определенную страницу, не объясняя, как они туда попали.

Мне бы очень хотелось, чтобы документ, который я мог раздать клиентам или членам команды, в следующий раз, когда они жалуются, что «этот код отстой», когда на самом деле они должны сказать «этот код не соответствует нашим бизнес-целям».

Answer 1

Это больше похоже на межличностную проблему, нежели на техническую (за исключением, может быть, последней точки).

Если вы чувствуете, что люди не вежливы и не уважают друг друга, есть много решений (консультирование, коучинг и т. Д.), Но их следует рассматривать и рассматривать как социальную проблему, а не техническую.

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

Существуют некоторые рекомендации для сообщения об ошибках, например ::1007*.

https://developer.mozilla.org/en/Bug_writing_guidelines

http://catb.org/esr/faqs/smart-questions.html

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

Answer 2

Потратьте несколько минут, чтобы поговорить с кем-то лично, если это возможно, и в противном случае по телефону.

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

Вам необходимо получить от общения на уровне

эта штука отстой

до

'Я действительно запутался, когда я делаю то и это, а потом это происходит и т. Д.'

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

Вам также может понадобиться помочь им понять, почему все так, как они есть.

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

Answer 3

Несколько хороших ответов здесь. Мы знаем, что нам нужно в хорошей базе данных для отслеживания ошибок. Те же самые функции, должным образом реализованные, способствуют обучению репортера ошибок.

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

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

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

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

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

Answer 4

Несмотря на то, что сообщения об ошибках типа «это не работает» не очень полезны, вы должны понимать, что не каждый программист.

Большинство людей, которые «жалуются», просто не знают, какую информацию они МОГУТ предоставить, чтобы быть более полезными, и предполагают, что вы знаете, о чем они говорят. Они также часто не знают о своем «тоне», потому что они не всегда используются для точного письменного общения (даже типы менеджеров могут явно не знать об этом - программисты OTOH склонны быть полными фанатиками, потому что они привыкли иметь плотно упакованная семантика в коротком блоке текста, потому что это то, что они делают для жизни).

Вам необходимо объяснить, что вам нужно знать, чтобы понять ошибку (т.е. иметь возможность ее воспроизвести или отследить). Такие правила, как Mozilla, очень помогают, если они присутствуют в системе отслеживания ошибок. Если ваша система отслеживания ошибок в основном состоит в том, что QA отправляет вам гневные письма, вам, вероятно, будет лучше, если вы действительно поговорите с ними лично и объясните им, как они могут быть более полезными, если они заботятся.

Если им не все равно, вы все равно облажались.

Answer 5

Может помочь древняя статья Джоэля: Отслеживание безболезненных ошибок , откуда:

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

1. Шаги для воспроизведения,
2. То, что вы ожидали увидеть, и
3. То, что вы видели вместо этого.

Кажется, легко, правда? Возможно, нет. Как программист, люди регулярно назначают меня ошибки, где они оставили один кусок или другой.

Answer 6

Я в замешательстве - когда вы говорите Мне бы очень хотелось, чтобы документ, который я мог раздать клиентам или членам команды, в следующий раз, когда они жалуются, что «этот код отстой» , когда на самом деле они должны сказать, что «этот код не достичь наших бизнес-целей ".
Какая разница? терминология? код - отстой, или не выполняет, или, что еще хуже, не использует его, не платит вам за это и теряет клиентов, заставляет задуматься о том, что вместо того, чтобы беспокоиться о том, как они это говорят, следует сосредоточиться на том, как на самом деле доставить код / ​​приложение туда, где оно должно быть чтобы получить более положительный ответ. Будьте счастливы, что они дают обратную связь и просто не игнорируют вас / вашу компанию. Получите все отрицательные отзывы, которые вы можете, объективно посмотрите на само приложение и определите, какие шаги необходимы, чтобы привести его в форму.