Иногда кажется, что ожидаемый результат в баге писать вообще не нужно. Например, когда в системе краш — все развалилось. Казалось бы, зачем тут ОР? И если ОР — «Система не должна падать», то он действительно выглядит лишним. Текст ради текста, от которого мы хотим избавиться.
НО!
Никто и не просит писать «система не упала». Напишите, что именно она должна была сделать. Открыть главную страницу? Вернуться назад? Выдать какое-то сообщение об ошибке?
Да, это бывает очевидным. Если мы грузим главную страницу и тут БАХ, эксепшен. А должна открыться главная. Л — логика. Но такие баги возникают редко и обычно на проектах с начинающими разработчиками, которые легко «ломают» странички, забыв поставить точку с запятой в коде.
А вот если разработчик уровнем повыше, то падение обычно означает, что в системе что-то пошло не так. Он такого развития не предусмотрел и просто не знает, что именно тут надо сделать. Например, при вводе данных происходит деление на ноль в отчете. Что делать? Данные не давать вводить? Отчет не грузить? Или грузить, но ставить 0 в ячейке? Или что?
Или вы нажимаете «Назад», а туда нельзя из-за соображений безопасности. Например, на прошлом экране вы оплачивали обработку файла. И если «назад» работает, то можно дважды списать денег за файл. И вот тестировщик ставит баг с ОР: «такого быть не должно». Ок, бро. А как должно то? Назад пустить, но денег повторно не списать? Редиректнуть на главную страницу? Или на форму исходной загрузки файла? Что именно ожидает тестировщик?
Если вы не напишите свои ожидания, разработчик сделает так, как сам считает правильным. И если вам не понравится его вариант, то вы будете переоткрывать задачу:
— Нет, так плохо! Пусть лучше будет вот так!
— Сразу бы так и сказал.
И ведь прав разработчик, прав! Сказали бы сразу, быстрее получили бы фикс. А сейчас, возможно, разработчику некогда уже, переключился на другие задачи...
НО!
Никто и не просит писать «система не упала». Напишите, что именно она должна была сделать. Открыть главную страницу? Вернуться назад? Выдать какое-то сообщение об ошибке?
Да, это бывает очевидным. Если мы грузим главную страницу и тут БАХ, эксепшен. А должна открыться главная. Л — логика. Но такие баги возникают редко и обычно на проектах с начинающими разработчиками, которые легко «ломают» странички, забыв поставить точку с запятой в коде.
А вот если разработчик уровнем повыше, то падение обычно означает, что в системе что-то пошло не так. Он такого развития не предусмотрел и просто не знает, что именно тут надо сделать. Например, при вводе данных происходит деление на ноль в отчете. Что делать? Данные не давать вводить? Отчет не грузить? Или грузить, но ставить 0 в ячейке? Или что?
Или вы нажимаете «Назад», а туда нельзя из-за соображений безопасности. Например, на прошлом экране вы оплачивали обработку файла. И если «назад» работает, то можно дважды списать денег за файл. И вот тестировщик ставит баг с ОР: «такого быть не должно». Ок, бро. А как должно то? Назад пустить, но денег повторно не списать? Редиректнуть на главную страницу? Или на форму исходной загрузки файла? Что именно ожидает тестировщик?
Если вы не напишите свои ожидания, разработчик сделает так, как сам считает правильным. И если вам не понравится его вариант, то вы будете переоткрывать задачу:
— Нет, так плохо! Пусть лучше будет вот так!
— Сразу бы так и сказал.
И ведь прав разработчик, прав! Сказали бы сразу, быстрее получили бы фикс. А сейчас, возможно, разработчику некогда уже, переключился на другие задачи...
Типичная ошибка
Результат: Все работает корректно.
Что такое «корректно»? Для ожидаемого результата это такое же стоп-слово, как для названия. Задайте себе вопрос, что именно означает «работает корректно» и запишите ответ.
См также:
Как заводить задачи в баг-трекер — в целом о заведении задачи
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Комментариев нет:
Отправить комментарий