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