Как готовится хороший баг?

Рассмотрим еще одну интересную тему "Рецепт хорошего бага" (источник: http://www.xmind.net/m/kwhk). Ниже представлена схема построения бага. Разберем по частям.

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

Дефект для разработчика – это корректировка упущенной (или специально пропущенной?:) ) части функционала.

Для аналитика дефект показывает:

1)    Возможно ошибку в описании функционала, что позволяет исправить ее на ранней стадии проекта

2)    Оценить корректность описанного функционала, ведь тестировщик (как говорилось выше) и аналитик могут воспринимать описанный функционал для разработки по разному

3)    Оценить объем работ и результативность разработки на данном этапе, так как чаще всего аналитик напрямую общается с заказчиком.

Так же, иногда, дефекты просматриваются заказчиком. И что для тестировщика может быть дефектом, заказчик воспримет как «фичу» )).

Для тестировщика обнаружение дефектов – это его работа.

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

У себя на проектах я работала с TFS и MTM, который взаимодействует с TFS, а также с Readmine.

Также необходимо на первом этапе определить жизненный цикл дефекта. В TFS на одном из проектов он выглядел у нас так: proposed – active на разработчике – resolved на тестировщике – active на разработчике (если не исправлен ) или closed на тестировщике (если исправлен). Определение ЖЦ бага позволяет исключить недопонимание между разработчиком и тестировщиком при работе с багом на проекте.

В трекинговой системе чаще всего реализованы автогенерируемые поля: 

·       Уникальный идентификатор 

·       Дата и время обнаружения дефекта 

·       Автор 

В TFS автоматически проставляется также приоритетность и критичность бага для всех одинаковая.

          Для работы с багом важно правильно указать его название. Оно должно быть настолько емким, насколько это возможно, поскольку дефект отображается в блоке-трекере и по ему в первую очередь оценивается объем работы при исправлении и локация бага. Например, такое название, как «Не работает кнопка» не позволяет определить локацию бага и кому его исправлять (front или backend). А если указать такое название: «Кнопка войти не кликабельна на странице авторизации» (front) или «После клика по кнопке войти не выполняется валидация пользователя» (backend), то разработчики быстрее определят кому чинить и куда смотреть.

          Следующим важным компонентом является описание обнаружения, расположения и других критерий дефекта: 

1. Исходное состояние системы 

- Должно быть ясно, недвусмысленно 

- Мы указываем пошаговый сценарий для воспроизведения дефекта. Если сценарий не ясен, разработчики возвратят ошибку с комментарием: он не воспроизводится. Это приведет к перенапряжениям (дополнительное определение и, как следствие, возможна задержка релиза) 

2. Ожидаемое поведение 

3. Полученный результат 

4. Приложения

- Журналы 

- Экранные снимки 

- Пользовательские файлы 

- Сертификаты 

- Информация из базы данных 

- Другие

5. Версия продукта

6. Область приложения, в которой обнаружен дефект. Например: Регистрация, администрирование, роли и т. Д. Можно указывать как «Тэг».

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

7. Дата и время 

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

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

8. Итерационный номер / Id, в котором обнаружен дефект

9. Критичность и приоритет 

Критичность - это степень отрицательного воздействия дефекта на продукт

·       S1 - Критический 

- Последствия: Неспособность пользователя работать с продуктом 

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

·       S2 - Hight 

- Последствия: не соответствуют ожидаемым требованиям пользователей 

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

·       S3 - средний 

- Последствия: Неисправность или неправильная работа части пользовательских функций 

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

·       S4 - Низкий 

- Последствия: пользователь раздражается при работе с продуктом 

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

Приоритет -это порядок, в котором дефекты должны быть исправлены. Чем выше приоритет, тем скорее вам нужно исправить дефект. 

·       P1 - Высокий 

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

·       P2-Medium 

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

·       P3- Низкий 

Дефект должен быть исправлен, его доступность не является критичной и не требует срочного решения. 

·       P4-Min 

Неисправность дефекта не требуется, поскольку текущая функциональность не обновляется или будет изменена в ближайшем будущем 

10. Ссылка на задачу или на тест - кейс 

11. Теги, указывающие на этап тестирования: 

- Переделать. Используется для дефектов, которые не были зафиксированы в первый раз 

- NoTestCase 

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

- Регресс. Используется для регрессионного тестирования. 

- Релиз. Используется для дефектов, которые были найдены командой по выпуску сборки

- Пропущено. Используется для дефектов, от пользователей 

- Sourse. Указывает этап жизненного цикла итерации, на котором была введена ошибка. Например, планирование, разработка и т. Д. Индикатор необходим для оценки стоимости (в условных единицах) дефекта: чем раньше была введена ошибка и впоследствии обнаружена, тем выше ее стоимость.

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