Http bug report url report php
How to Report a Bug
There is a large number of PHP users. There is a much smaller number of people who actually develop the PHP language and extensions. There is an even smaller number of people who actively fix bugs reported by users.
What does this mean for you, an aspiring bug reporter? In order to catch the eye of one of these few stalwart volunteers, you’ll need to take to heart a few tips on how to report a bug so that they can and will help you.
Take special note of that word in bold above. The people who are going to help you with a bug you report are volunteers. Not only are you not paying them to help you, but nobody else is either. So, to paraphrase the immortal words of Bill and Ted, «be excellent to them».
Beyond that golden rule, what follows are some additional tips on ways to make your bug report better so that someone will be able to help you.
The basics: what you did, what you wanted to happen, and what actually happened.
Yes, the example is silly. But if your bug report simply said «The make_happy_meal function doesn’t work,» we wouldn’t be able to say «That’s because you can’t have onion rings in a happy meal, you can only have french fries or curly fries.» By telling us what you asked for, what you expected to get, and what you actually got, we don’t have to guess.
Always search the bug database first.
Advice is so good, we’ll repeat it twice. Always search the bug database first. As we said above, there’s a lot of users of PHP. The odds are good that if you’ve found a problem, someone else has found it, too. If you spend a few minutes of your time making sure that you’re not filing a duplicate bug, that’s a few more minutes someone can spend helping to fix that bug rather than sorting out duplicate bug reports.
If you don’t understand an error message, ask for help.
Don’t report an error message you don’t understand as a bug. There are a lot of places you can ask for help in understanding what is going on before you can claim that an error message you do not understand is a bug.
(Now, once you’ve understood the error message, and have a good suggestion for a way to make the error message more clear, you might consider reporting it as a feature request.)
Be brief, but don’t leave any important details out.
This is a fine line to walk. But there are some general guidelines:
Use English.
Yes, the PHP user and developer communities are global and include a great many people who can speak a great many languages. But if you were to report a bug in a language other than English, many (if not most) of the people who would otherwise help you won’t be able to. If you’re worried about your English skills making it difficult to describe the bug, you might try asking for help on one of the non-English mailing lists.
Don’t report bugs about old versions.
Every time a new version of PHP is released, dozens of bugs are fixed. If you’re using a version of PHP that is more than two revisions older than the latest version, you should upgrade to the latest version to make sure the bug you are experiencing still exists.
Note that PHP branches which are no longer actively supported will receive fixes for critical security issues only. So please do not report non-security related bugs which do not affect any actively supported PHP branch.
Only report one problem in each bug report.
If you have encountered two bugs that don’t appear to be related, create a new bug report for each one. This makes it easier for different people to help with the different bugs.
Http bug report url report php
Что пишут в блогах
В этом видео я показал как можно визуализировать покрытие автоматическими тестами для GraphQL api с помощью инструмента Reqover.
Cегодня хочу поговорить с вами на тему комьюнити для тестировщиков.
Как и в любой сфере, среди тестировщиков существует куча различных комьюнити. Раньше они организовывались в скайпе.
Забываю похвастаться статусом книги.
Классной вам команды, четких и логичных требований, огненных разработчиков, адекватных менеджеров и проектов с крутой архитектурой!
Уважаемые коллеги, сильные мидлы, уверенные автоматизаторы, вдохновленные стажеры и специалисты фуллстек!
Онлайн-тренинги
Конференции
Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Алексей Потемкин, QA engineer компании «JetRuby Agency»
Так уж случилось, что у нас накопилась масса материала, посвященного теме создания идеального отчета об ошибках (bug report). Обобщив эту информацию и вооружившись практическим опытом, мы решили написать статью. Перед вами подробный текст о стандарте написания баг репортов.
Каналы поступления багов
Начнем с каналов поступления багов. Мы можем столкнуться с проблемами и получить информацию об их появлении следующим образом:
Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.
Направления работы отдела QA
С каналами поступления информации о багах мы определились. Теперь перейдем к направлениям работы QA инженеров. Их несколько:
В зависимости от направления работы состав информации, подаваемой в баг репорт, будет изменяться. Однако окончательная цель QA специалиста останется неизменной. Речь, разумеется, идет об устранении бага.
Вот здесь начинается самое интересное. Чем полнее и точнее подана информация, тем проще QA инженеру или менеджеру проекта определить приоритет проблемы, а разработчику — ее устранить. Все просто, у команды общие цели — стабильный проект, довольный заказчик и счастливые пользователи программного обеспечения, отсутствие переработок.
Написание bug report — один из кирпичиков, которые закладываются в фундамент достижения этих целей. Он должен быть ровным и красивым. В противном случае мы сталкиваемся с проблемами: разработчикам приходится тратить время на воспроизведение бага, вместо того чтобы писать код.
Написание bug report: как это происходит
В идеальном мире QA специалист добавляет баг в трекинговую систему только в том случае, если он может воспроизвести проблему. Сообщения же о дефектах, которые приходят от заказчика и пользователей, не всегда содержат максимум полезной информации. В таких случаях QA специалист должен либо самостоятельно определить проблему, либо связаться с лицами, заявившими о ее наличии и собрать все недостающие сведения.
Прежде чем создавать баг-репорт, убедитесь, что такого же дефекта нет в системе отслеживания ошибок. Если он уже зафиксирован, при необходимости дополните описание актуальной информацией.
Чего делать нельзя? Нельзя информировать сразу о нескольких проблемах в пределах одного баг репорта. Закон джунглей: один bug report = одна проблема. Не ленитесь.
Чем плох баг репорт с несколькими проблемами в пределах одной задачи? Это значительно замедляет процесс их устранения. Следите за руками: после починки дефекта разработчик переназначает задачу на QA специалиста для проверки. Если мы имеем несколько проблем в одной задаче – разработчик не сможет отдать их на проверку, пока не устранит каждую из них. Чувствуете как утекает время? Когда же все баги упакованы в отдельную задачу, QA специалист может приступить к проверке исправлений значительно раньше. Таким образом, жизненный цикл бага (переоткрытие, закрытие) проходит быстрее, и программное обеспечение быстрее продвигается к релизу.
Нельзя заводить, как баг, то, что не имеет отношения к спецификации проекта. Не нужно отнимать у разработчиков время на работу, которая не согласована.
По аналогии поступаем и с code-review. Весьма полезно иногда показывать коллегам свежесозданный отчет об ошибке. Возможно они подскажут, что следует добавить и/или исключить из описания проблемы.
К слову, баг репорт состоит не только из описания. Любое сообщение о дефекте включает в себя два элемента:
Рассмотрим каждый из них в отдельности.
Заголовок
При составлении заголовка мы используем золотое правило: “Что? Где? При каких условиях?”. Заголовок — это первое, что увидят разработчики, менеджер проекта или ваши коллеги — QA специалисты. Сделав его максимально простым, точным и понятным, вы сразу же зададите верное направление. Итак, заголовок отчета об ошибке должен:
Давайте рассмотрим работу с заголовком на простом примере:
Небольшой комментарий к информации об окружении и проектных традициях. Приведем простой пример. Мы имеем дело с проектом, в пределах которого разрабатывается мобильное приложение под две платформы: iOS и Android. В зависимости от того, к какой платформе привязан баг, в заголовке указываем: iOS или Android. Например, “iOS. Application accepts dates of birth from the future.”.
Дополнительный вариант — использование так называемых ярлыков (labels). Некоторые системы отслеживания ошибок предоставляют соответствующий функционал.
Описание
Переходим ко второму компоненту bug report. Описание должно содержать следующую информацию:
При работе с Pivotal Tracker мы привыкли маркировать уровни проблемы цифровым значением от 1 до 4, это значение указывается в качестве label. По уровням градация следующая: 1 — это Blocker и Critical, 2 — это Major, 3 — это Minor и 4 — это Trivial. Такая градация уровня проблемы используется на всех проектах, которые ведутся в Pivotal Tracker.
А теперь рассмотрим каждый из компонентов описания баг репорта в отдельности.
Примеры
Пример #1
Один из баг репортов для мобильного приложения. Проект ведется в Pivotal Tracker. Уровню проблемы присваивается значение в диапазоне от 1 до 4, где наиболее важные моменты — это “1” и далее по убыванию. Приложение разрабатывалось сразу под две платформы — Android и iOS. Поэтому мы решили прописывать платформу в заголовок задачи.
Переходим к составляющим баг репорта:
Заголовок — Android. About Track screen. Nothing happens after tap on the Label. Как было сказано выше, мы указываем платформу, тем самым отвечая на вопрос “где?”. То есть: на платформе Android, на экране About Track. Далее мы отвечаем на вопросы “что?” и “когда?” — Nothing happens after tap on the Label.
Так как отдельных полей о тестовом окружении в Pivotal Tracker не предусмотрено, мы добавляем информацию о билде (Build v2.0.6) и версии Android, на которой был воспроизведен баг (Android 6.0), в поле Description.
В этом же поле прописываем шаги воспроизведения бага:
И ожидаемый результат: Expected behaviour: Label screen should be opened.
Кроме того, к задаче были прикреплены скриншоты экрана About Track с явным указанием проблемной надписи. При нажатии на нее ожидался переход на другой экран.
Пример #2
Следующий пример — баг репорт из проекта, связанного с реализацией REST API для мобильных приложений. Проблема состояла в том, что в ответе не возвращалась необходимая информация (атрибуты).
Кликните на изображение для увеличения
Проект также велся в Pivotal Tracker, поэтому уровень проблемы был указан с помощью label. Использовалась аналогичная шкала (от 1 до 4). Мы присвоили проблеме уровень “2”, так как отсутствие данной в ответе метода не позволяло выполнить некоторые операции в профиле пользователя.
Итак, заголовок — The method «View User Profile» should return information about user’s location. Мы совершенно отчетливо указываем на метод и проблему. Далее в поле Description мы даем понять, что речь идет о стейджинге.
Указываем реквизиты пользователя, которые могут понадобиться для воспроизведения проблемы. В нашем случае это: email, пароль и токен.
Описываем проблему и добавляем техническую информацию: пример вызова метода при помощи curl и текущий ответ.
Наконец, указываем что мы ожидали увидеть в ответе недостающие атрибуты.
Выводы
Как видите, сведения об окружении и технические детали могут меняться в зависимости от направления проекта. В остальном состав подаваемой информации в отчетах об ошибках идентичен.
Что еще важно отметить? На сегодняшний день существует масса систем для автоматического сбора информации об ошибках. Например, Errbit для веб или Crashlitics для мобильных приложений. Они могут быть интегрированы с вашей системой отслеживания ошибок и передавать все технические подробности проблемы. Однако автоматически созданные задачи должны тщательно исследоваться тестировщиком для определения и добавления шагов воспроизведения проблемы. Лишь после этого задача передается разработчикам.
Использование общих шаблонов и практик дизайна отчетов об ошибках в пределах компании позволяет существенно сократить время коммуникации между разработчиками и QA специалистами. Дело в том, что согласование задач (то есть случаи, когда разработчики возвращают тестировщикам задачи со статусами rejected, can’t reproduce, more info) зачастую существенно затягивается. Соблюдение же правил написания bug reports позволяет решить эту проблему. В результате мы экономим кучу драгоценного времени. Даже не сомневайтесь, что заказчики и пользователи ПО оценят это положительно.
Баг репорт (bug report): оформление и пример
Баг репорт (bug report) – это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Bug report c определением в самом общем случае – это несоответствие требованиям или функциональным спецификациям (или здравому смыслу). То есть это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
В данной статье мы рассмотрим основные моменты, связанные с созданием баг репорта, а также в конце предоставим баг репорт пример с возможностью скачивания.
Содержание
Определения понятия баг
Для лучшего понимания, того что такое баг репорт, нужно тать и определение понятию что такое баг. Следует отметить, что однозначного и исчерпывающего определения Bug не имеет, поэтому перечислим наиболее распространенные.
Мы будем использовать простое определение:
Дефект (баг, глюк, ошибка; defect, bug) – это несоответствие требованиям или функциональным спецификациям.
Также следует помнить, что к багам относится любое некорректное поведение программы, не соответствующее оправданным ожиданиям пользователя, даже в том случае, если это поведение не документировано в требованиях и спецификациях.
Баги могут встречаться в любой документации, в архитектуре и дизайне, в коде программы и т.д.
Иногда баг на самом деле является не ошибкой в программе, а результатом неверного конфигурирования программы и/или окружения.
Управление инцидентами перед оформлением баг репорта
Инцидент (incident) — это любое событие, требующее исследования.
Любое существенное, незапланированное событие, которое происходит во время тестирования, что требует дальнейшего исследования и / или коррекции:
Если есть расхождения между фактическими и ожидаемыми результатами, то прежде чем делать send bug report (отправь баг репорт), баг должны быть зарегистрированы как инциденты.
Инцидент (Test Incident) – любое событие, наблюдение, найденное в рамках тестирования, требующее исследования. Инцидент может возникнуть:
Виды инцидентов
Есть практика выделять два вида тестовых инцидентов: дефект и запрос на улучшение. Если давать определения этим понятиям, то можно назвать следующее
Документирование инцидента
Как мы отмечали выше, прежде чем отправь баг репорт, найденные во время тестирования инциденты должны быть специальным образом задокументированы. Это может быть:
Для управления и контроля над тестовыми инцидентами и баг репортами используются специализированные программы о них и поговорим ниже.
Инструмент управления дефектами и инцидентами
Оформление баг репорта или отчета об инциденте удобно делать если есть специальный инструмент управления дефектами (Defect Management Tool, Bug or Issue Tracker Tool) – инструмент, обеспечивающий фиксирование дефектов и изменений, а также поддержку их состояний. Часто имеет процессно-ориентированные возможности для поддержки и контроля распределения, исправления и повторной проверки дефектов, а также возможности отчетности. Помимо стандартной функциональности, хороший инструмент управления дефектами должен иметь возможности:
В свою очередь хороший отчет о дефекте (баг репорт) должен обладать рядом свойств и характеристик, о которых давайте поговорим ниже.
Оформление баг репорта: основные принципы
Определения для понятия bug report мы навали выше, поэтому начнем с характеристик, которыми должен обладать отличный баг репорт. Качественное оформление баг репорта должно отвечать на следующие вопросы:
Инженер по тестированию должен уделять большое внимание качеству создаваемых отчетов о дефектах. Чем лучше он описан тем менее вероятна ситуация отклонения дефекта или неверной трактовки дефекта другими участниками проекта.
Цель баг репорта
Целью составления отчета о дефекте является ее исправление, поэтому не имеет смысла создавать отчеты ради отчетов. Чем больше хорошо задокументированных отчетов поступает от команды тестирования, тем больше доверия к тестированию. Целью отчёта об ошибке (bug-report) является:
Отчёт об ошибке – один из основных результатов работы тестировщиков. И, к слову, именно этот результат работы видят коллеги (другие тестировщики и люди, не входящие в команду тестировщиков), при этом заказчики видят работающий продукт.
И если подводить черту под смыслом написания баг репорта, то основная цель написания отчёта об ошибке – устранение ошибки.
Поэтому стоит помнить, что хороший тестировщик – не тот, кто написал за день 1000 бесполезных и бессмысленных отчётов, а тот, по чьим отчётам (вне зависимости от их количества) было исправлено большое количество ошибок.
Баг репорт: пример полей для заполнения (атрибуты)
Ниже предоставлен список основных полей отчета о дефекте. Будем перечислять возможные атрибуты, а также останавливаться и объяснять наиболее важные. Звездочками помечены обязательные поля для заполнения.
Название проекта * (Project) – официальное название проекта
Здесь, в принципе, все понятно и каких-либо дополнительных объяснений не нужно.
Уникальный номер отчета * (ID) – идентификатор отчета о дефекте
У каждого отчёта об ошибке должен быть уникальный идентификатор. Как правило, системы управления ошибками (bug tracking systems) позволяют формировать идентификатор в виде некоторого шаблона, например аббревиатура проекта + дата + порядковый номер
Либо, каким-нибудь другим видом, при этом ID, будет позволять идентифицировать баг.
Дата создания * (Created Date) – дата создания отчета
Опять-таки, здесь все предельно понятно.
Дата обновления (Update Date) – дата обновления (изменение, закрытие)
Данный атрибут не всегда является обязательным, и в дополнительном толковании не нуждается.
Краткое описание * (Summary, Title, Subject, Synopsis) – заголовок отчета
Важный атрибут любого баг репорта. Нужно емко и по существу передать информацию о проблеме. Характеристика хорошего заголовка – прочитав только заголовок понятен смысл ошибки. Хорошее краткое описание, как и баг репорт вцелом, должно давать ответы на три вопроса:
Например:
Краткое описание иногда предваряется префиксом, указывающим область работы с приложением, для которой актуален баг, например:
Примечание:
Текущий статус * (Status) – состояние инцидента
Набор статусов зависит от выбранного процесса разработки. Базовые статусы:
О правилах переходов из состояния в состояние будет сказано в статье про жизненный цикл бага.
Резолюция (Resolution) – пояснение к статусу
К примеру, дефект может быть закрыт, но причины закрытия могут быть разными: сделан, дубликат, отклонен. Набор резолюций зависит от выбранного процесса разработки. Базовый набор возможных резолюций:
Подробнее о резолюциях будет сказано в отдельной статье.
Приоритет (Priority) – свойство, указывающее на очередность выполнения задачи или устранения дефекта
Также является важным атрибутом bug report, чем выше приоритет сущности, тем быстрее нужно приступить к ее реализации. Набор приоритетов завит от выбранного процесса разработки и зачастую, данную информацию отражает тест план. Базовый набор приоритетов:
Приоритет может выставляться инженером по тестированию, но, как правило, приоритет редактируется менеджером проекта.
Строгость (Severity) – техническая оценка инцидента
Набор степеней строгости дефектов завит от выбранного процесса разработки и договоренностей между участниками проекта. Базовый набор:
Тип инцидента (Incident Type) *
Принято выделять два вида тестовых инцидентов:
Категория инцидента (Category)
Данное свойство отображает, к какой характеристике проекта относится инцидент. Базовый набор категорий:
Компонент (ы) (Component)
Здесь отображается область объекта тестирования, к которой относится инцидент.
Версия приложения, для которой инцидент актуален (Affects Version)
Версия приложения, в которой инцидент найден. И версии, на которых инцидент воспроизводится. Важно понимать, что если мы находим дефект на поздних версиях приложения, то, возможно, он воспроизводится и на более ранних версиях. Для десктоп приложений важно знать все версии, где дефект воспроизводится. Иногда детальное отображение всех версий, где воспроизводится дефект, требуется для сбора метрик. На большинстве веб-проектов достаточно указывать только версию, в которой нашли инцидент.
(Fix Version)
Версия приложения, в которой инцидент был закрыт.
Создатель отчета * (Reporter)
Этот атрибут хранит в себе имя создателя отчета. Создателем отчета не обязательно должен быть специалистом по тестированию, им может быть любой участник проекта или даже пользователи.
На кого назначен отчет (Assignee)
Здесь отражается имя сотрудника, назначенного на решение задачи.
Метки (Labels)
Метки используются для систематизации информации. В дальнейшем метки служат для сбора метрик, поиска дефектов и т.п.
Окружение (Environment)
Окружение, на котором найден дефект – операционная система, браузер, версия браузера, сервер и т.п. Если дефект воспроизводится на всех окружениях, то ставится соответствующий комментарий.
Описание * (Description)
Также чрезвычайно важный атрибут. Описание должно быть лаконичным и ясным, как и Summary, но в более развернутой форме. Если есть альтернативные шаги, то их также нужно указать. В описание можно оставлять любые полезные примечания – повторяемость, уточнения и т.п. Пример Description в баг репорте:
Если администратор заходит на страницу приветствия, то логотип пропадает.
Actual result: логотипа нет. (Реальный результат)
Expected result: логотип в правом верхнем углу. (Ожидаемый результат)
Requirement ID: #45 (пункт требований)
Reproduced on: Win10, IE11, 1200x800dpi (на чем воспроизводиться)
Workaround: Да, логотип отображается, если обновить страницу повторно
For more details, please, see attached files:
Как видно из примера Описание (Description) имеет набор атрибутов, которые входят в его состав, давайте некоторые поясним
Приложения (Attachments)
Любая информация, которая поможет воспроизвести ситуацию:
Воспроизводимость (reproducible, reproducibility)
Это поле показывает, воспроизводится ли баг всегда («always») или лишь иногда («sometimes»). Баги, воспроизводящиеся всегда, гораздо проще диагностировать.
Примечание:
Рекомендация: пройдитесь по своим шагам воспроизведения хотя бы 2-3 раза прежде, чем писать, что баг воспроизводится всегда.
Помните, что это задача тестировщика – доказать, что баг есть. Поэтому сразу же, как увидели баг, делайте скриншот. Даже если вам самому больше не удастся воспроизвести баг, возможно, программист по скриншоту поймёт, в чём дело.
Возможность «обойти баг» (workaround)
Это поле косвенно влияет на важность и срочность устранения ошибка. Если некое действие можно выполнить в обход сценария, приводящего к ошибке, поле принимает значение «да» («yes»), в противном случае – поле принимает значение «нет» («no»).
Шаги воспроизведения (steps to reproduce, STR)
Данная информация в отчёте об ошибке является крайне важной. Именно она позволяет разработчику быстро воспроизвести и устранить проблему. Это поле следует заполнять максимально подробно, т.к. будучи незнакомым с внутренней структурой приложения, тестировщик не может знать, какие из выполненных им действий наиболее существенны для диагностирования данной ошибки (steps в тест кейсе, в какой-то степени, похожи STR).
Несколько рекомендаций:
Пример:
Дополнительная информация (additional info)
В это поле можно писать всё то, что вы считаете необходимым отметить, но что не подходит для размещения в других полях.
Требования, тест-кейсы, среда нахождения ошибки, билд, рассуждения, комментарии, мысли, анализ возможных причин появления бага и путей его устранения – всё это пишется здесь.
Симптом (symptom)
Это поле показывает, к какой категории относится ошибка. Наиболее широко распространённые симптомы:
Примечание: Может ли у ошибки быть сразу несколько симптомов? Да, может. Но выбирать лучше самый важный (наиболее показательный).
Должен ли баг репорт содержать весь набор атрибутов?
Вроде бы, мы рассмотрели наиболее распространенные атрибуты для bug report. Все из перечисленных полей(атрибутов) заполняются создателем отчета. Поле приоритет редактируется менеджером проекта.
Отвечая на вопрос, нужно ли пользоваться всеми атрибутами, можно сказать, что в зависимости от требований и контекста ситуации конкретного проекта, выбранного процесса разработки набор полей отчета об инциденте может быть иным. Часто возникает необходимость добавления новых полей в отчет для сбора требуемых метрик. Процесс изменения состояний инцидентов также зависит от множества факторов. Названия полей в разных инструментах могут отличаться от описанных полей, но смысл остается прежним.