Инструмент “Дефекты” — это внутреннее техническое решение, разработанное для упрощения взаимодействия команды разработки с командой качества (QA) при помощи отчетов об ошибках (Bug reports).
Ключевая идея инструмента — провести реформу процесса работы с дефектами, превратив это из произвольных комментариев в полноценный структурированный комплекс.
-
Уменьшить время Time To Market. Хотим выпускать задачи в релиз быстрее.
-
Улучшить контроль. Исключить любые “забыл поправить” или “ой, потеряли”.
-
Повысить эффективность QA-отдела. Много времени уходит на описание проблемы, новых членов команды нужно учить описывать с нуля.
Раньше, когда наш отдел тестирования был совсем еще молод, многие процессы были выстроены не так хорошо, как могли. Все обнаруженные дефекты и улучшения мы выписывали в комментарии к задачам, создавали Excel-документы, общались в личных сообщениях или делали записи на листочках. Со временем в этом процессе мы находили множество недостатков, начиная от тех, что с такими “дефектами” очень трудно работать, невозможно быстро понять приоритет дефекта, заканчивая отсутствием общей структуры дефектов и статистикой ошибок по проектам. Поэтому мы начали искать требуемое нам решение.
Все задачи компании ведутся в таск-трекере Planfix, в котором из коробки не было необходимых нам возможностей. Мы изучили сторонние готовые решения, такие как Jira, YouTrack и Trello, но требуемый инструмент должен быть интегрирован в Planfix или реализован непосредственно в нем. Помимо этого, инструмент должен обладать значительными возможностями кастомизации, чтобы мы могли адаптировать его под свои бизнес-процессы. Готовых и полностью подходящих решений для нас не оказалось, поэтому мы реализовали инструмент с необходимыми нам возможностями прямо в нашем Planfix.
Итоговый инструмент включает в себя следующее:
-
Структура. Мы разработали полностью индивидуальную форму заполнения отчета об ошибках на базе таск-трекера Planfix. Тестировщик фиксирует полную информацию об ошибке и передает ее на исправление. Форма заполнения дефекта включает в себя:
- название,
- окружение, в котором подтвердилась ошибка,
- предусловие, требующееся для повторения ошибки,
- шаги воспроизведения,
- ожидаемый и фактический результат,
- серьезность,
- приоритет дефекта.
Таким образом, разработчик всегда имеет полную информацию об ошибке, что позволяет сократить время на исправление дефекта и минимизировать запросы уточняющей информации от QA.
-
Бэклог. Здесь аккумулируются дефекты и улучшения, которые, как и другие, ожидают реализации, но имеют самый низкий приоритет и не относятся к конкретной задаче.
-
Отчеты. Мы разработали и автоматизировали создание собственного отчета, который предоставляет нам статистику по всем известным ошибкам на каждом проекте и который позволяет не пропускать важные дефекты.
-
Приоритезация. Критичность дефектов может быть разной, поэтому важно их приоритезировать. Для этих целей при заполнении дефекта мы внедрили выбор серьезности и приоритета дефекта. Кроме того, мы сформулировали рамочный регламент, определяющий формулу определения серьезности и приоритета дефекта. На конкретном проекте этот регламент может быть скорректирован согласно ожиданиям заказчика, функционалу и направленности проекта. Так мы исправляем в первую очередь самые критичные ошибки, сильно влияющие на бизнес.
-
Автоматизация. Инструмент предназначен для всей команды на проекте, и чтобы каждый участник всегда имел актуальную информацию о состоянии дефекта, мы внедрили ряд статусов, автоматизировав переходы между ними. Только что созданный дефект передается на исправление, а исправленный дефект — на тестирование. Так мы добились увеличения скорости тестирования, решения ошибок и полностью исключили “зависание” проблемы в промежуточных статусах.
После внедрения разработанного инструмента наш процесс выглядит следующим образом:
- На начальном этапе менеджер или тимлид проекта формирует задачу разработчику, в которой детально описаны требования к выполнению задачи, указаны ссылки на документацию, макеты, изображения, видеоматериалы и прочее.
- Выполнив задачу, разработчик переводит ее в статус “Ожидает тестирование”. В этот момент исполнителем задачи автоматически назначается закрепленный за проектом тестировщик.
- В ходе тестирования, тестировщик прикрепляет дефекты к задаче и возвращает ее на доработку.
- После их исправления, дефекты проходят повторное тестирование, помечаются исправленными, а задача переходит в ожидание релиза.
Стоит отметить, что это не конец тестирования — процесс повторится после того, как задача попадет в продакшен. Тестировщик повторно проверит задачу и исправленные ошибки. Все это позволяет нам поддерживать высокое качество выпускаемых продуктов и избежать критических ошибок в продакшене.
-
Максимальная информативность. Прочитав лишь одну строчку в названии дефекта, важно понимать: что сломалось, где и при каких обстоятельствах. Помимо этого, требуется сразу понимать серьезность и приоритет ошибки. Слишком много информации для короткого названия задачи. Решая эту задачу, мы внедрили приоритезацию дефектов в виде пиктограммы, которая указывает на очередность решения дефекта, исходя из его влияния на бизнес, а путем внутренних исследований мы вывели правила написания названия дефекта. Так мы получили информативный заголовок, состоящий всего из одной строки и иконки.
-
Отсутствие готового решения. Проведя большую работу по анализу существующих инструментов и предоставляемых ими возможностей, мы осознали, что подходящего нам решения нет. Лучше изучив возможности уже используемого нами таск-трекера, просмотрев примеры решения разных задач на его основе, нам удалось внедрить желаемый инструмент, используя продвинутые возможности Planfix по управлению процессами и их автоматизации, а также по программированию собственной логики, которая позволила нам реализовать сквозную нумерацию дефектов по всем проектам в таск-трекере.
-
Быстрый старт. При создании подобного инструмента легко добиться ситуации, когда логика работы и организация процесса будет понятна только тем, кто принимал участие в разработке инструмента. Для нас это было недопустимо — новый разработчик не должен тратить много времени на ознакомление и понимание логики. Для решения этого вопроса мы изначально делали инструмент таким, чтобы он был интуитивно понятен каждому. Дополнительно мы подготовили презентацию того, как работает механизм, для чего он нужен, раскрыли процесс работы со стороны разработчиков, тестировщиков и менеджеров. По ходу возникновения вопросов и предложений мы вносили корректировки в процесс, и в результате добились того, чего хотели — после небольшой ознакомительной презентации инструмент понятен всем участникам процесса разработки.
