Средства трекинга ошибок

Знаете ли вы, что на каждые 1000 строк кода разработчики программного обеспечения могут допустить от 100 до 150 ошибок? Создание веб-приложений может показаться увлекательным процессом. Однако в процессе создания различных веб-приложений команда разработчиков будет сталкиваться с различными ошибками, что приведет к необходимости использования средств отслеживания ошибок. Наличие ошибок не означает, что вы плохой разработчик. Однако если вы позволите конечному пользователю обнаружить ошибку, вас могут оценить не как «очень» хорошего разработчика.

Ошибки могут привести к ухудшению качества обслуживания клиентов, потере прибыли или нарушению всего производственного процесса. Представьте себе, что вы работаете в сфере электронной коммерции; вы создали хорошую целевую страницу, но ваши клиенты не могут зарегистрироваться, чтобы купить ваши товары! Вы многое теряете, когда не можете отследить ошибки, имеющиеся в вашем приложении.

Что такое отслеживание ошибок?

Отслеживание ошибок, также известное как отслеживание дефектов или отслеживание проблем, — это процесс регистрации и мониторинга ошибок или багов в ходе тестирования программного обеспечения. Большие системы или веб-приложения могут содержать десятки и сотни ошибок. Каждый дефект/ошибку необходимо отслеживать, оценивать и определять приоритеты для отладки.

Как работает отслеживание ошибок

Ошибка возникает, когда система или приложение работают не так, как было задумано. Такие ошибки могли быть допущены разработчиками, дизайнерами или архитекторами программ. Команды тестирования используют различные средства отслеживания ошибок, чтобы отслеживать и сообщать об ошибках, появляющихся в приложении в процессе его разработки и тестирования.

Инструмент отслеживания ошибок должен иметь базу данных, в которую заносятся все факты об известных ошибках. К числу таких элементов относятся: время сообщения об ошибке, степень серьезности ошибки, влияние ошибки на нормальное функционирование приложения, возможность воспроизведения ошибки, кто выявил ошибку и кто работает над ее устранением.

Типичная ошибка может проходить следующие стадии:

• Активная ошибка. Ведется расследование.
• Проверенная ошибка. Ошибка уже исправлена и готова к тестированию.
• Проверенная ошибка. Ошибка была повторно протестирована и проверена отделом контроля качества.
• Закрытая ошибка. Отдел контроля качества повторно протестировал ошибку после ее исправления или выяснил, что она не является ошибкой.
• Вновь открыта. К сожалению, ошибка может пройти все вышеперечисленные стадии и так и не быть исправлена. Такая ошибка может быть вновь открыта.

Классификация ошибок

Все ошибки не одинаковы. Некоторые из них могут обеспечить минимальную функциональность, другие же могут привести к полному отказу системы. Вот некоторые из основных классификаций ошибок:

• Очень незначительные. Такую ошибку можно проигнорировать или найти простое решение. Такая ошибка не повлияет на выпуск продукта.
• Отказ некритичных систем. Для такой ошибки существует обходной путь. Система может быть выпущена, если такая ошибка хорошо документирована.
• Нарушение функциональности. Возможно, существует обходной путь, но он неудовлетворителен. Такую систему не следует выпускать для конечных пользователей.
• Катастрофическая. Такая ошибка может привести к невосстановимой потере данных и отказу приложения. Система с такой ошибкой не должна выпускаться.

Какими основными функциями должны обладать средства отслеживания ошибок?

Определение приоритетов ошибок

Все ошибки не одинаковы. Как только ошибка идентифицирована, следующим шагом должна быть ее оценка с последующей категоризацией. Инструменты отслеживания ошибок должны обладать этой функцией, чтобы обеспечить определение влияния ошибок, а затем расстановку приоритетов в зависимости от степени их серьезности.

Отслеживание состояния

При создании обширной системы у вас, скорее всего, возникнет множество ошибок. Инструмент отслеживания ошибок должен отслеживать их до тех пор, пока они не будут устранены, независимо от того, является ли эта проблема мелкой или крупной. Такой инструмент должен иметь приборную панель, на которой перечислены все проблемы и их текущее состояние для удобства отслеживания.

Аналитика и отчетность

Ошибка может стать хорошим уроком. Идеальный инструмент для отслеживания ошибок должен обладать функциями аналитики и отчетности, позволяющими собирать все данные, связанные с ошибкой, начиная с момента сообщения о ней и заканчивая ее устранением. Такой инструмент позволяет легко выявлять тенденции, анализировать важнейшие показатели и создавать специальные отчеты. Вот краткое описание лучших инструментов отслеживания ошибок, о которых я расскажу.

Продукт	Примечательные особенности
Zoho Bug Tracker	Отслеживание ошибок с расстановкой приоритетов, настройкой и совместной работой
monday.com	Управление работой, CRM и отслеживание ошибок с визуализацией
Bugyard	Сбор визуальной обратной связи от членов команды и клиентов
BugHerd	Управление проектами и отслеживание ошибок с предоставлением отчетов в режиме реального времени
Marker.io	Визуальный инструмент для создания отчетов об ошибках с возможностью совместной работы в режиме реального времени
DoneDone	Отслеживание ошибок в реальном времени, настраиваемые шаблоны
MantisBT	Инструмент отслеживания ошибок с открытым исходным кодом с пользовательскими и командными отчетами
Disbug	Обнаружение ошибок с помощью записи экрана, скриншотов и журналов
Ruttl	Инструмент обратной связи на сайте с функциями фиксации ошибок и совместной работы
Backlog	Инструмент отслеживания задач, настраиваемые шаблоны и репозитории
Bird Eats Bug	Отчеты об ошибках с захватом экрана и интеграцией с третьими сторонами

Давайте рассмотрим эти инструменты подробнее.

Zoho Bug Tracker

Zoho Bug Tracker — это простая, быстрая и масштабируемая система отслеживания ошибок, которая помогает разработчикам эффективно управлять ошибками.

Ключевые особенности:

• Расстановка приоритетов. С помощью этого инструмента можно регистрировать ошибки и отслеживать их по срокам исполнения, степени серьезности и даже по пользовательским полям и статусам.
• Настраиваемая приборная панель. Создатели Zoho понимают, что каждый проект уникален, поэтому инструмент поставляется с настраиваемой приборной панелью.
• Совместная работа. Наличие функций Forms и Discuss позволяет легко сотрудничать с командой и знать, над чем работают все члены команды.
• Автоматизация. Функция автоматизации удобна тем, что отправляет электронные письма при создании, обновлении и устранении ошибок.

Zoho предлагает бесплатный тарифный план для 3 пользователей и платные тарифные планы с бесплатным пробным периодом.

monday.com

monday.com — это отмеченная многими наградами платформа для управления работой, CRM и разработки. Ей доверяют более 180 000 клиентов, в том числе Canva, Outbrain, Wix, Uber и другие.

Платформа разработки представляет собой комплексное решение для поддержки всего жизненного цикла продукта — от стратегии развития продукта до выпуска и отслеживания ошибок. Платформа адаптивна и создана с учетом удобства пользователя. Она позволяет легко регистрировать ошибки, определять их приоритетность и отслеживать ход их устранения. Разработчики могут создавать персональные дорожные карты и диаграммы Ганта для визуализации планирования спринтов и отслеживания ошибок, что дает им возможность получить полный обзор всей необходимой информации.

Ключевые особенности:

• Централизованное отслеживание: Централизованное отслеживание ошибок для совместного поиска решений и визуализации прогресса.
• Автоматизация: Автоматизация позволяет не допустить пропусков ошибок, автоматически создавать тикеты поддержки и уведомлять соответствующих членов команды.
• Фильтрация и определение приоритетов: Отслеживайте ошибки с помощью тегов, фильтров и приоритетов. Просмотр статуса ошибки и времени, затраченного на ее устранение.
• Отчетность: Генерирует интерактивные отчеты для анализа тенденций, таких как повторяющиеся проблемы и среднее время устранения ошибок, что помогает принимать обоснованные решения.

Готовый к использованию шаблон отслеживания ошибок позволяет создать систему отслеживания ошибок за считанные минуты и настроить ее в соответствии с вашими требованиями. Программа опробована и протестирована в течение 14-дневного пробного периода. Компания предлагает скидки для квалифицированных некоммерческих организаций.

Bugyard

Bugyard помогает владельцам сайтов собирать визуальные отзывы от своих коллег и клиентов прямо на сайте. Bugyard — один из лучших инструментов отслеживания ошибок для фрилансеров и компаний малого и среднего бизнеса.

Ключевые особенности:

• Визуальная обратная связь. Помимо того, что Bugyard опирается на отзывы клиентов, он делает скриншоты вашей веб-страницы в том виде, в котором ее видят конечные пользователи.
• Доступность на протяжении всего цикла. Bugyard помогает отслеживать ошибки в процессе разработки и после запуска сайта в эксплуатацию.
• Сбор необходимых метаданных. Снимок экрана содержит необходимые технические метаданные, такие как браузер, разрешение экрана, операционная система и размер.
• Интеграция с инструментами сторонних разработчиков. Вы можете интегрировать Bugyard со сторонними приложениями, такими как Zendesk, Freshdesk, Trello, Gmail и Slack.

Bugyard предлагает несколько тарифных планов для фрилансеров, команд и агентств.

BugHerd

BugHerd — это инструмент управления проектами и отслеживания ошибок для дизайнеров и разработчиков. Платформа проста в использовании благодаря интуитивно понятному пользовательскому интерфейсу и многочисленным видеороликам.

Ключевые особенности:

• Автоматизированный. Bugherd имеет различные автоматизированные средства сбора технических данных.
• Отчетность в реальном времени. Функции записи экрана и комментирования позволяют создавать отчеты в режиме реального времени для работы команды разработчиков.
• Панель управления проектом. В Bugherd есть доска задач в стиле канбан, где руководители программ могут назначать задания различным разработчикам.
• Неограниченное количество участников. Функция неограниченного количества гостей и проектов позволяет разработчикам приглашать столько людей, сколько они хотят, для рецензирования своего кода.

Стоимость Bugherd начинается от 33 долл. в месяц с 14-дневным бесплатным пробным периодом.

Marker.io

Marker.io — это инструмент визуального информирования об ошибках для команд разработчиков программного обеспечения и агентств. Инструмент имеет виджет на сайте, позволяющий разработчикам собирать отзывы с помощью технических данных, скриншотов и аннотаций.

Ключевые особенности:

• Обратная связь в реальном времени. Marker.io записывает видео, аннотации и скриншоты.
• Инструменты для совместной работы. Платформа позволяет командам разработчиков сотрудничать и получать информацию от сторонних специалистов.
• Автоматизация. Инструмент автоматически отправляет электронные письма в зависимости от стадии ошибки.
• Интеграция со сторонними разработчиками. Marker.io можно интегрировать с такими инструментами управления проектами и контентом, как Teamwork, Shortcut, Notion, Trello, Asana, ClickUp, Wrike, monday.com, WordPress, Jira, GitHub и GitLab.

Стоимость тарифных планов начинается от 49 долл. в месяц с 15-дневной бесплатной пробной версией. Также предлагается скидка 20% на годовые планы.

DoneDone

DoneDone — один из старейших инструментов отслеживания ошибок, запущенный в 2009 году. Современный подход позволяет легко отслеживать ошибки и предоставлять информацию о них в режиме реального времени.

Ключевые особенности:

• Отчетность в режиме реального времени. Инструмент генерирует мгновенные отчеты для принятия решений.
• Шаблоны ошибок. Если вы не знаете, как начать отслеживать ошибки, вы можете настроить имеющиеся шаблоны.
• Автоматизация. Инструмент отправляет обновления состояния на связанные с ним электронные письма.
• Сторонние интеграции с Basecamp, HipChat, GitHub.

Стоимость тарифных планов начинается от 4 долл. в месяц, также имеется бесплатная пробная версия.

MantisBT

MantisBT — это инструмент отслеживания ошибок с открытым исходным кодом, предназначенный для разработчиков программного обеспечения. С помощью этого инструмента, сочетающего в себе мощь и простоту, пользователи могут за считанные минуты приступить к работе и сотрудничать над различными проектами.

Ключевые особенности:

• Отчеты и отзывы пользователей. Предусмотрена возможность сообщать об ошибках в приложении.
• Отчеты и комментарии команды разработчиков. Команда разработчиков может собирать отчеты и комментарии с помощью этого инструмента.
• Мониторинг ошибок. Разработчики могут легко использовать аналитику и отчеты об истории ошибок, доступные в этом инструменте.
• Отчеты и отзывы тестировщиков. Бета-тестеры могут оставлять свои отзывы с помощью этого инструмента до того, как новые функции будут выпущены для пользователей.

MaintisBT доступен в виде бесплатной пробной версии, а стоимость платных тарифных планов начинается от 4,95 долл. в месяц.

Disbug

Disbug — это инструмент, позволяющий обнаруживать и отслеживать ошибки с помощью записи экрана, скриншотов, журналов консоли и сетевых журналов.

Ключевые особенности:

• Кнопка с одним щелчком мыши. Вы можете легко объяснить и рассказать о проблеме/ошибке одним щелчком мыши.
• Интеграция со сторонними приложениями. Disbug может быть связан с такими инструментами, как Jira и Trello, для эффективного мониторинга и отчетности.
• Инструменты для совместной работы. Disbug поддерживает совместную работу, и вы можете приглашать других людей к участию в вашем проекте.

Disbug предлагает различные тарифные планы для стартапов, агентств, компаний и даже индивидуальные тарифные планы для предприятий.

Ruttl

Ruttl — это инструмент обратной связи с веб-сайтами, позволяющий пользователям редактировать «живые» сайты, оставлять комментарии в режиме реального времени, делать гостевые комментарии, быстро загружать изображения и делиться ссылками с клиентами.

Ключевые особенности:

• Фиксация проблем/ошибок. В Ruttl имеются встроенные шаблоны, которые можно использовать для фиксации информации об ошибках.
• Совместная работа. Ruttl — идеальный инструмент для разработчиков и дизайнеров, которые хотят сотрудничать над различными проектами.
• Уведомления/оповещения. Весь жизненный цикл ошибок фиксируется, а уведомления отправляются по электронной почте.
• Интеграция с третьими сторонами. Вы можете использовать Ruttl совместно со Slack, Trello и Jira Board.

Ruttl предлагает бесплатный тарифный план и платные тарифные планы стоимостью от 13 долл. в месяц.

Backlog

Backlog от Nulab используется разработчиками и руководителями команд для сбора, приоритизации и распределения различных задач между членами команды.

Ключевые особенности:

• Настраиваемые шаблоны. Backlog поставляется с шаблонами, которые можно настраивать в зависимости от потребностей.
• Захватывает все. При использовании Backlog важна каждая деталь, поскольку он фиксирует запросы на внесение изменений, слияния, сборки, обновления и многое другое.
• Git и SVN. Инструмент поставляется со встроенными репозиториями, что упрощает управление кодом.
• Обмен файлами с помощью перетаскивания. Вы можете хранить все связанные рабочие файлы в едином пространстве.

Backlog имеет бесплатный уровень, а стоимость платных пакетов начинается от 35 долл. в месяц.

Bird Eats Bug

Bird Eats Bug — это инструмент для руководителей, инженеров-программистов, специалистов по контролю качества и дизайнеров. Этот инструмент также поставляется с расширением для хрома, которое показывает сетевые ошибки и ошибки JavaScript в реальном времени.

Ключевые особенности:

• Простой захват экрана. Захват экрана позволяет регистрировать ошибки в режиме реального времени, а также создавать отчеты об ошибках одним щелчком мыши.
• Веб- SDK. Разработчики могут установить веб- SDK, который позволяет собирать отчеты об ошибках с большим количеством данных.
• Интеграция со сторонними приложениями. Bird Eats Bug можно использовать с различными инструментами, такими как GitHub, Trello, Zapier, Slack и Jira Cloud.

Bird Eats Bug имеет бесплатный уровень, в то время как платные версии начинаются от 40 долларов в месяц при ежегодной оплате.

Подведение итогов

Если вы хотите, чтобы вас считали серьезным разработчиком, независимо от того, создаете ли вы свой сайт для портфолио или веб-приложения для клиентов, вам следует обратить внимание на отслеживание ошибок. Отбросьте эту электронную таблицу и выберите любой из перечисленных выше инструментов, который соответствует вашим потребностям!

Просмотров: 105

From Wikipedia, the free encyclopedia

A bug tracking system or defect tracking system is a software application that keeps track of reported software bugs in software development projects. It may be regarded as a type of issue tracking system.

Many bug tracking systems, such as those used by most open-source software projects, allow end-users to enter bug reports directly.^[1] Other systems are used only internally in a company or organization doing software development. Typically bug tracking systems are integrated with other project management software.

A bug tracking system is usually a necessary component of a professional software development infrastructure, and consistent use of a bug or issue tracking system is considered one of the «hallmarks of a good software team».^[2]

Making[edit]

A major component of a bug tracking system is a database that records facts about known bugs. Facts may include the time a bug was reported, its severity, the erroneous program behavior, and details on how to reproduce the bug; as well as the identity of the person who reported it and any programmers who may be working on fixing it.^[3]

Typical bug tracking systems support the concept of the life cycle for a bug which is tracked through the status assigned to the bug. A bug tracking system should allow administrators to configure permissions based on status, move the bug to another status, or delete the bug. The system should also allow administrators to configure the bug statuses and to what extent a bug in a particular status can be moved. Some systems will e-mail interested parties, such as the submitter and assigned programmers, when new records are added or the status changes.

Usage[edit]

The main benefit of a bug-tracking system is to provide a clear centralized overview of development requests (including both bugs and improvements; the boundary is often fuzzy), and their state. The prioritized list of pending items (often called backlog) provides valuable input when defining the product road map, or maybe just «the next release».

In a corporate environment, a bug-tracking system may be used to generate reports on the productivity of programmers at fixing bugs. However, this may sometimes yield inaccurate results because different bugs may have different levels of severity and complexity. The severity of a bug may not be directly related to the complexity of fixing the bug. There may be different opinions among the managers and architects.

A local bug tracker (LBT) is usually a computer program used by a team of application support professionals (often a help desk) to keep track of issues communicated to software developers. Using an LBT allows support professionals to track bugs in their «own language» and not the «language of the developers.» In addition, an LBT allows a team of support professionals to track specific information about users who have called to complain—this information may not always be needed in the actual development queue. Thus, there are two tracking systems when an LBT is in place.

Part of integrated project management systems[edit]

Bug and issue tracking systems are often implemented as a part of integrated project management systems.
This approach allows including bug tracking and fixing in a general product development process, fixing bugs in several product versions, automatic generation of a product knowledge base and release notes.

Distributed bug tracking[edit]

Some bug trackers are designed to be used with distributed revision control software. These distributed bug trackers allow bug reports to be conveniently read, added to the database or updated while a developer is offline.^[4] Fossil and Veracity both include distributed bug trackers.

Recently, commercial bug tracking systems have also begun to integrate with distributed version control. FogBugz, for example, enables this functionality via the source-control tool, Kiln.^[5]

Although wikis and bug tracking systems are conventionally viewed as distinct types of software, ikiwiki can also be used as a distributed bug tracker. It can manage documents and code as well, in an integrated distributed manner. However, its query functionality is not as advanced or as user-friendly as some other, non-distributed bug trackers such as Bugzilla.^[6] Similar statements can be made about org-mode, although it is not wiki software as such.

Bug tracking and test management[edit]

While traditional test management tools such as HP Quality Center and IBM Rational Quality Manager come with their own bug tracking systems, other tools integrate with popular bug tracking systems.^{[citation needed]}

See also[edit]

• Application lifecycle management
• Comparison of issue-tracking systems – Including bug tracking systems
• Comparison of project management software – Including bug tracking systems

References[edit]

External links[edit]

• Bug Tracking Software at Curlie
• How to Report Bugs Effectively by Simon Tatham
• List of distributed bug tracking software

Выбираем подходящий баг-трекинг

Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.

Интро

Буду банален. Ошибки появляются и обнаруживаются на различных этапах процесса разработки. Поэтому можно разделить баги на категории, в зависимости от времени их обнаружения:

• Недоделки. Это ошибки, которые допустили разработчики, пока пилили новый функционал. Такие ошибки находят при исследовательском или приемочном тестировании новых фич на девелоперских стендах команд.
• Баги в регрессе. Это дефекты, которые находят ручные регрессионные тесты или автоматические UI и API тесты на стенде для интеграции кода. 
• Баги с прода. Это проблемы, которые нашли сотрудники или клиенты и обратились в службу технической поддержки.

С чего мы начинали, или Jira

Два года назад у нас была выделенная команда тестировщиков, которые вручную тестировали продукт после интеграции кода всех команд. До этого момента код проверялся разработчиками на девелоперских стендах. Ошибки которые находили тестировщики заносились в бэклог в Jira. Баги хранились в общем бэклоге и переезжали из спринта в спринт с другими задачами. Каждый спринт два-три бага доставались и чинились, но большинство оставалось на дне бэклога:

1. Одна из причин, по которой баги копятся в бэклоге  – они не мешают пользователям. У таких багов низкий приоритет и их не будут чинить.
2. Также, если в компании нет чётких и понятных правил заведения багов, тестировщики могут добавлять одну и ту же проблему несколько раз, потому что не смогли найти в этом списке уже добавленный баг-репорт.
3. Ещё одной причиной может послужить то, что на проекте задействованы неопытные тестировщики. Ошибка начинающих тестировщиков, заносить в баг-трекинг все баги найденные во время работы. Неопытные тестировщики считают целью тестирования  – поиск багов, а не предоставление информации о качестве продукта и предотвращение появления дефектов.

Приведу простой пример. При построении отчётов в полях ввода даты по умолчанию подставляется сегодняшний день. При изменении даты в попапе можно снова выбрать сегодняшний день и поле ввода даты очистится.

У меня есть подозрения, что за все время работы нашей сети, никто, кроме тестировщиков не воспроизводил эту ошибку. Такого рода ошибки и составляют большинство багов, которые не исправляются.

При таком подходе, когда заносятся все найденные баги, некоторые из них дублируются и большинство из этих багов не чинится возникают проблемы:

• Тестировщики демотивируются, так как ошибки которые они находят не исправляются разработчиками. Складывается ощущение, что работа не имеет смысла.
• Владельцу продукта сложно управлять бэклогом с большим количеством багов.

Прощай Jira, да здравствует Kaiten

Весной 2018 года мы отказались от Jira и перешли в Kaiten. Смена инструментов была вызвана причинами, о которых Андрей Арефьев написал в статье «Почему Додо Пицца стала использовать Kaiten вместо связки Trello и Jira». После перехода в Kaiten наш подход к работе с багами не изменился:

• Недоделки заносились на командные доски и разработчики самостоятельно решали чинить их или нет.
• Баги, которые нашли в регрессе (его проводила выделенная команда тестировщиков), чинили в релизной ветке и не релизили код, пока все проблемы не были исправлены. Мы решили, что логичнее вести и собирать информацию об этих проблемах в канале тестировщиков в Slack. Тестировщики писали сообщение, которое содержало легенду, список багов с логами и имена разработчиков, которые взяли задачу в работу. С помощью эмоджи меняли статус, а в трэдах обсуждали, прикладывали скрины, синхронизировались. Тестировщиков этот формат устраивал. Некоторым разработчикам не нравился такой способ, потому что в чате параллельно шла другая переписка и это сообщение уходило наверх и его не было видно. Мы его закрепляли, но это не сильно упрощало жизнь.

• Баги которые нашли на проде заносились в бэклог, Product Owner, расставлял приоритеты и выбирал те, которые будем чинить.

Время экспериментов, или нет

Мы решили поэкспериментировать с форматами и создали отдельную доску в Kaiten, на которой хранили баги и меняли статусы. Мы упростили заведение баг-репорта, чтобы тратить меньше времени. При добавлении карточки в Kaiten тестировщики помечали разработчиков. Об этом им на почту отправлялось уведомление. Мы вывели эту доску на монитор, который висел в проходе рядом с нашим рабочим местом, чтобы разработчики видели прогресс и процесс тестирования стал прозрачным. Эта практика тоже не прижилась, потому что основной канал общения  – Slack. Наши разработчики не проверяют почту часто. Поэтому это решение быстро перестало работать и мы снова вернулись к Slack.

Верните муравьишек

После неудачного эксперимента с доской в Kaiten, некоторые разработчики всё ещё были против формата с сообщением в Slack. И мы стали думать как трекать баги в слаке и решить проблемы, которые мешали разработчикам. В результате поисков наткнулись на приложение для Slack, Workast, которое помогает организовать работу с тудушками прямо в мессенджере. Мы подумали, что это приложение позволит управлять процессом работы с багами более гибко. У этого приложения были свои плюсы: смена статусов и назначение на разработчиков по одному нажатию кнопки, завершенные задачи скрывались и сообщение не разрасталось до огромных размеров.

Так выглядели решенные задачи в приложении Todo и просьбы вернуть «муравьишек». После окончания пробного периода приложения Workast мы решили от него отказаться. Потому что пользуясь этим приложением, мы пришли к тому же, что было во время, когда мы пользовались Jira. Оставались некоторые баги, которые кочевали в этом списке из регресса в регресс. И с каждой итерацией их становилось больше. Возможно, стоило доработать процесс работы с этим расширением, купить его и пользоваться, но мы этого не сделали.

Наш идеальный способ по работе с багами сейчас

В конце 2018 - начале 2019 года у нас в компании произошли ряд изменений, которые повлияли на процесс работы с багами.

Во-первых, у нас не стало выделенной команды тестировщиков. Все тестировщики разошлись в команды разработчиков, для усиления компетенции тестирования команд. Благодаря этому мы стали находить ошибки раньше, до того как произойдет интеграция кода команд.

Во-вторых, мы отказались от ручного регрессионного тестирования в пользу автоматического.

В-третьих, мы приняли «zero bug policy». В статье «#zerobugpolicy или как мы баги чиним» bevzuk подробно рассказывает как мы выбираем баги, которые чиним.

Сегодня процесс работы с багами выглядит следующим образом:

• Недоделки. Тестировщики сообщают о проблеме аналитикам или продакт менеджерам. Идут ногами, показывают, воспроизводят, объясняют как это повлияет на клиентов и решают нужно ли это починить до релиза или можно починить позже, а может даже и не стоит чинить совсем.
• Баги в регрессе, которые нашли автотесты, чинит команда, которая трогала этот участок системы и мы не релизим этот код, пока не решим проблему. Тестировщики фиксируют эти баги в произвольном формате в канале релиза в Slack.
• Баги с прода. Такие баги попадают напрямую к владельцам задач. Аналитики прогоняют ошибки по Матрице приоритетов бага и добавляют в бэклог либо фиксируют у себя, накапливая статистику обращений по этой проблеме.

Итоги

Коротко говоря, мы отказались в принципе от баг-трекинговой системы. С помощью такого подхода работы с багами мы решили несколько болей:

• Тестировщики не расстраиваются из-за того, что ошибки, которые они находят и заводят в баг-трэкинг не исправляются.
• Тестировщики не тратят время на заведение и полное описание багов, которые даже никто не прочтёт.
• PO проще управлять бэклогом, в котором нет мёртвого груза.

Я не хочу сказать, что трэкинг багов бесполезен. Баги которые мы берём в работу трэкаются как и любые другие задач. Но баг-трэкинговая система это не обязательный атрибут тестирования. Её не нужно использовать только потому, что используют большинство компаний и так принято в индустрии. Нужно «думать головой» и примерять инструменты к своим процессам и потребностям. Для нас идеально работать без баг-трекинговой системы сейчас. За пол года такой работы, мы ни разу не подумали о том, чтобы вернуться к ней и снова заводить все баги туда.

А как в вашей компании устроен процесс работы с багами?

Зачем нужен? Для того чтобы максимально повысить эффективность своей работы, тестировщик, программист или целая фирма по разработке программного обеспечения используют в своей работе различные программы. Одной из них является баг-трекер. Он помогает выявлять и отслеживать ошибки в программах и кодах.

Что дает? Вопрос о том, как упорядочить данные, касающиеся многочисленных задач, проектов и клиентов, становится все более актуальным. Чтобы вести учет рабочего времени и обеспечить всесторонний обзор для определения приоритетов, отлично помогают баг-трекеры.

Понятие баг-трекера

Система отслеживания ошибок (от англ. bug tracking system) является программным продуктом, предназначенным для помощи проектировщикам ПО при поиске и анализе ошибок кода.

В качестве основного элемента баг-трекера выступает база данных, в которой аккумулированы сведения обо всех найденных ошибках. Примерная структура этого хранилища информации:

• автор сообщения о возникшей проблеме;
• дата и время обнаружения;
• степень критичности ошибки;
• проявление бага при запуске приложения;
• корректировщик, занимающийся оптимизацией кода и устранением проблемы;
• состояние ошибки.

При использовании bug tracking system применяется принцип «жизненного цикла» ошибки, который фиксируется по условиям возникновения проблемы. Система, в зависимости от реализации, может содержать функционал, позволяющий администратору ограничивать доступ к просмотру и редактированию кода, изменять состояние ошибки и удалять их.

Систему отслеживания ошибок можно также применять в корпоративной среде. В этом случае задействуется функция оценки продуктивности программистов. Тем не менее это использование баг-трекера не всегда эффективно по причине того, что ошибки имеют различное происхождение и сложность. При этом усилия, затраченные на устранение проблемы, не всегда адекватны ее серьёзности. Иногда на поиск и устранение легкой ошибки требуется много времени и напряженного труда.

Жизненный цикл бага

Обычно bug tracking system использует кокой-либо из вариантов «жизненного цикла» ошибки. Статус бага определяется текущим состоянием.

Рассмотрим классический жизненный цикл дефекта:

1. Новый — ошибка выявлена при тестировании.
2. Назначен — определен специалист, отвечающий за нивелирование бага.
3. Разрешён — дефект возвращается для повторной работы тестировщика. Обычно дается комментарий, содержащий следующую информацию:
   • откорректировано (исправления входят в патч или новую версию программного продукта);
   • дубль (обнаружен повтор ошибки, над устранением которой уже проводится работа);
   • не исправлено (дефект незначительный, не влияющий на работоспособность, исправление отложено до выхода следующей версии и т.д.);
   • невоспроизводимо (не удается выявить баг; происходит запрос об условиях возникновения ошибки).
4. Тестировщик повторно проверяет исправленную версию кода, если ошибка воспроизводится, то баг повторно получает статус «назначен». В случае успешного прохождения теста – статус «закрыт».
5. Запись «открыт вторично» означает наследование ошибки в новой версии программного продукта.

Как уже упоминалось, баг-трекер дает администратору возможность гибкой настройки доступа пользователей к просмотру и редактированию кода.

Система обнаружения ошибок в современных условиях просто необходима для построения правильного процесса тестирования, и ни один QA-инженер вне зависимости от своего опыта не обходится без нее в своей деятельности. На данный момент существует множество самых различных баг-трекеров. Выбор из такого разнообразия зачастую сопряжен с определенными трудностями.

Баг-трекинговые системы

Все изобилие bug tracking system подразделяются на две категории – лицензионные и бесплатные. Несмотря на то, что тариф free предлагает немного урезанный функционал и некоторые ограничения, тестировщики охотно используют такие системы в своей повседневной практике. Произведем сравнение баг-трекеров, наиболее эффективных с точки зрения QA-инженеров.

Redmine

Основные характеристики:

• Абсолютно бесплатная система с открытым исходным кодом.
• Интуитивно-понятный удобный интерфейс с поддержкой 34 разных языков (в том числе и русского).
• Возможность планирования с помощью диаграммы Ганта.

Redmine – больше, чем просто баг-трекер. Это полноценное решение для управления проектами, что делает систему такой же популярной, как Jira. Программа написана на языке Ruby и совместима с Microsoft SQL, MySQL, PostgreSQL и SQLite.

Отчет ошибок доступен для просмотра любым пользователем, которого добавили в проект со статусом «наблюдатель». Система поддерживает несколько баз данных с учетом временных затрат. Очень удобно реализована функция планирования и отслеживания задач при помощи диаграммы Ганта.

Скачать
файл

Среди недостатков можно отметить: недостаточную развитость механизма предоставления прав пользователя и отсутствие оповещения об изменениях в документе.

Mantis

Также является бесплатным инструментом. Весьма лаконичное простое приложение, доступен как Web-интерфейс, так мобильная версия. Среди достоинств выделяют поддержку time tracking, доступ к истории изменений проекта, наличие многофункциональной мобильной версии, множество плагинов, позволяющих значительно расширить возможности программы.

К недостаткам относятся скудный аскетичный интерфейс, возможность создания только одного скриншота к отчету об ошибке, отсутствие автоматического отслеживания дефектов.

Яндекс.Трекер

Платный сервис, но предоставляет доступ к функционалу в ознакомительных целях на 30 дней, по истечении которых пользователю необходимо будет приобрести лицензию. В работе используется методология Agile, предполагающая определенную гибкость при работе над проектами. Участникам доступно создание задач с описанием, а также есть возможность назначения исполнителей и наблюдателей.

Bugzilla

Mozilla Foundation разработала это приложение еще в 1998 году. Bugzilla является одним из самых популярных сервисов по отслеживанию ошибок. Программа имеет открытый исходный код. Перечислим основные функции этого баг-трекера:

• Формирование подробного отчета с возможностью наглядного представления информации в виде графиков, диаграмм, таблиц. Поддерживается конвертация в CSV, что дает возможность вносить свои изменения.
• Поддержка расширенных поисковых запросов.
• Наличие корректора исправлений.
• Возможность наблюдения за действиями других пользователей при наличии соответствующих прав доступа.
• Отслеживание времени.
• Гибкость при настройке полей и рабочих процессов.
• Опция проверки работоспособности позволяет вам сканировать свою базу данных для получения баг-репорта с предложениями по устранению ошибок.
• Поддержка плагинов и хорошие возможности интеграции с другими платформами, позволяющие использовать приложение в веб-обозревателях, почтовых клиентах и сервисах управления проектами.

Программа Bugzilla написана на языке Perl. Имеет полную совместимость с такими базами данных, как Oracle, MySQL и PostgreSQL. Несмотря на то, что разработчики программы для получения наилучшей производительности рекомендуют применение с Apache 2.2, в действительности нет никаких минимальных требований к серверу.

Jira

Первоначально программа задумывалась как классический баг-трекер, но сейчас эта платформа позволяет использовать функцию планирования agile-проектов. На сегодняшний день Jira является, пожалуй, самым популярным продуктом в сфере разработки и тестирования программного обеспечения. Расширенные возможности приложения:

• гибкое всестороннее управление проектами;
• осуществление контроля за всеми стадиями процесса;
• среда создания прикладных программ.

Используя комплексную систему Jira, тестировщики могут подвергать классификации все задачи по различным критериям и управлять статусом ошибки. Причем все внесенные изменения хранятся в истории и доступны для просмотра и анализа.

Программа помогает реализовать принципы управления проектами «Scrum» и «Kanban».

Jira – это платный сервис, но имеющий тариф free для добавления 10 пользователей. Система представляет собой интерактивную доску – Dashboard, с помощью которой удобно отслеживать выполнение решаемых задач.

Среди достоинств баг-трекера выделяют: расширенный функционал, который можно значительно развить установкой плагинов; гибкую настройку рабочих столов; интеграцию с другими системами (Trello, Slack, Git, Zephyr, Google Drive & Docs и др.); связывание задач и ошибок; возможность построения диаграммы Ганта.

Настраиваемые элементы Jira:

• план решения проблем;
• рабочий стол пользователя;
• типы задач;
• окна;
• результаты;
• уведомления.

Так как Jira является достаточно мощным инструментом со множеством настроек и возможностей, ее использование в небольших коллективах тестировщиков сопряжено с некоторыми трудностями. Кроме того, использование этого баг-трекера требует обладания пользователем определенными знаниями и навыками.

YouTrack

Платный сервис, поддерживающий Scrum и Kanban. Основные характеристики:

• Очереди задач для группировки.
• Расширенный поиск по нескольким настраиваемым фильтрам.
• Возможность ограничения доступа к задачам, имеющим конфиденциальную информацию.

YouTrack – детище компании JetBrains, являющейся известным авторитетом в сфере проектирования ПО для отслеживания ошибок. Сервис имеет возможности интеграции с большим количеством CVS, а также с GitHub и Bitbucket. Кроме того, система обладает рядом уникальных возможностей, значительно облегчающих работу тестировщиков. Например, наличие возможности учета издержек на проект и автопоиск дубликатов.

Web Issues

Предназначение сервиса – организация совместной работы. Программа с открытым исходным кодом предоставляет вам возможность доступа из любого веб-обозревателя по желанию.

Перечислим основной функционал приложения:

• Фиксация в журнале истории всех внесенных в проект изменений.
• Возможность прикрепления скриншотов к баг-репортам.
• Координация действий участников команды при работе над решением задачи.
• Контроль доступа пользователей.
• Экспорт проблем в файлы CSV
• Сохранение баг-репорта в формате PDF и HTML.
• Шифрование канала по SSL-протоколу.

Это далеко не полный перечень баг-трекеров. Возможно, прочитав статью, вы сможете остановить свой выбор именно на том инструменте, который позволит в полной мере реализовать проекты, и работа над ними будет продуктивной и комфортной благодаря своевременному поиску и исправлению ошибок.

Привлекает мир кодирования и создания программ? На курсе программиста с нуля до Junior вы освоите основы, познакомитесь с языками и инструментами разработки, и станете готовы к созданию своих первых проектов в IT-индустрии.

С этой задачей нам помогут справиться баг-трекинговые системы, которых на рынке сейчас достаточно много. Рассмотрим самые популярные и удобные из них.

Jira

Изначально Jira предназначалась только для отслеживания ошибок. Однако сейчас она также используется для планирования agile-проектов.

Это платная система. Но есть тариф “Free” с возможностью добавления 10 пользователей.

Jira представляет собой интерактивную доску (Дашборд), с помощью которой можно следить за выполнением поставленных задач. Все задачи классифицируются различными видами функций, подзадач, багов и т.д. Они могут редактироваться, назначаться на различных исполнителей или просто изменять статус с «открыт» на «закрыт». Все изменения по задаче записываются в журнал.

Плюсы:
— Широкий функционал, который можно дополнительно расширить с помощью плагинов.
— Интеграция с различными системами (Git, Zephyr, Trello, Slack, Google Drive & Docs, draw.io и так далее).
— Есть возможность строить диаграмму Ганта.
— Рабочие столы можно настроить под себя.
— Позволяет составлять план работы.
— Возможность искать задачи по гибким фильтрам.
— Наличие мобильного приложения.
— Связывание задач/ошибок.
— Уведомления по электронной почте.
— Пользователи получают последние обновления о ходе выполнения проектов.

Минусы
— Сложность настройки и обслуживания, особенно для малого бизнеса и небольших команд.
— Иногда тяжело найти то, что нужно (из-за огромного количества функций).
— Требуется много времени, чтобы научиться эффективно использовать.

Redmine

Это бесплатное веб-приложение. И это больше, чем просто трекер ошибок. Redmine — решение для управления проектами с открытым исходным кодом и существует он уже более десяти лет. Написан на Ruby и совместим с MySQL, PostgreSQL, Microsoft SQL и SQLite.

Баг-репорт может отслеживаться любым сотрудником, который добавлен в проект и отмечен как наблюдатель.

Плюсы:
— Есть возможность установить дополнительные плагины для расширения функционала.
— Удобный пользовательских интерфейс.
— Возможность планирования с помощью диаграммы Гантта.
— Ленты и уведомления по электронной почте.
— Многоязычный интерфейс (поддерживает 34 разных языка).
— Поддержка нескольких баз данных.
— Учет временных затрат.
— Гибкая система отслеживания проблем.

Минусы:
— Некоторые функции очень скрыты.
— Сложно разобраться в установке на сервер.
— На больших объемах данных, пользователей или количестве подключенных плагинов начинает снижаться производительность.
— Отсутствуют оповещения об изменении документов.
— Слабо развита система предоставления прав пользователя (например, ограничения доступа к определенным задачам проекта).

Mantis

Бесплатный инструмент. По сравнению с другими баг-трекинговыми системами, это довольно простой инструмент. Он доступен как в виде web-приложения, так и в мобильной версии. Баг-репорт можно назначить на любого пользователя, который работает в проекте.

Инструмент построен на PHP и совместим с базами данных MySQL и PostgreSQL. Его также можно настроить для управления проектами.

Плюсы:
— Открытый исходный код.
— Возможность настройки полей.
— Поддержка time tracking.
— Возможность работы в нескольких проектах одновременно.
— Доступная история изменений в отчетах.
— Неограниченное количество пользователей, проектов и баг-репортов.
— Управление доступом, которое можно изменить для каждого проекта.
— Настраиваемые поля проблем.
— Многофункциональная мобильная версия (iPhone, Android и Windows Phone).
— Есть плагины, которые значительно улучшают использование инструмента.

Минусы:
— В процессе создания отчета об ошибке можно прикрепить только один снимок экрана. Можно прикрепить еще один к уже созданному сообщению об ошибке.
— Пользовательский интерфейс не привлекателен.
— Нет возможности сгенерировать отчет о проделанной работе.
— Нет возможности отслеживать что-то автоматически.

Trac

Открытая бесплатная веб-система для контроля багов и разработки софтверных продуктов. Есть русская локализация.

Trac специально создан для проектов разработки и отслеживания проблем, но также может использоваться для управления документами. Он имеет минималистский дизайн, встроенную вики и интегрируется с Apache Subversion и GitHub.

Можно связать ошибки с различными задачами, файлами, страницами вики или ошибками. Trac написан на Python и совместим с SQLite, MySQL и PostgreSQL.

Плюсы:
— Поддержка нескольких платформ: Linux, Unix, Mac OS X, Windows и т.д.
— Перекрестные ссылки между базой данных зарегистрированных ошибок, системой контроля версий и вики-страницами.
— Мониторинг и управление прогрессом.
— Параметры управления пользователями.
— Подсветка кода и сравнение файлов.
— Большое количество плагинов.

Минусы:
— Несколько проектов не могут быть обработаны.
— Ограниченная функциональность, если не использовать все его плагины.
— Комплексная установка.

Яндекс.Трекер

Сервис для управления проектами по методологии Agile. Платный, но предоставляется бесплатный доступ на 30 дней.

Пользователи могут создавать задачи, описывать их, назначать исполнителей и наблюдателей, а также комментировать ход решения вопроса в карточке задачи. Гибкие настройки прав доступа. Высокая производительность.

Плюсы:
— Живые задачи в реальном времени.
— Очереди задач для группировки.
— Фильтры и поиск.
— Дашборды, визуализация прогресса, agile-доски.
— Учёт времени и трудозатрат.
— Напоминания и призывы.
— Просмотр истории изменений.
— Интеграция с GitHub, возможность добавлять вызовы API в программы, написанные на языке Python (то есть можно легко перенести данные из другого инструмента).
— Есть дополнительные плагины.
— Возможность ограничить доступ к задачам с конфиденциальной информацией.
— Мобильное приложение для iOS и Android.

Минусы:
— Довольно «сырое» мобильное приложение, ряд действий можно осуществлять только с ПК.

Zoho

Платная система, но при регистрации до 3-х пользователей предусмотрен бесплатный тариф. Zoho Issue Tracker является неотъемлемым модулем для программного обеспечения Zoho Projects. Это облачная сквозная система, которая позволяет сообщать об ошибках, управлять рабочими процессами и исправлять дефекты.

Плюсы:
— Гибкий рабочий процесс.
— Разные категории вопросов.
— Пользовательские циклы управления ошибками.
— Подробные отчеты.
— Гибкая система фильтрации: серьезность, категория и т.д.
— Многофункциональное мобильное приложение.
— Интуитивно понятный интерфейс.
— Просмотр статистики пользователя.
— Интеграция с Bitbucket и GitHub.
— Автоматический багтрекер. Позволяет установить правила для запуска обновлений в полях ошибки или в сторонних приложениях.
— Уведомления по электронной почте об изменениях.

Минусы:
— Проблемы с поддержкой клиентов из разных часовых поясов.
— Дополнительная плата за Zoho Reports.
— Сложно учиться.

YouTrack

Платный баг-трекер с возможностью пользоваться бесплатной ограниченной версией. Поддерживает Scrum и Kanban, а также работу по собственной (свободной) методике. Обеспечивает контроль просроченных задач, диаграммы «выгорания задач» и кумулятивного потока исполнения, поддержку вложенных задач, а также возможность обслуживания нескольких проектов в одной контрольной панели.

Доступен в виде облачного сервиса, либо в виде веб-приложения для установки на собственный веб-сервер.

Плюсы:
— Хорошо настроенный инструмент.
— Интеллектуальный поиск.
— Экспорт в CSV.
— Тайм-менеджмент.
— Специальные команды для быстрой смены нескольких задач одновременно.
— 17 видов отчетов.
— Специальные теги для группировки вопросов.
— Создание вопросов по электронной почте.
— Логическое связывание задач.
— Режим вики.

Минусы:
— Поддержка недостаточна даже в платных версиях.
— Нет отслеживания вех.
— Проекты имеют публичный статус в бесплатной версии.

Trello

Веб-приложение, которое изначально было предназначено для управления проектами небольших групп. Платная система, но есть бесплатный тариф с определенными ограничениями.

Проекты распределяются на доски, которые выглядят очень наглядно. На досках задачи можно распределять по колонкам по принципу доски в канбан: новые задачи, задачи в очереди, задачи в работе, завершенные задачи и так далее.

Атрибуты, как таковые, в данной системе не предусмотрены. Но для присвоения серьезности или приоритета можно использовать цветовые маркеры. На доски добавляются определенные пользователи, которые закрепляются за задачами, где пишут комментарии по ходу выполнения.

Плюсы:
— Freemium-модель.
— Наглядность в ходе выполнения задачи.
— Возможность работы на нескольких досках.
— Интеграция с различными сервисами.
— Система построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии.

Минусы:
— Система построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии. Да, это плюс и минус одновременно. Когда количество баг-репортов измеряется сотнями, смотреть “все на одном экране” становится неудобно.
— Слишком простая и не предназначена для больших команд. Задачи банально не имеют номера, не говоря уже о переводе или установке на свой сервер.

Google Таблицы

Универсальный бесплатный инструмент. Если проект небольшой и в нем не так много баг-репортов, то Google Таблицы подойдут.

Плюсы:
— Бесплатно.
— Полная свобода творчества.

Минусы:
— Нет возможности интеграция с различными программами.
— Нет возможности учитывать время.

________
У каждой баг-трекинговой системы есть свои преимущества и недостатки. Достаточно изучить одну любую систему, чтобы понять принцип работы остальных. Как только вы поймете принцип, то на освоение новой системы у вас будет уходить совсем немного времени.