Когда вы заводите баг, нужно обосновать свой ожидаемый результат. Почему именно так должно быть?
Иногда обоснование вообще не пишут, так как «это же очевидно!». Или говорят: «Так правильно, мамой клянусь!». Или упирают на эмоции (зайчики обиделись). Но это все — плохие обоснования.
Лучше расскажите о какой-то реальной проблеме пользователя.
Потому что мы с вами – тестировщики. Наша задача — крушить и ломать, вводить «Войну и мир» в короткое поле, редактировать одну запись в двух вкладках браузера и прочая, прочая. И даже если у нас что-то не работает, это не значит, что пользователь тоже будет так поступать.
И иногда баги не исправляют просто потому, что «да никто так не делает!». И это нормально. Зачем тратить силы и ресурсы на проблему, которая никогда не возникнет?
Особенно это касается проблем с usability. Как мы помним, то, что удобно айтишнику, неудобно простому пользователю. И наоборот! И получается, что если мы просто пишем «Ну это неудобно...» — это плохое обоснование, мало ли что неудобно тебе, остальных все устраивает. А вот если мы собираем фидбек от пользователей, аттачим их письма, в которых они нам жалуются, то это сразу говорит о том, что такая проблема действительно существует. И это уже повышает ее приоритет.
Проблема реального заказчика всегда лучше, чем просто какой-то негативный тест от тестировщика.
Это не значит, что на проблемы тестировщиков никогда не исправляют. Если проблема есть у вас, тоже жалуйтесь! Может, разработчик может вам помочь буквально за 5 минут, просто он не в курсе ситуации.
Пожалуйтесь, не бойтесь! Может, вы страдаете, а разработчик даже не догадывается об этом. И может быть, он сможет быстро исправить вашу проблему, здесь и сейчас. А может и не исправить, но подсказать путь обхода.
Конечно, если проблема разовая, или сейчас исправлять ее слишком долго, то задача оптимизации уедет в следующий релиз или дальше. Но стоит хотя бы обсудить «как это можно улучшить» и поставить задачу. Ведь если задачи нет — никто ничего не сделает.
Есть разные случаи проблем:
— проблема заказчика;
— проблема реального пользователя;
— проблема тестировщика;
— проблема внутри команды;
Одни более приоритетны, другие менее. И все же, если мы описываем реальный кейс и реальную проблему, то у такой задачи больше шансов на исправление, чем у «очевидно же, так всем будет лучше».
Да, нужно понимать, что, даже если мы опишем, как реальным пользователям плохо, это все равно не гарантирует того, что мы исправим баг, но такова жизнь. В любом случае, если мы хотя бы описали проблему, то будет как минимум понятно, почему мы вообще поставили эту задачу. Даже если мы вернемся к нему через месяц, два или три. Мы всегда увидим, почему мы считали, что пользователям плохо и неудобно с этим работать.
Напомню плохие обоснования багов
Другие хорошие варианты, кроме проблемы:
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Иногда обоснование вообще не пишут, так как «это же очевидно!». Или говорят: «Так правильно, мамой клянусь!». Или упирают на эмоции (зайчики обиделись). Но это все — плохие обоснования.
Лучше расскажите о какой-то реальной проблеме пользователя.
Потому что мы с вами – тестировщики. Наша задача — крушить и ломать, вводить «Войну и мир» в короткое поле, редактировать одну запись в двух вкладках браузера и прочая, прочая. И даже если у нас что-то не работает, это не значит, что пользователь тоже будет так поступать.
И иногда баги не исправляют просто потому, что «да никто так не делает!». И это нормально. Зачем тратить силы и ресурсы на проблему, которая никогда не возникнет?
Особенно это касается проблем с usability. Как мы помним, то, что удобно айтишнику, неудобно простому пользователю. И наоборот! И получается, что если мы просто пишем «Ну это неудобно...» — это плохое обоснование, мало ли что неудобно тебе, остальных все устраивает. А вот если мы собираем фидбек от пользователей, аттачим их письма, в которых они нам жалуются, то это сразу говорит о том, что такая проблема действительно существует. И это уже повышает ее приоритет.
Проблема реального заказчика всегда лучше, чем просто какой-то негативный тест от тестировщика.
Это не значит, что на проблемы тестировщиков никогда не исправляют. Если проблема есть у вас, тоже жалуйтесь! Может, разработчик может вам помочь буквально за 5 минут, просто он не в курсе ситуации.
Тестируя новую фичу, я покрываю ее автотестами. Фреймворк для тестов уже давно есть, мы к нему привыкли. Тесты похожи друг на друга, поэтому копипастятся — ведь обычно мы меняем один какой-то параметр, оставляя остальное неизменным. Это принцип «1 тест = 1 проверка», чтобы падение теста сразу указывало на причину.
И вот мне надо из автотеста в автотест копипастить параметры. И я должна их раскопипастить из первого теста во второй, в третий, в четвертый, в пятый, в десятый... И в этой копипасте мне надо поменять лишь 1 значение в одной строчке, и если я это не сделаю, у меня все развалится со страшной ошибкой.
Разумеется, когда я копипастой занимаюсь, то хоть где-то да ошибусь... В итоге я написала 30 тестов, запустила их одним разом, и у меня все свалилось с NPE. Я сижу, чешу голову и думаю «блин, где же я ошиблась».
Я весь день разбираюсь, ищу ошибку, запускаю автотесты... Пытаюсь найти баг или место, где я облажалась. В итоге нахожу и потом на следующем митинге жалуюсь:
— Я вчера весь день писала эти автотесты, потому что ошиблась в пятом тесте и потом долго пыталась понять, в чем причина падения. Ох уж эта копипаста!
И тут разработчик говорит:
— Да подошла бы ко мне, я бы тебе за полчаса все зарефакторил и починил эту проблему.
А что, так можно было?!!
Пожалуйтесь, не бойтесь! Может, вы страдаете, а разработчик даже не догадывается об этом. И может быть, он сможет быстро исправить вашу проблему, здесь и сейчас. А может и не исправить, но подсказать путь обхода.
Конечно, если проблема разовая, или сейчас исправлять ее слишком долго, то задача оптимизации уедет в следующий релиз или дальше. Но стоит хотя бы обсудить «как это можно улучшить» и поставить задачу. Ведь если задачи нет — никто ничего не сделает.
Есть разные случаи проблем:
— проблема заказчика;
— проблема реального пользователя;
— проблема тестировщика;
— проблема внутри команды;
Одни более приоритетны, другие менее. И все же, если мы описываем реальный кейс и реальную проблему, то у такой задачи больше шансов на исправление, чем у «очевидно же, так всем будет лучше».
Да, нужно понимать, что, даже если мы опишем, как реальным пользователям плохо, это все равно не гарантирует того, что мы исправим баг, но такова жизнь. В любом случае, если мы хотя бы описали проблему, то будет как минимум понятно, почему мы вообще поставили эту задачу. Даже если мы вернемся к нему через месяц, два или три. Мы всегда увидим, почему мы считали, что пользователям плохо и неудобно с этим работать.
Напомню плохие обоснования багов
Другие хорошие варианты, кроме проблемы:
См также:
Комментариев нет:
Отправить комментарий