Паттерны и антипаттерны обоснования задач

Ссылка на Хабр

Исходно статья опубликована на Хабре, там у нее есть удобное оглавление, чтобы не листать многабукафф, а сразу перейти куда надо. В блоггере такое сделать сложнее, увы и ах  ╮(︶︿︶)╭

Когда вы заводите задачу, ее нужно обосновать. Вы должны убедить разработчика, что:

• это действительно баг;
• его необходимо исправить;
• его нужно исправить именно так, как мы сказали.

А то иногда читаешь баги (особенно баги новичков) и задаешься вопросом:
— Почему это баг??

Например, там написано: «Загружаем отчет, получаем 57,6. А должно быть — 57.9».

Если записать обоснование, это решит проблемы:

• Коллеги отвлекают с вопросами «А почему это баг?», вырывая из контекста.
• Спустя месяц ты сам забыл, а, собственно, почему это был баг…

См также:
Зачем нужно обоснование в баге — более подробно о том, зачем вообще обоснование.

Через меня прошли сотни начинающих тестировщиков (студентов). Вот как раз на их задачах я и начала задаваться вопросом «А почему это баг?»… Спрашиваешь ребят, а в ответ получаешь «Да это же очевидно!». Ну как-то не очень =))

Через кучу задач и вопросов «А почему?» стали вырисовываться паттерны ответов. Я выделила хорошие и плохие паттерны. О них и хочу рассказать.

Эта статья для:

• начинающих тестировщиков — узнайте, как грамотно объяснять свою точку зрения;
• тест-менеджеров — чтобы дать ссылку своим падаванам и потом ссылаться на антипаттерны без дополнительных объяснений.

Антипаттерны: плохое обоснование

Три ступени гнева, отрицания и обоснования багов:

1. Очевидно же — Нам очевидно, вот и не обосновываем. А потом получаем «ой, я забыл, почему так хотел»… Это очевидно только вам, только здесь и только сейчас. Через полгода сами забудете, почему именно так. Объясните как для тупых, что там за очевидность такая.
2. Мамой клянусь, так правильно! — Зачем клясться? Почему-то же вы считаете, что так правильно, вот и расскажите, почему. Дайте ссылку на требования, например.
3. Зайчики обиделись — «Ах ты не добавил котика на главную? Ну все! Я обиделся… И УШЕЛ! А вы! Потеряли клиента!!». Но то, что неудобно вам, может быть удобно другим. Так что уберите эмоции и приведите факты.

Каждое название паттерна кликабельное, переходит на более подробную статью о нем

Хорошие паттерны обоснования

Вместо антипаттернов стоит использовать правильное обоснование:

1. Пруфлинк — ТЗ, интернет, письмо клиента, в котором он просил этот функционал...
2. Единообразие — Если система всегда работает так, а в одном месте по-другому, стоит исправить!
3. Проблема — опишите проблему, которая возникает у вас, или у пользователя (если вы общаетесь с клиентами). Реальная проблема всегда лучше, чем просто негативный тест.

См также:

Когда обоснование бага не нужно — бывает и так ¯\_(ツ)_/¯

Итого

Обязательно пишем, почему мы решили, что это действительно баг и почему мы хотим, чтобы его исправили именно так, как мы тут написали. Задаем себе вопросы из серии «5 почему»

— почему я считаю, что это очевидно?
— почему я считаю, что так правильно?
— почему я считаю, что пользователи расстроятся?

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

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

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков