Home

Автор: Вячеслав Дукальский

Для фиксирования багов во многих организациях приняты различные CTS (Change Tracking Systems). Все эти системы могут отличаться исполнением, дизайном, возможностями, но всегда будет то общее, сама суть, что их объединяет — наличие сообщения о найденной ошибке.

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

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

• Заголовок
• Описание/Шаги возпроизведения ошибки
• Номер билда тестируемого продукта (при необходимости можно включить также номер версии и его язык)
• Получатель сообщения
• Степень важности
• Присоединенные файлы с тестовыми материалами (логи, скриншоты, дампы памяти и т.д.)
• Операционная система (в большинстве случаев с указанием ее версии, SP или hotfix’a)

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

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

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

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

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

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

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

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

Итак, суммируя все вышеизложенное, придерживайтесь следующих правил:

• Используйте шаблоны везде, где это возможно
• Пишите коротко и ясно. Не нужно историй.
• Один баг ссылается на одну проблему. Не совмещайте два бага в один.
• Не пишите одну и ту же вещь снова и снова. Напишите ее один раз в CTS и ссылайтесь на нее во всех других местах.