четверг, 3 января 2019 г.

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

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


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


Когда вы заводите задачу, ее нужно обосновать. Вы должны убедить разработчика, что:
  • это действительно баг;
  • его необходимо исправить;
  • его нужно исправить именно так, как мы сказали.
А то иногда читаешь баги (особенно баги новичков) и задаешься вопросом:
— Почему это баг??

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



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

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

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

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

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

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


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


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


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


Итого


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

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

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

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

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

Комментариев нет:

Отправить комментарий