Кстати, интересно, а какая собственно разница между требованием, тест-кейсом и баг-репортом?
Требование описывает позитивный сценарий работы системы, ту возможность, которую приложение предоставляет пользователю.
"У пользователя должна быть возможность сложить два числа в калькуляторе"Приёмочный тест-кейс описывает пример такого сложения. В нем может быть предусловие, есть шаги (действия) и проверка, которую также можно назвать постусловием, описывающим то, как что конкретно и как должно изменится.
Пользователь может складывать два положительных числа:
Результатом операции 2 + 2 должно быть 4
Пользователь может складывать два отрицательных числа:
Результатом операции -2 + -2 должно быть -4
И так далее…
Что же такое баг? По сути, это тест-кейс, который обязательно должен содержать актуальное поведение системы, и, возможно, ожидаемый результат.
"После того, как я ввожу операцию 2 + 2 в калькулятор и нажимаю на кнопку равно – система зависает. (см. видео)"В данном примере баг-репорта описание ожидаемого значения не приводится. Зачем? Писать: "А я на самом деле ожидал, что система не зависнет и в результате выдаст 4"? В данном примере это и так понятно, что, наверное, система не должна зависать. Нужна ли нам информация о том, что в результате должно быть 4? Скорее всего – нет, по крайней мере, не в этом баге. Ведь этот баг про "зависание" системы, а не про правильный подсчет.
Не хватает контекста… ну, пусть калькулятор который мы разрабатываем, на самом деле будет использоваться также кассирами в супермаркете. И суммировать он будет не простые числа, а цены купленных товаров.
Странно, почти все забыли об этом контексте, а спецификация уже написана и подписана, и уже вышла первая версия приложения для внутреннего тестирования.
Давайте напишем баг:
Заголовок: Результат операции должен быть отформатирован в соответствии формату цены
Дано я хочу сложить цены двух товаров
Когда я складываю товар с ценой "$2" и "$2"
То ожидаю получить "$4.00" в результате
Но, на самом деле результат был "4"
На рабочем английском, это будет выглядеть так:
Title: The operation result should correspond to the currency format
Given I want to add two items
When I add the item with prize "$2" and the item with prize "$2"
Then the result should be "$4.00"
But, the actual result was "4"
Странно, что в нашем наборе приемочных тестов не было такого. Хм… а что нужно сделать чтобы баг-репорт превратился в приемочный тест? Правильно! – Удалить последнюю строку с актуальным значением и оставить только ожидаемое.
Вот еще один пример с контекстом. В данном случае, баг не имеет никакого отношения к требованием, а просто описывает поведение системы.
В "стандартном" варианте:
Заголовок: Ошибка при удалении сотрудника: Internal Server Error после редактирования имени
Предусловие:
Создан проект "Новый проект 1"
В проект добавлен сотрудник "Вася Форточкин"
Зайдите на главную страницу проекта
Шаги:
Измените имя сотрудника "Вася Форточкин" на "Вася Пупкин"
Сохраните изменения
Попробуйте удалить сотрудника из проекта
После этого действия появляется страница со след ошибкой:
" Internal Server Error "
См. скриншот [ошибка_при_удалении_сотрудника.png]
В формате Given When Then:
Заголовок: Ошибка при удалении сотрудника: Internal Server Error после редактирования имени
Дано: создан проект "Новый проект 1"
И в проект добавлен сотрудник "Вася Форточкин"
И я нахожусь на Главной Странице проекта
И я изменил имя сотрудника "Вася Форточкин" на "Вася Пупкин"
И сохранил изменения
Когда я пытаюсь удалить сотрудника из проекта
Тогда появляется страница со след. ошибкой:
"Internal Server Error"
См. скриншот [ошибка_при_удалении_сотрудника.png]
Только не подумайте, я не пишу такие баг-репорты по каждой опечатке в тексте на страницах приложения.
Для меня формат "Given When Then" позволяет намного четче выделить предусловия, действия и ожидаемый результат. Предусловия или контекст начинается со слова "Given" (Дано). Некоторое важное действие начинается со слова "When" (Когда) ожидаемый и актуальный результат начинается со слов "Then" (Тогда/То) или "But" (Но). Присмотритесь – структура очень четкая.
По началу, разработчикам такой формат был непривычен, но понятен. По крайней мере, мне очень редко возвращали баги назад потому, что разработчик не мог понять, в чем проблема. Зачастую, саму проблему было сложно описать словами, и тогда в ход шла запись видео.
Да, и, наверное, главный вопрос. А какая разница между "стандартным" подходом и Given When Then? В общем – нет никакой разницы. Это просто альтернативные пути, которые ведут к цели. Мне больше нравится второй, но и первым я не брезгую.
Главное, чтобы баг-репорт был понятным.
Комментариев нет:
Отправить комментарий