Когда вы заводите баг, нужно обосновать свой ожидаемый результат. Почему именно так должно быть? Иногда результат вообще не пишут, так как «это же очевидно!»
У меня на курсе такое обоснование не проканает. Когда студент это понимает, он переходит на следующую стадию гнева, отрицания, и обоснования багов, которая называется «Мамой клянусь!». Это когда мы просто говорим, что так правильно, не объясняя, почему.
То есть обоснование выглядит примерно так:
Но такое обоснование снова не отвечает на мой вопрос «Но почему?». Почему ты решил, что так правильно? Я все еще не ванга и не телепат, и я не знаю, почему ты считаешь это правильным.
По сути это мало чем отличается от ситуации «вообще ничего не написал, потому что это очевидно». Поэтому я и называю это второй стадией — именно по такому сценарию обычно и развиваются события, сначала «очевидно», потом «да так точно правильно». Посмотрим на примере из жизни студентов:
Конечно, тут не надо доходить до крайностей и давать ссылки на словари, когда вы ставите баг на опечатку или пропущенную запятую. И все же «Пётр» — нетривиальный пример, это ведь исключение из правил. Всегда работает так, а для Петра иначе.
Поэтому тут ссылка будет нелишней. Особенно если разработчик спросил «А разве так правильно?». Можно обвинить его в глупости и неграмотности и испортить отношения. А можно дать ссылку, мягко подтвердив свою точку зрения.
Но ок, возьмем другой пример, не про правила русского языка, которые «так очевидны».
Такое обоснование больше похоже на «Мне лень пойти погуглить, поискать факты. Верьте на слово». Когда у нас нету фактов и доказательств, есть стремление завуалировать свое обоснование и написать «Наверное, возможно, наверняка...».
Но это СТОП-слова! Если у вас возникает желание их написать — значит, у вас нет реальных фактов. Значит, вы просто додумываете. А почему нужно делать задачу, основанную на фантазии тестировщика? Докажите свою теорию!
Конечно, гуглить тяжело. Искать факты — это занимает время. Куда проще сказать «наверное, так и есть». Вдруг разработчик думает так же? Тогда обоснование прокатит. А если он считает иначе, тогда уже и погуглим...
А если фактов нет? Тогда задачу даже заводить не стоит. Да, сложно отказываться от «своего, родного» бага. Но это тоже надо уметь.
Вместо абстрактного «да такие люди точно есть!» приводите ФАКТЫ.
А при постановке задачи используйте принцип 5 почему. Записывая ожидаемый результат, спросите себя «А почему я именно это ожидаю?». Первый ответ будет «Это же очевидно», но снова задайтесь вопросом «А почему?». И если заметите, что никаких данных нет, просто вам так кажется — поищите факты или обсудите ситуацию с коллегами.
Другие антипаттерны обоснования задач:
Хорошие обоснования:
У меня на курсе такое обоснование не проканает. Когда студент это понимает, он переходит на следующую стадию гнева, отрицания, и обоснования багов, которая называется «Мамой клянусь!». Это когда мы просто говорим, что так правильно, не объясняя, почему.
То есть обоснование выглядит примерно так:
Результат
57,6
Ожидаемый результат
57.9, потому что так правильно
Но такое обоснование снова не отвечает на мой вопрос «Но почему?». Почему ты решил, что так правильно? Я все еще не ванга и не телепат, и я не знаю, почему ты считаешь это правильным.
По сути это мало чем отличается от ситуации «вообще ничего не написал, потому что это очевидно». Поэтому я и называю это второй стадией — именно по такому сценарию обычно и развиваются события, сначала «очевидно», потом «да так точно правильно». Посмотрим на примере из жизни студентов:
Пётр и индусы
Наша система умеет склонять имена по падежам. Студент проверяет имя Пётр. Знаете, как оно склоняется? В именительном падеже оно пишется через букву Ё, а во всех остальных — через Е. «Пётр, но Петру».
И вот я захожу в баг-трекер и читаю такой баг: «Пётр склоняется по падежам через букву ё, а должно через е».
Я спрашиваю:
— А почему ты так считаешь?
— Ну очевидно же, что через Е надо (первая стадия)
— Почему ты считаешь, что это очевидно?
— Но это же по правилам русского языка так!
— По каким правилам?
— Ну что, я вам должен бегать и гуглить правила русского языка? (вторая стадия — так правильно, верьте мне)
— ДА! Да, именно это ты и должен делать. Потому что это будет уже обоснованием бага. Потому что, возможно, что твой разработчик индус, может быть, ты тоже индус. И вы не знаете правил русского языка! Так дай на них ссылку, и все вопросы сразу отпадут.
Конечно, тут не надо доходить до крайностей и давать ссылки на словари, когда вы ставите баг на опечатку или пропущенную запятую. И все же «Пётр» — нетривиальный пример, это ведь исключение из правил. Всегда работает так, а для Петра иначе.
Поэтому тут ссылка будет нелишней. Особенно если разработчик спросил «А разве так правильно?». Можно обвинить его в глупости и неграмотности и испортить отношения. А можно дать ссылку, мягко подтвердив свою точку зрения.
Но ок, возьмем другой пример, не про правила русского языка, которые «так очевидны».
Емейл .рф
Эту задачу очень любят заводить мои студенты (почти каждый поток ее оформляют):
— Я пытаюсь зарегистрироваться с емейлом .рф и не могу. Это баг!
— Почему?
— Как это почему? Мы живем в России, такие емейлы есть у всех!
Я рассказывала этот кейс на конференции DUMP (вот видео выступления), и у меня был полный зал слушателей. Я попросила поднять руки тех, у кого есть такой емейл. Из 200 человек руки подняли три человека.
То, что мы живем в России, вообще не говорит о том, что у всех есть такие емейлы. Ну да, ну да... А еще ручные медведи и матрешки...
Причинно-следственной связи здесь нет, просто сложно отказаться от своей идеи. Ведь вот же, я баг нашел! Как это может оказаться не багом?? Такой классный же. Россия же, очевидно же! Нет, не очевидно? Ну все равно Россия, НАВЕРНЯКА таких много.
Такое обоснование больше похоже на «Мне лень пойти погуглить, поискать факты. Верьте на слово». Когда у нас нету фактов и доказательств, есть стремление завуалировать свое обоснование и написать «Наверное, возможно, наверняка...».
Но это СТОП-слова! Если у вас возникает желание их написать — значит, у вас нет реальных фактов. Значит, вы просто додумываете. А почему нужно делать задачу, основанную на фантазии тестировщика? Докажите свою теорию!
Конечно, гуглить тяжело. Искать факты — это занимает время. Куда проще сказать «наверное, так и есть». Вдруг разработчик думает так же? Тогда обоснование прокатит. А если он считает иначе, тогда уже и погуглим...
А если фактов нет? Тогда задачу даже заводить не стоит. Да, сложно отказываться от «своего, родного» бага. Но это тоже надо уметь.
Емейл.рф — факты
Какие тут могли бы быть факты?
Во-первых, мы можем делать наш сайт для каких-то гос заказчиков, которых обязуют регистрироваться именно в домене .рф. Корпоративный стандарт, у них нет выхода.
Или у нас действительно есть много таких заказчиков, это показывает статистика.
Например, в логах много ошибок «попытка зарегаться через такой домен». И возможно, тогда стоит сделать эту фичу. Чтобы не потерять потенциальных клиентов.
На основании таких фактов РМ принимает решение, будем делать задачу или нет. И если будем, то когда. А может сказать «ну есть ошибки, и ладно, их меньше 1% общих регистраций, не будем делать»
Вместо абстрактного «да такие люди точно есть!» приводите ФАКТЫ.
А при постановке задачи используйте принцип 5 почему. Записывая ожидаемый результат, спросите себя «А почему я именно это ожидаю?». Первый ответ будет «Это же очевидно», но снова задайтесь вопросом «А почему?». И если заметите, что никаких данных нет, просто вам так кажется — поищите факты или обсудите ситуацию с коллегами.
Другие антипаттерны обоснования задач:
Хорошие обоснования:
См также:
Зачем нужно обоснование в баге
Паттерны и антипаттерны обоснования задач — общая статья
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Паттерны и антипаттерны обоснования задач — общая статья
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Комментариев нет:
Отправить комментарий