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