Если вы нашли ошибку в мобильном приложении, Вам необходимо сообщить об этом для того, чтобы ее исправить. Подачи мобильных bug reportов требуют некоторой дополнительной информации для разработчиков, чтобы они могли воспроизвести и исправить ошибку.
Но что важно, при оформлении mobile бага? Как должен выглядеть баг отчет?
Прежде чем ответить на эти два вопроса, я хочу поднять еще один: “ Зачем отправлять отчет об ошибке?”
Отчеты об ошибках очень важны для владельца продукта, продукт-менеджера и разработчиков. Во-первых, отчет об ошибках рассказывает разработчикам и владельцам продукта о проблемах. Они также помогают определить возможные новые сложности, и, наконец, последнее, но не наименее важное, они обеспечивают полезную информацию о том, как клиент может использовать данный продукт. Вся эта информация может быть использована для улучшения вашего программного обеспечения.
Всякий раз, когда вы находите что-то странное, если что-то ведет себя по-разному или выглядит странно, не стесняйтесь оформляйте bug report.
Давайте подойдем к вопросу, как должен выглядит баг репорт и что важно при его оформлении.
Отчет об ошибке должен содержать как можно больше информации о том, как именно она была выявлена, как можно воспроизвести и исправить ошибку. Ваш отчет должен включать только информацию, которая важна для обработки ошибки, поэтому постарайтесь избегать добавления каких-либо бесполезной информации. Еще один важный момент заключается в том, что вы должны описать только одну ошибку за ошибкой. Не создавайте контейнеры для ошибок. Вполне вероятно, что не все ошибки, которые будут исправлены в одно и то же время, поэтому воздержитесь от объединения или группировки.
Следующая информация должна быть включена в отчет об ошибке:
БАГ ID
Баг должен иметь уникальный идентификатор, как число или комбинацию символов или цифр.
ОПИСАНИЕ
Создайте краткое, но содержательное Описание: краткий обзор, что пошло не так, не вдаваясь в детали. Вы можете добавить, например, коды ошибок или указать на часть приложения, где произошла ошибка.
Плохо: “сбой в приложении”, “Белая страница”, “увидел ошибку”, “ошибка”
Хорошо: “код ошибки 542.”, “Тайм-аут, при отправлении поискового запроса.”
ШАГИ ВОСПРОИЗВЕДЕНИЯ
Это один из самых важных моментов. Предоставить точные шаги, вместе с исходными данными о том, как воспроизвести ошибку. Если вы в состоянии предоставить такую информацию, ошибку будет очень легко исправить в большинстве случаев.
Плохо: “я пытался выполнить поиск.”
Хорошо: “Запустите приложение и введите ‘Mobile Testing’ в поле ввода поиск. Нажмите на кнопку поиска, и вы увидите код ошибки 783 на странице результатов поиска”
ОЖИДАЕМЫЙ РЕЗУЛЬТАТ
В этом разделе Вы должны описать, ваш ожидаемый резуьтат, когда произошла ошибка.
Плохо: “она должна работать.”
Хорошо: “я ожидал увидеть результаты поиска с прокручиваемым списком из 20 записей.”
АКТУАЛЬНЫЙ РЕЗУЛЬТАТ
Что случилось, когда произошла ошибка? Запишите фактический результат, что пошло не так.
Плохо: “это просто не работает.”
Хорошо: “страницы результатов поиска были пустыми.” или “я получил код ошибки 567 на странице результатов поиска.”
ОБХОДНОЙ ПУТЬ
Если вы нашли способ продолжить работу с приложением, избегая ошибки, объясните свои действия. Это шаги, которые важно знать, поскольку временное решение может привести к другим проблемам или указывают на способ, в котором приложение не должно использоваться. С другой стороны, решение может быть очень полезным для группы поддержки, чтобы помочь клиентам решить проблему до тех пор, пока ошибка будет исправлена.
Плохо: “я нашел обходной путь.”
Хорошо: “если вы положите устройство в горизонтальном режиме, нажмете на кнопку " Поиск ", и пользователь может искать снова.”
ПОВТОРНОЕ ВОСПРОИЗВЕДЕНИЕ
Если вы обнаружили повторяющуюся ошибку, это нормально. Если это происходит каждый раз, это здорово, как это легко исправить разработчику. Но если ошибка возникает только в 20 процентов времени, гораздо труднее найти решение. Убедитесь, что вы предоставили эту информацию, так как это очень полезно для разработчиков и предотвратит закрытие ошибки с комментарием “не может быть воспроизведен”.
Плохо: “Иногда”
Хорошо: “ошибка возникает в 2 случаях из 10.”
ОПЕРАЦИОННЫЕ УСТРОЙСТВА, МОБИЛЬНЫЕ ПЛАТФОРМЫ И ВИД ДЕВАЙСА
Запишите вид операционной системы, мобильной платформы и устройство, на котором произошла ошибка.
Плохо: “на Android” или “iOS”
Хорошо: "Android версии 4.1.2 Google Nexus 4" или "для iOS, Версия 6.1 iPhone 4S"
КОНКРЕТНАЯ ИНФОРМАЦИЯ ПО МОБИЛЬНОМУ УСТРОЙСТВУ
Мобильные устройства имеют множество интерфейсов и датчиков, которые могут повлиять на ваше приложение. Батареи также могут повлиять на приложение, которое вы тестируете. Запишите всю эту информацию в свой отчет об ошибке.
Плохо: “нет информации”
Хорошо: “GPS датчик активирован, поменял ориентацию с вертикальной на горизонтальную.” или “использовал устройство в солнечном месте.” или “состояние батареи 15%.” или “состояние батареи было 100%.”
ВЕРСИЯ БРАУЗЕРА
Если ваше приложение-это мобильное веб-приложение, и вы нашли проблему, очень важно отметить, версию браузера, где ты нашел баг, как это может происходить только в определенной версии браузера.
Плохо: “Google Chrome” или “Mozilla Firefox”
Хорошо: "Google Chrome Версия 45.35626" или "Mozilla Firefox 27.6"
ВЕРСИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Еще один очень полезный кусок информации версия приложения, где произошла ошибка. Может быть, вы нашли проблему в версии 1.2, но там уже имеется более новая версия, в которой ошибка была Исправлена. Это предотвратит разработчика от необходимости тратить время, пытаясь воспроизвести баг, который уже исправлен.
Плохо: “нет информации”
Хорошо: "IOS 1.2.3"
СОСТОЯНИЕ СЕТИ
При оформлении ошибки, важно предоставить некоторую информацию о состоянии сети, в которой произошла ошибка. Это поможет определить проблему более легко и, вероятно, покажет некоторые побочные эффекты о которых никто не подумал.
Плохо: “нет информации” или “случилось по дороге на работу”
Хорошо: “я был подключен к сети 3G пока я гулял по центру города.”
ЯЗЫК
Если ваше приложение поддерживает несколько языков, предоставьте эту информацию в свой отчет об ошибке.
Плохо: “нет информации”
Хорошо: “я использовал немецкий язык.”
ТЕСТОВЫЕ ДАННЫЕ
Эта информация может быть предоставлена в шагах, предпринятых для воспроизведения ошибки, но данные, необходимые для воспроизведения ошибки могут быть более сложным, поэтому имеет смысл предоставить эту информацию в отдельном разделе. Предоставить SQL скрипты или точные данные, введенные в поля ввода.
Плохо: “нет информации”
Хорошо: “найдите вложенный SQL скрипт для переключения базы данных в определенное состояние.” или “Enter " мобильное тестирование " в поле ввода поиск.”
УРОВЕНЬ КРИТИЧНОСТИ
Каждый баг должен иметь уровень критичности. Вы можете составить список уровней с вашей командой. Важно определить уровень важности бага, поскольку он позволит команде приоритизировать их, так как критические и приоритетные баги будут исправляться в первую очередь. Если эта информация не предоставлена, это будет занимать гораздо больше времени. По умолчанию уровни критичности: критический, высокий, средний и низкий.
Плохо: “нет информации”
Хорошо: “критический” или “средний”
КАТЕГОРИЯ БАГА
Кроме того, категория ошибки-это тоже очень полезная информация. Например, если есть много UX ошибок, это может быть показателем плохого UI и UX и, это означает, что приложение нуждается в более конструктивных улучшениях.
Плохо: “нет информации”
Хорошо: “функциональность” или “UX” или “Производительность”
СКРИНШОТ ИЛИ ВИДЕО
Всякий раз, когда вы обнаружите ошибку, попробуйте создать скриншоты или видео, чтобы предоставить разработчику более подробную информацию. Видео-это отличный способ, чтобы описать как именно вы нашли баг.
Плохо: “нет скриншоты или видео прилагается.” или “Screenshot1.png”
Хорошо: “01_InsertSearchTerm.png, 02_SearchResultPageWithError.png”
URL
Если вы тестируете мобильное веб-приложение, важно отметить, точный адрес, где происходит ошибка. Без этой информации разработчику сложно найти где именно произошла проблема.
Плохо: “нет " URL”
Хорошо: "http://www.testurl.com/start.php?post=11212"
LOG ФАЙЛЫ
Если приложение зависает и вылетает, подключите устройство к компьютеру и посмотрите лог-файлы. В большинстве случаев в stack trace будет показано описание ошибки. Такая информация чрезвычайно полезна для разработчиков, так как они знают, сразу в каком классе ошибка.
Плохо: “сведения не предоставлены”
Хорошо: “предоставить полный стек trace в bug reportе.” или “прикрепленный файл журнала отчета.”
ТЕСТИРОВЩИК, КОТОРЫЙ НАШЕЛ БАГ
Запишите ваше имя или имя тестера, который обнаружил ошибку. У разработчика или владельца продуктов могут возникнуть вопросы по поводу сообщений об ошибке и они, конечно, могут хотеть напрямую связаться с тестером, который нашел проблему. В большинстве случаев это происходит автоматически. Если нет, убедитесь, что вы добавить свой e-mail адрес.
Плохо: “нет информации”
Как вы видели, есть много информации, которая должна быть включена в отчет об ошибке. Существует три других пункта, которые вы должны иметь в виду, когда пишете отчет об ошибке.
При подаче отчета об ошибке, не используйте оскорбительные или эмоционально напряженные слов, как такие ошибки будут игнорироваться разработчиком и в конечном итоге приведут к плохим отношениям внутри команды.
Второй-это не ваша вина, что произошла ошибка. Это программное обеспечение, сломалось и вы и ваши коллеги должны это исправить.
И третий момент-сделайте его простым. Попробуйте написать ваш отчет об ошибке таким образом, что кто-то, не имея представления о проекте или приложении был в состоянии понять проблему. Если отчет об ошибке, написан легко, каждый Разработчик в команде сможет его исправить и другие коллеги, также смогут понять проблему и оценят вашу работу.
Комментариев нет:
Отправить комментарий