Когда вы заводите баг, нужно обосновать свой ожидаемый результат. Почему именно так должно быть?
Иногда обоснование вообще не пишут, так как «это же очевидно!». Или говорят: «Так правильно, мамой клянусь!». Или упирают на эмоции (зайчики обиделись). Но это все — плохие обоснования.
Вместо голосновных утверждений надо использовать факты. И пруфлинк в этом плане — отличное обоснование!
Это может быть:
Ссылка на требования
Самый простой баг — когда есть ТЗ и система работает не так, как там описано.
Так и пишем в ожидаемом результате: «57,9, потому что так в ТЗ». Хм, хм... Погодите-ка. Это звучит как «мамой клянусь»…
Да, в такой формулировке так и звучит. Поэтому подтвердите свои слова ссылкой. Иначе разработчик читает баг, и ему надо:
Уважайте время коллег, и они будут вам благодарны.
Сами требования
Если требования хранятся НЕ в конфлюенсе или другой облачной системе, а в обычном ворде, прикладывайте тот документ, по которому вы тестируете.
Вполне возможно, что вы тестируете устаревшие требования. И если вы приложите прям ворд-файл, по которому проверяете, его может увидеть аналитик и сказать «Ой, погоди, мы уже 10 раз все поменяли, забыл выложить. На, держи!»
Если вы этого не сделаете, то потратите три часа на разборки с разработчиком, который скажет «а у меня по другому!». Вы будете бегать, смотреть его требования, потом ваши, потом искать аналитика, чтобы уточнить кто прав…
А так вы сразу вложили требования, разработчик посмотрел сказал «что-то какая-то фигня», перенаправил аналитику. Аналитик их писал, и он, открыв ваш ворд, сразу поймет, устарел он или нет. Вот и экономия времени!
Ссылка в интернет
Как мы помним, требования бывают далеко не всегда. И вместо них может быть... Ссылка в интернет! Да, почему бы и нет?
Если вспомним про наш пример «Пётр, Петру», то, даже если у нас в системе есть требования, врядли там написано «Система работает по правилам русского языка» и перечислены все правила русского языка. Конечно, так никто не пишет. И все равно получается, если хотите сослаться на правила русского языка, вам придется пойти их и погуглить.
Или если взять пример с Шарипат. Опять таки, с чего вы взяли, что это нормальное женское имя? Идем гуглим всякие казахские и прочие имена, находим Шарипат, находим другие похожие имена и даем ссылочку на эту страничку.
И тут уже, даже если разработчик с вами не согласен, он может прийти и сказать — «Смотри, ты дал ссылку на сайт, да это же желтая пресса какая-то, там всегда пишут фигню». Но если вы не дали ссылку, разработчику придется самому гуглить, самому искать всякие сайты и только тогда он поймет, что, возможно, вы напали на какие-то ложные сведения. Сэкономьте ему время, дайте сразу ссылку в интернет.
Да, здесь нужно понимать, что не каждая ссылка полезна и оправдана, но она как минимум покажет, почему вы считаете, что это действительно баг. Это вам уже не «мамой клянусь», а с обоснованием!
Письмо заказчика
Обоснованием может быть отсылка на письмо заказчика. У нас в джире есть даже отдельное поле, «Бизнес-обоснование», куда мы записываем, какой заказчик просил эту фичу. И тогда, когда мы читаем наш баг, то мы сразу же видим:
— Ага, бизнес-обоснование пустое. Это значит, что мы сами нашли эту проблему и считаем, что ее нужно поправить.
Либо:
— Ага, вот такой то заказчик на проблему жаловался 1 августа 2015 года
И если нам надо уточнить у этого Заказчика, что именно его не устраивает, то мы легко можем найти это письмо, ведь у нас есть вся информация (кто, когда, как называется письмо). Зная эту инфу, я пойду и найду письмо за 5 сек в своем аутлуке. Если этой инфы нет, то мне придется пойти в аутлук и искать среди 10 разных папочек — какой заказчик это просил и в каком письме?
К тому же, если мы видим, что эту фичу просили несколько разных заказчиков, то у нее сразу повышается приоритет. Так как мы понимаем:
— Ага, вот заказчик 1 жаловался тогда-то, через пару недель / месяцев жаловался заказчик другой. Хмммм, но ведь наверняка есть куча других заказчиков, которые тоже страдают, но молчат. Плачут, колются, но продолжают жрать кактус. Ведь не все будут писать нам и сообщать о проблеме…
Так что чем больше жалоб, тем выше приоритет. Так как мы понимаем, что это реальный пользователь пожаловался, у них действительно есть такие проблемы. И даже если мы вернемся к багу спустя полгода или год, благодаря вложенному письму или хотя бы ссылке на него всегда можно будет поднять историю задачи.
ROI
Мы можем попробовать подсчитать ROI — коэффициент окупаемости. Действительно ли нам нужно сделать эту фичу или исправить этот баг? Принесет ли это должный эффект?
Одно дело — внести мелкую правку на полчаса разработки, которая поможет сотням пользователей. Совершенно другое — из-за истерики одного пользователя две недели переделывать работу системы, которая всех остальных устраивает.
Если мы подсчитали ROI и видим, что овчинка стоит выделки — вкладываем расчеты в задачу. Но иногда после подсчетов выясняется, что делать задачу не нужно. И это — нормально! Значит, мы сэкономили время команды на обсуждение ненужной фичи.
Именно для этого мы и продумываем обоснование — потому что иногда кажется «Ах, какой баг, какой баг!», а потом начинаешь думать над обоснованием… И понимаешь, что фигня это, а не баг, даже заводить не стоит...
Статистика
Соберите статистику и вложите в задачу:
— количество ошибок в логах;
— количество жалоб в техподдержку;
— количество кликов на кнопку;
— количество пользователей, которые ушли на этапе оформления заказа (закрыли вкладку);
— …
То есть если вы считаете, что типовая форма оформления заказа в интернет-магазине «плохая» и ее надо улучшить — обоснуйте. Чем именно она плоха? Тем, что для ввода адреса надо знать свой индекс и заполнять 10 обязательных полей? А правда ли это плохо или раздражает только вас?
Учтите, что разработчики могут не видеть «очевидного» в своем ПО. Они ведь его разрабатывали, тестировали... Видят постоянно по 100 раз в день, уже привыкли к интерфейсу. Так что даже если он и правда устарел, нужны факты.
А собираются факты легко — просим сделать статистику, чтобы посмотреть, когда пользователь уходит со страницы. И если он добавил пиццу в корзину, а потом начал заполнять поля и после 5-7 плюнул и ушел, это не очень круто. А если так каждый третий поступает — точно стоит что-то улучшать!
Допустим, делаем мы бухгалтерское ПО. Нам кажется: «фу, мышкой никто не работает, надо сделать так, чтобы все работало из командной строки, чтобы мышку вообще не надо было трогать!». Мы тратим на этот функционал кучу времени, а реальные пользователи его вообще не используют. Потому что им нужна мышка, чтобы взять, тыкнуть на большую кнопку... А то что удобно программистам, им вообще до лампочки, так как им удобно совершенно другое.
И если вы хотите рассказывать всем, что нужно пользователям, сначала изучите usability-тестирование, а потом говорите, обидятся зайчики, или нет.
Только статистика честно расскажет о существовании проблемы. Если статистики нет, это будет всего лишь вкусовщина. А вкусы у всех разные. Тестировщику хочется кнопку красную, разработчику — зеленую, а дизайнеру — синюю. Так что ищите факты и давайте на них пруфлинк!
Напомню плохие обоснования багов
Другие хорошие варианты, кроме пруфлинка:
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Иногда обоснование вообще не пишут, так как «это же очевидно!». Или говорят: «Так правильно, мамой клянусь!». Или упирают на эмоции (зайчики обиделись). Но это все — плохие обоснования.
Вместо голосновных утверждений надо использовать факты. И пруфлинк в этом плане — отличное обоснование!
Это может быть:
- Ссылка на требования
- Сами требования (ворд файл, презенташка...)
- Ссылка в интернет
- Подсчитанный ROI
- Письмо заказчика
- Статистика
Ссылка на требования
Самый простой баг — когда есть ТЗ и система работает не так, как там описано.
Так и пишем в ожидаемом результате: «57,9, потому что так в ТЗ». Хм, хм... Погодите-ка. Это звучит как «мамой клянусь»…
Да, в такой формулировке так и звучит. Поэтому подтвердите свои слова ссылкой. Иначе разработчик читает баг, и ему надо:
- осознать, про какое ТЗ идет речь;
- найти само ТЗ;
- найти конкретное место, о котором речь;
- вчитаться…
Уважайте время коллег, и они будут вам благодарны.
Сами требования
Если требования хранятся НЕ в конфлюенсе или другой облачной системе, а в обычном ворде, прикладывайте тот документ, по которому вы тестируете.
Если вы этого не сделаете, то потратите три часа на разборки с разработчиком, который скажет «а у меня по другому!». Вы будете бегать, смотреть его требования, потом ваши, потом искать аналитика, чтобы уточнить кто прав…
А так вы сразу вложили требования, разработчик посмотрел сказал «что-то какая-то фигня», перенаправил аналитику. Аналитик их писал, и он, открыв ваш ворд, сразу поймет, устарел он или нет. Вот и экономия времени!
Ссылка в интернет
Как мы помним, требования бывают далеко не всегда. И вместо них может быть... Ссылка в интернет! Да, почему бы и нет?
Если вспомним про наш пример «Пётр, Петру», то, даже если у нас в системе есть требования, врядли там написано «Система работает по правилам русского языка» и перечислены все правила русского языка. Конечно, так никто не пишет. И все равно получается, если хотите сослаться на правила русского языка, вам придется пойти их и погуглить.
Или если взять пример с Шарипат. Опять таки, с чего вы взяли, что это нормальное женское имя? Идем гуглим всякие казахские и прочие имена, находим Шарипат, находим другие похожие имена и даем ссылочку на эту страничку.
И тут уже, даже если разработчик с вами не согласен, он может прийти и сказать — «Смотри, ты дал ссылку на сайт, да это же желтая пресса какая-то, там всегда пишут фигню». Но если вы не дали ссылку, разработчику придется самому гуглить, самому искать всякие сайты и только тогда он поймет, что, возможно, вы напали на какие-то ложные сведения. Сэкономьте ему время, дайте сразу ссылку в интернет.
Да, здесь нужно понимать, что не каждая ссылка полезна и оправдана, но она как минимум покажет, почему вы считаете, что это действительно баг. Это вам уже не «мамой клянусь», а с обоснованием!
Письмо заказчика
Обоснованием может быть отсылка на письмо заказчика. У нас в джире есть даже отдельное поле, «Бизнес-обоснование», куда мы записываем, какой заказчик просил эту фичу. И тогда, когда мы читаем наш баг, то мы сразу же видим:
— Ага, бизнес-обоснование пустое. Это значит, что мы сами нашли эту проблему и считаем, что ее нужно поправить.
Либо:
— Ага, вот такой то заказчик на проблему жаловался 1 августа 2015 года
И если нам надо уточнить у этого Заказчика, что именно его не устраивает, то мы легко можем найти это письмо, ведь у нас есть вся информация (кто, когда, как называется письмо). Зная эту инфу, я пойду и найду письмо за 5 сек в своем аутлуке. Если этой инфы нет, то мне придется пойти в аутлук и искать среди 10 разных папочек — какой заказчик это просил и в каком письме?
К тому же, если мы видим, что эту фичу просили несколько разных заказчиков, то у нее сразу повышается приоритет. Так как мы понимаем:
— Ага, вот заказчик 1 жаловался тогда-то, через пару недель / месяцев жаловался заказчик другой. Хмммм, но ведь наверняка есть куча других заказчиков, которые тоже страдают, но молчат. Плачут, колются, но продолжают жрать кактус. Ведь не все будут писать нам и сообщать о проблеме…
Так что чем больше жалоб, тем выше приоритет. Так как мы понимаем, что это реальный пользователь пожаловался, у них действительно есть такие проблемы. И даже если мы вернемся к багу спустя полгода или год, благодаря вложенному письму или хотя бы ссылке на него всегда можно будет поднять историю задачи.
ROI
Мы можем попробовать подсчитать ROI — коэффициент окупаемости. Действительно ли нам нужно сделать эту фичу или исправить этот баг? Принесет ли это должный эффект?
Одно дело — внести мелкую правку на полчаса разработки, которая поможет сотням пользователей. Совершенно другое — из-за истерики одного пользователя две недели переделывать работу системы, которая всех остальных устраивает.
Если мы подсчитали ROI и видим, что овчинка стоит выделки — вкладываем расчеты в задачу. Но иногда после подсчетов выясняется, что делать задачу не нужно. И это — нормально! Значит, мы сэкономили время команды на обсуждение ненужной фичи.
Именно для этого мы и продумываем обоснование — потому что иногда кажется «Ах, какой баг, какой баг!», а потом начинаешь думать над обоснованием… И понимаешь, что фигня это, а не баг, даже заводить не стоит...
Например, мы приходим на работу с мобильным приложением, а там есть дебаг-панель для тестировщиков, которая выглядит примерно так:
Воу-воу! Тут синенькое, там красненькое, текст не виден полностью, шрифты идут вразброс... Явный баг! Как это до меня не заметили? Срочно оформляю, нужен рефакторинг!
Как обосновать? «Да вы что, если если пользователь ТАКОЕ увидит, то он сразу обидится и уйдет.» Стоп. Включаем мозг. Это дебаг-панель. Она для тестировщиков и разработчиков, помощник в тестировании. Пользователь ее НИКОГДА не увидит. А если увидит, то ВОТ ЭТО уже будет баг, причем критичный!
См также:
Debug-панель в тестировании мобильных приложений — о том, что это такое вообще
А наведение красоты... Да кому она нужна, красота эта? Новый функционал туда добавляется срочно и быстро. Тестировщик приходит, жалуется на проблему, разработчик на коленке пишет код. Работает? Не трогай!
Ничего не случится с чувством прекрасного у тестировщика, пусть в других местах такие баги ищет. Потому что на рефакторинг этой панели может уйти неделя разработки. А это очень дорого. И ради чего? Ради красоты? Да ну ее нафиг, лучше сделать функционал, за который клиент заплатит.
Так что подсчитали трудозатраты и поняли — нам и так хорошо живется, ничего менять не стоит!
Статистика
Соберите статистику и вложите в задачу:
— количество ошибок в логах;
— количество жалоб в техподдержку;
— количество кликов на кнопку;
— количество пользователей, которые ушли на этапе оформления заказа (закрыли вкладку);
— …
То есть если вы считаете, что типовая форма оформления заказа в интернет-магазине «плохая» и ее надо улучшить — обоснуйте. Чем именно она плоха? Тем, что для ввода адреса надо знать свой индекс и заполнять 10 обязательных полей? А правда ли это плохо или раздражает только вас?
Учтите, что разработчики могут не видеть «очевидного» в своем ПО. Они ведь его разрабатывали, тестировали... Видят постоянно по 100 раз в день, уже привыкли к интерфейсу. Так что даже если он и правда устарел, нужны факты.
А собираются факты легко — просим сделать статистику, чтобы посмотреть, когда пользователь уходит со страницы. И если он добавил пиццу в корзину, а потом начал заполнять поля и после 5-7 плюнул и ушел, это не очень круто. А если так каждый третий поступает — точно стоит что-то улучшать!
Если вспомнить про емейл .рф, то можно посмотреть по логам — а есть ли вообще ошибки вида «Попытка зарегистрироваться на такой емейл отклонена»? Может, их вовсе нету, а мы тут уже кучу обиженных пользователей придумали, из-за которых сайт буквально миллионы потерял.Почему статистика лучше эмоций? Да потому что мы, ИТ-специалисты, и простые пользователи — два разных мира. То, что удобно нам, неудобно им. И наоборот.
Допустим, делаем мы бухгалтерское ПО. Нам кажется: «фу, мышкой никто не работает, надо сделать так, чтобы все работало из командной строки, чтобы мышку вообще не надо было трогать!». Мы тратим на этот функционал кучу времени, а реальные пользователи его вообще не используют. Потому что им нужна мышка, чтобы взять, тыкнуть на большую кнопку... А то что удобно программистам, им вообще до лампочки, так как им удобно совершенно другое.
И если вы хотите рассказывать всем, что нужно пользователям, сначала изучите usability-тестирование, а потом говорите, обидятся зайчики, или нет.
В своей системе мы собираем анонимную статистику, какой функционал используется, а какой нет. На веб-форме есть очень много фильтров, которые тяжело поддерживать. А нужны ли они? Нельзя просто взять и убрать, стоит проверить.
Так вот статистика обычно очень удивляет. Мы думали, этот фильтр не используют вовсе, а на самом деле каждый час отрабатывает. А на другой возлагали большие надежды, а он никому и не нужен...
Только статистика честно расскажет о существовании проблемы. Если статистики нет, это будет всего лишь вкусовщина. А вкусы у всех разные. Тестировщику хочется кнопку красную, разработчику — зеленую, а дизайнеру — синюю. Так что ищите факты и давайте на них пруфлинк!
Другие хорошие варианты, кроме пруфлинка:
См также:
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Комментариев нет:
Отправить комментарий