Привет, Хабр! Меня зовут Кирилл Иванов. Я уже много лет участвую в организации процесса тестирования в Тензоре. У нас есть особенность — мы используем собственные разработки для управления релизами, хранения тестов и трекинга багов.
Эта заметка — рефлексия, взгляд тестировщика изнутри на наши собственные инструменты, которые помогают выживать в сложных процессах с тысячами разработчиков и уверенно держать планку качества на высочайшем уровне. Расскажу о том, как внутренние сервисы успешно заменяют нам популярные рыночные решения: проведу параллели, сделаю сравнения, подчеркну сильные стороны и недостатки.
Дисклеймер: компания не продает продукты для управления разработкой ПО. Цель — поделиться тем, что есть, почерпнуть полезные идеи и опыт из комментариев, взглянуть на себя со стороны: что получается хорошо, а что можно улучшить)
Релизы
Три главных вопроса разработки продукта — что, в каком качестве и в какие сроки получит конечный пользователь? Не удивительно, что в любом инструменте для управления разработкой есть некий объект, соединяющий в себе сроки и наполнение таких "поставок". И у нас такой тоже есть!
Вехи вместо версий: наш аналог Jira Version
В Jira для планирования релизов используют сущность Version. В Saby нам её заменяет «Веха» — удобный контейнер для задач со всем необходимым для управления релизами.
Ключевые особенности наших вех:
Внешне выглядят как карточки документов — всё под рукой.
Список задач вехи доступен без дополнительных отчётов.
Есть полнотекстовый поиск и гибкие фильтры — можно быстро отобрать тикеты по любым комбинациям параметров.
История фильтрации экономит время: не нужно заново настраивать сложные выборки.
С точки зрения тестировщика, инструмент удобный. Всегда знаешь, что с твоими ошибками и в каком они состоянии, какая нагрузка на разработчиков и тестировщиков.
Как устроена структура
Реестр задач вехи представляет собой дерево, верхний уровень которого — тип документа ("Задача", "Ошибка" и другие), а последующие уровни — состояние тикета (открыт, на проверке и т.д.) и управленческая структура команды:
Что это дает нам на практике?
Всегда видно, сколько задач и какого типа находятся на том или ином подразделении и сотруднике для быстрой оценки состояния.
Легко найти "узкие места” — важно для релиз-менеджеров и руководителей направлений, а также и тестировщиков: можно вовремя поднять вопрос о пересмотре планов по задачам и ошибкам в веху.
Можно посмотреть топ в разрезе подразделений с наибольшим количеством задач на них. Кто загружен больше, где возможны задержки:
Особенно актуально это становится по мере приближения к дедлайну, когда видно: команда явно “закопалась” в задачах, переоценила свои возможности, требуется помощь.
Увы, пока в Saby нет фильтрации и сортировки по приоритету задач. Потому что такого понятия как “приоритет” в наших реалиях не существует в принципе. Это может выглядеть немного противоречащим теории тестирования с severity / priority, но для мажорных релизов мы нашли решение:
Создаём специальную веху для блокеров — ошибок, которые частично или полностью парализуют работу продуктов.
Релиз‑менеджеры следят, чтобы такие баги брали в работу как можно быстрее:
Отслеживаем динамику: отчет «Аналитика»
Один из инструментов для отслеживания динамики прироста/убыли задач в вехе — специальный отчет-диаграмма “Аналитика”. Можно построить как по всей вехе (рис.1), так и по отдельному подразделению (рис.2).
Что показывает отчет:
Идеальное выполнение — прямая от даты создания вехи (или за 25 дней до релиза) до даты релиза.
Фактическое выполнение — текущее количество задач в вехе или на исполнителях (при фильтре).
Плановый объём работ — сколько задач нужно закрывать ежедневно, чтобы успеть к релизу.
Завершенные — количество закрытых фаз по документам в вехе.
Аналитика помогает команде оценивать текущее состояние и делать ретроспективу, анализировать причины всплесков и отклонений, учитывать ошибки планирования.
«Лента»: визуализация этапов
Веха — это не просто список задач, а целый документ с регламентом и контрольными точками. Чтобы отслеживать прогресс от старта до релиза, есть функционал «Лента»:
показывает, на каком этапе находится документооборот;
помогает нам убедиться, что процесс идёт по плану
Визуализация прохождения вехи по этапам документооборота
Цифры и масштабируемость
Количество ошибок и задач в вехе — не проблема:
Инструмент хорошо масштабируется и показывает достаточно отзывчивую реакцию при любых выборках.
Что нам нравится в Saby-вехах?
Полностью русскоязычная среда. В отличие от Jira (зарубежного продукта), Saby — изначально отечественный сервис с интерфейсом, документацией и инструкциями на русском языке. Это упрощает работу без необходимости переключаться между языками.
Интуитивно понятный интерфейс. Как и популярные Kaiten с Яндекс Трекером, Saby отличается удобством восприятия. Его структура позволяет детально фильтровать задачи, не перегружая пользователя лишними элементами.
Структурированность. Интерфейс Saby выстроен логично, что помогает быстро ориентироваться в задачах. В отличие от Jira, где для большинства продвинутых функций нужны плагины, базовый функционал Saby покрывает основные сценарии работы без дополнительных настроек.
удобство: всё в одном месте, без лишних отчётов;
гибкость: поиск, фильтры, настройка под команду;
прозрачность: видно нагрузку, динамику;
контроль: контрольные точки и визуализация через «Ленту».
Что мы могли бы улучшить?
Визуализация задач. В Saby пока нет наглядного отображения зависимостей между задачами (доступно у конкурентов).
Инструменты для сложных сценариев. В отличие от Jira с плагинами (например, Advanced Roadmaps и Structure), Saby не предлагает:
специальных полей для связывания блокирующих задач;
механизмов работы с дублями задач.
Это усложняет управление задачами в крупных проектах.
Нам кажется, что Saby-вехи — удобный инструмент для базовых задач по управлению релизами: у него русскоязычный интерфейс и логичная структура.
Управление проектами
Вехи хорошо работают для организации релизов, но что с разработкой нового функционала, компонентов? Для этой цели у нас служат "Проекты". Процесс устроен так, что разработки новых фич и релизы идут как бы параллельно. Проект — классический водопад с идеями, планированием сроков, этапами. Релизы — итерации с установленной периодичностью. Когда проект готов, он сливается в один из ближайших релизов (веху). Тестировщик всегда включен в оба эти процесса: готовит очередной релиз по “регрессу” и участвует в тестировании проекта, функционал которого обычно скрыт под “фичей” и виден только избранным.
Каждый проект включает:
требования и техническую документацию;
планы разработки и тестирования;
срок внедрения решения в продукт (в рамках одной из вех);
задачи и ошибки, которые находит тестирование в новом функционале.
Визуально проект представлен карточкой с ключевыми данными:
краткое описание;
основные участники (в том числе ответственного за качество проекта тестировщика);
объём работ (в человеко‑днях);
срок выполнения.
Есть возможность выделять этапы проекта, чтобы сгруппировать задачи, оценить объем, спланировать сроки:
Мы не теряем ошибки от тестировщиков — они всегда привязаны к соответствующему этапу разработки функционала. Это позволяет четко отслеживать готовность каждого этапа.
На отдельной вкладке представлены участники, которых можно сгруппировать, прописать роли, а в процессе выполнения проекта или по его итогам оценить вклад каждого участника в проект по времени и задачам:
Анализируя плановые и фактические цифры по команде тестирования, мы понимаем, где просчитались, а где попали в цель. Это дает опыт для будущих оценок.
Вкладка "Документы" служит для хранения документации. Это могут быть как отдельные экземпляры файлов, так и ссылки на документы на Saby-диске:
Для тестировщика доступность всей проектной документации в одном месте — хорошее подспорье. После завершения проекта документация остаётся в базе знаний Saby.
Присутствует и лента, как и во всех остальных документах Saby. Здесь можно посмотреть текущий прогресс по проекту, его состояние:
После разработки ТЗ и до начала реализации к проекту привлекается тестирование. На этом этапе тестировщик делает вычитку ТЗ, составляет концептуальный план тестирования с ключевыми моментами и обсуждает свои вопросы по ТЗ с менеджером проекта — Saby сам напомнит об этом ответственному за проект тестировщику, чтобы он всё сделал вовремя:
Можно настроить любой flow для проекта. А поля и внешний вид карточки устанавливает каждый участник под себя:
Встроенный гант помогает ориентироваться в сроках этапов проекта и не упускать момент, когда к этапу пора подключаться тестированию:
Что нам нравится в Saby-проектах?
Встроенные диаграммы. Saby предлагает наглядные диаграммы прямо в системе — это упрощает анализ данных без необходимости выгружать их в сторонние сервисы.
Удобный трекер трудозатрат. Инструмент позволяет четко отслеживать затраты времени на задачи — такой функционал не всегда есть в аналогах «из коробки».
Полное отображение этапов работы. Все стадии проекта видны в едином интерфейсе, что даёт целостное представление о процессе (в Jira, например, одновременно отображается только одна доска).
Рис. Доска в Jira (скрин с оф.сайта) Интегрированный инструмент для работы с документами. В Saby можно управлять документами в рамках проекта без переключения на другие сервисы — это экономит время и снижает фрагментацию данных.
Гибкая настройка процессов. Как и лидеры рынка (Jira, «Я.Трекер», «Кайтен»), Saby позволяет кастомизировать рабочие процессы, поля и статусы, адаптируя систему под нужды команды.
Можно связывать проекты между собой, если один проект является логическим продолжением другого— это позволяет быстро переключаться между ними.
Что мы могли бы улучшить?
Углубленная кастомизация Agile‑досок и привязка к проектам. В проектах Saby доски не являются нативной частью. Они есть, но пока живут своей отдельной жизнью, и закидывать задачи на доску приходится вручную. В итоге применяются они редко.
Рис. Доска в Яндекс Трекер (скрин с оф.сайта)
Как мы храним и прогоняем тесты: система «Кайдзен»
Когда речь заходит о подготовке релизов, критически важно не только что тестировать, но и как это организовано. В Saby за это отвечает система «Кайдзен» — она состоит из двух взаимосвязанных блоков: «Зоны ответственности» и «Проверки».
Зоны ответственности: карта тестового покрытия
Это наша «карта мира» — декомпозиция всех продуктов от верхнего уровня до мельчайших деталей.
Что дает:
четкое разделение зон тестирования;
привязку тестов к конкретным участкам функционала;
назначение ответственных тестировщиков за каждый участок.
Реестр зон ответственности покрывает все продукты
Каждый участок хранит в себе информацию о связанных с его функционалом тестах (и тестировщиках, ответственных за эти тесты):
Проверки
В некотором приближении, этот компонент можно сравнить с "прогонами" ("тест-раны") в популярных TMS.
Проверка — такой документ-инструкция для функционального тестировщика, что и как проверить. Он помогает команде оценить прогресс проверки функционала, состояние функционала и объем найденных дефектов.
Когда команда начинает тестировать версию, от зоны ответственности создается "Проверка" в соответствующую веху. Проверка вбирает в себя все тесты зоны с учетом иерархии: вложенные зоны становятся разделами, а тесты в них — пунктами проверки со статусом по умолчанию "Не тестировался":
Внутри тесты, как и в любой TMS, — это пара "шаг - ожидаемый результат":
Все вполне красиво и удобно, есть drag'n'drop для степов, можно хранить скрины, поясняющие шаги и отмечать отдельные шаги, как пройденные. Есть поле для указания планового времени. Это хорошо для оценки трудозатрат тестирования.
В Тензоре у каждого тест-кейса — свой ответственный тестировщик. Мы всегда можем оценить нагрузку на человека — ни один тест-кейс не будет забыт.
Функционал окна позволяет создавать ошибки сразу при прохождении теста (пункта проверки):
Заведенные ошибки в дальнейшем можно посмотреть как в этом пункте проверки на отдельной вкладке, так и от всей проверки:
Каждый пункт в "Проверке" находится в одном из состояний, которое выбирается из меню:
При этом проверка в режиме реального времени даёт возможность отслеживать текущее состояние, что является очень классной опцией для QA-лида:
В пылу подготовки релиза удобный и простой способ контроля — ценная опция.
По нашим правилам за неделю до релиза все тесты по продукту должны быть пройдены, оставшееся время — на добивание и ретест ошибок, санити и регресс.
Состояния всех проверок, как ручейки в реку, стекаются в веху. Вкладка "Проверки" вехи наглядно покажет прогресс тестирования по всему включенному в релиз функционалу — удобно для быстрой оценки готовности версии:
Интеграция с автотестами
В условиях шести мажорных релизов, пяти минорных и десятков хотфикс-версий в год критичные для клиента функциональности стремимся проверять автотестами. Большая часть — end-to-end-тесты (web, mobile), повторяющие действия пользователя. Дополняет его api-тестирование.
По каждой зоне ответственности есть минимум две сборки автотестов: smoke, acceptance и, возможно, отдельные сборки для прочих функциональных тестов.
Все автотесты в сборках связаны с пунктами проверок, что позволяет автоматически устанавливать их состояния.
Jenkins не предоставляет удобного инструмента для быстрого просмотра/понимания проблем. С растущим количеством выполняемых (а значит и падающих) автоматических тестов это становится проблемой. Для ее решения используем очередную внутреннюю разработку — JenkinsControl. Этот интерфейс активно применяется автоматизаторами, DevOps-инженерами и функциональными тестировщиками: он позволяет наглядно отслеживать текущую ситуацию о состоянии тестов по нашим продуктам, разбирать и подписывать упавшие тесты:
Специальный отчет, который строится от проверки, позволяет увидеть как покрытие приемочными тестами, так и общее покрытие по функциональным тестам:
Благодаря отчету команда функционального тестирования понимает фронт работ для постановки задач автоматизаторам.
Что нам нравится в Saby-кайдзен?
Логичная структура хранения тестов. В системе два ключевых блока: зоны ответственности и проверки. Это позволяет чётко разделять эталонные сценарии и текущие — никакой путаницы.
Все проверки для регресса в одном месте. Не требуется отбирать тест-кейсы фильтром, что исключает потерю сценариев для регресса и отчетов.
Есть синхронизация тестов в обе стороны между проверками и кайдзен-зонами.
Удобная детализация сценариев. Каждый сценарий разбит на разделы: шапка с метаданными (название, сроки, ответственный), описание и пошаговая инструкция.
Гибкая фильтрация и связи. Отдельные вкладки для сортировки проверок по людям и зонам, интеграция с досками, планами работ и вехами.
Всё под рукой. Встроенный чат для обсуждений, возможность прикреплять документы, дефекты и задачи прямо к проверкам;
Автоматизация статуса. Если сценарий связан с автотестом через JenkinsControl, статус проверки обновляется автоматически — не нужно вручную отслеживать изменения.
Наглядная аналитика. Встроенные диаграммы и отчеты показывают:
покрытие автотестами;
текущие ошибки и задачи;
загрузку сотрудников;
время выполнения задач.
В отличие от Jira, где для удобного пользования функционалом нужны плагины (T4J, Xray), или Яндекс Трекера, требующего интеграции с TMS, у нас полный набор инструментов «из коробки».
Что мы могли бы улучшить?
Интеграция со сторонними инструментами. В отличие от Jira (интеграция с GitHub, Slack), Кайтен (подключение к TestRail, Zephyr) и Яндекс Трекера (API для GitHub, BitBucket), Saby не поддерживает плагины. Добавление таких возможностей расширит сценарии использования. Но, наверное, это не является актуальным для продукта без продаж вовне.
Автоматизация рутинных операций. В Кайтен можно настраивать автоматические действия при смене статуса карточки, в Яндекс Трекере — использовать триггеры и автодействия. В Saby пока нет гибких правил для:
назначения исполнителей;
отправки уведомлений;
изменения параметров задач.
Углубленная аналитика и отчетность. Jira с плагинами предлагает продвинутую аналитику, а в Saby отчёты ограничены встроенными диаграммами. Добавление настраиваемых дашбордов повысит удобство для менеджеров.
Интуитивность для нетехнических пользователей. Кайтен славится простым интерфейсом для команд без IT‑бэкграунда. Saby мог бы немного упростить навигацию.
Ошибки и задачи
Самое близкое и родное сердцу любого тестировщика — баг-репорт или по-нашему просто “ошибка”. Так как в Saby почти все является электронным документом,
ошибки — не исключение. Это отлично ложится на жизненный цикл баг-репорта, и мы можем гибко управлять движением бага так, как нужно нам.
Жизненный цикл
Если вы работали с Jira, то в Saby сразу почувствуете себя как дома — процесс обработки ошибок тут устроен очень похоже. Никаких сюрпризов: всё просто и по делу.
Базовые этапы:
Кто‑то находит баг и заводит тикет.
Если ошибка по обращению клиента — ответственный за зону кайдзен тестировщик проводит дополнительный анализ по приоритету решения проблемы.
Разработчик чинит.
Тестировщик проверяет исправление.
Если всё хорошо, закрываем баг. Если что-то не так, отправляем на доработку.
Регламент “Ошибка”
Здесь мы вполне совместимы с устоявшимися стандартами — сюрпризов для новичков в компании быть не должно.
Как это связано со сборкой
Жизненный цикл ошибки крепко привязан к сборке версий:
После исправления разработчик переводит баг в статус «Ожидание доброски кода». Тут система делает своё дело: заливает изменения в нужные ветки и прогоняет тесты.
Если всё ок — статус меняется на «Ожидание сборки сервиса». Собирается дистрибутив.
Обновляется стенд.
Как только дистрибутив попал на тестовый стенд, баг автоматически переходит к тестировщику на «Проверку». Дальше два варианта: закрываем или возвращаем в работу.
Этапы прохождения ошибки
Фишки, которые делают жизнь проще:
Дублирующие баги. Связали несколько тикетов? Когда основной баг доберётся до тестового стенда, дубли автоматически пойдут на проверку.
Этапы прохождения ошибки-дубля Настройка под себя. Этапы и переходы можно гибко подстраивать под конкретные задачи. Например:
Двойная проверка. Мы не ограничиваемся одним тестировщиком:
ответственный за функционал смотрит баг «в родном» контексте;
автор бага проверяет, как проблема проявляется в других местах.
Проверка смежных зон. Если нужно, подключаем нескольких тестировщиков — так не пропустим баги на стыке модулей.
Передача ошибки смежным группам тестирования Синхронизация с продакшеном. Если баг пришёл от технолога или техподдержки, этап проверки наступит только после обновления рабочей среды (автор получает репорт одновременно с обновлением).
В итоге получаем процесс, который:
не даёт забыть про важные шаги;
снижает влияние человеческого фактора,
обеспечивает проверку со всех сторон.
Все для того, чтобы баги ловились надёжно, а разработчики и тестировщики не тратили время на рутину.
Карточка ошибки
Карточка ошибки в Saby — штука удобная: все нужные поля под рукой, ничего лишнего.
Можно сразу запустить баг в работу, а можно отложить и вернуться позже — как удобнее. Можно указать веху, место обнаружения ошибки (приложение), серьезность, и стадию, на которой обнаружена ошибка:
Наша свежая фича: поле "На бою с… " — показывает, как давно ошибка мешает нашим пользователям. Работает автоматически:
если баг найден в продакшене — подставляется текущая дата;
если на тестовом стенде — дата вехи, в которую включён баг.
Очень выручает при подготовке отчётов по ошибкам в проде: сразу видно, какие баги «засиделись» и требуют срочного внимания.
Автосоздание багов: прощай, рутина!
Чтобы тестировщики не тратили время на ручное заполнение карточек, у нас есть крутой инструмент: Wasaby Developer Tool — наш внутренний плагин для отладки Saby‑приложений. С ним всё просто:
нашли баг — нажали кнопку прямо на странице;
плагин сам создает баг‑репорт;
в карточку автоматически подставляются:
версия сервиса/платформы;
тестовый стенд;
скриншот;
логи.
В итоге:
меньше рутины — больше времени на поиск и анализ багов;
минимум ошибок из‑за ручного ввода;
вся важная информация сразу в карточке — ничего не потеряется.
Аналогичное автосоздание ошибки доступно из упавшего автотеста в JenkinsControl: можно сформировать баг‑репорт по упавшему тесту без лишних телодвижений. При этом даже будут добавлены шаги воспроизведения.
Инструменты заточены так, чтобы тестировщики сфокусировались на главном, а не на заполнении форм.
Скрины и вложения: просто, быстро, без лишних движений
Добавлять вложения в карточку ошибки — одно удовольствие. Есть сразу три удобных способа:
через меню;
перетаскиванием в нужное поле;
из буфера обмена — всего один клик.
Наш скриншотер — маленький помощник с большими возможностями
В систему встроен собственный инструмент для создания скриншотов. И это не просто «сделать снимок» — у него целый набор фишек:
скрины со скроллом;
видео на фоне скрина — голосовые комментарии, клики, пометки;
одновременная запись экрана и камеры;
запись видео в форматах GIF и MP4;
встроенный редактор — можно что‑то подправить или выделить прямо на месте;
интеграция в систему — никаких лишних переходов и окошек.
Что ещё приятно:
Можно редактировать скриншоты и видео уже после загрузки в карточку ошибки. Не идеально получилось с первого раза? Не беда — поправим!
Нет головной боли с хранением файлов. Благодаря интеграции с Saby.Диском все вложения надёжно сохраняются — вам не нужно думать, куда их складывать и как не потерять.
Что нам нравится в Saby-ошибках
В работе с дефектами у нас есть комфорт и забота о сотрудниках тестирования:
Удобство регистрации дефектов: В Saby есть встроенный инструмент для создания скриншотов и записи логов, что значительно упрощает процесс регистрации ошибок. Это отличает его от аналогов, где такие функции либо отсутствуют, либо требуют дополнительных настроек.
Интеграция с тестовыми стендами: Saby позволяет автоматически создавать дефекты не только из системы TMS, но и прямо из тестовых стендов, что экономит время и упрощает работу тестировщиков.
Четкая категоризация ошибок: В системе предусмотрено четкое разделение ошибок по категориям (функциональные, ошибки производительности, безопасности и проектирования), что упрощает их обработку и решение.
Фиксированное флоу: Устоявшийся процесс работы с дефектами в Saby позволяет легко ориентироваться в системе и не требует сложных настроек.
Что можно улучшить
Несмотря на множество плюсов, мы понимаем, что в сравнении с аналогами могли бы подрасти:
Расширение интеграционных возможностей: В отличие от Jira и Яндекс Трекера, Saby не имеет глубокой интеграции с другими системами и сервисами. Но для нас пока это не актуально.
Гибкость настройки приоритетов: Подобно Яндекс Трекеру, было бы полезно иметь более гибкую настройку приоритетов для задач. Это позволило бы более точно управлять очередностью выполнения работ.
Поддержка сложных workflow: Как Jira, Saby мог бы предложить более гибкую настройку рабочих процессов, что позволило бы адаптировать систему под различные нужды команд.
Визуализация задач: Подобно Kaiten, добавление более продвинутых визуальных инструментов для отслеживания задач могло бы сделать работу с системой еще удобнее и эффективнее.
Как мы анализируем качество релизов: от автоотчетов до ежемесячных срезов
После крупных релизов команда QA не просто переводит дух — мы внимательно разбираем, как всё прошло. Главные вопросы:
сколько багов нашли на этапе тестирования;
какие ошибки всё‑таки добрались до клиентов;
насколько оперативно команды справлялись с задачами.
Для этого у нас налажена система отчётов — и автоматических, и ручных.
Автоотчеты: мгновенный снимок ситуации
Сразу после обновления система сама формирует отчёт по всем проблемным точкам. В него попадают:
аварии (они идут отдельным документом по специальному регламенту);
ошибки, с которыми столкнулись клиенты;
проблемы с производительностью и нагрузкой — всё за первые три дня после релиза.
Что даёт такой отчёт:
помогает понять, пропустила ли команда тестирования критический баг;
показывает, нарушилась ли работа у клиентов;
выявляет, связаны ли проблемы с новой версией;
даёт полную картину по всем участкам — видно, где «болевые точки».
Ежемесячные срезы: стратегический взгляд
В конце каждого месяца QA‑сектор проводит глубокий анализ состояния продуктов. Готовится два типа документов:
Сводный файл — общая картина по всем участкам.
Индивидуальные файлы для каждого продуктового направления — в них собраны все серьёзные ошибки:
функциональные (что‑то не работает как надо);
нефункциональные (проблемы с производительностью, удобством и т. п.).
Руководители видят реальное количество проблем и могут грамотно спланировать работы на следующий месяц. Команды получают чёткое понимание, на чём фокусироваться в первую очередь. Мы выстраиваем долгосрочную стратегию улучшения качества — не просто «чиним баги», а устраняем системные недочёты:
В итоге:
автоматические отчёты дают оперативную обратную связь — можно быстро реагировать на проблемы;
месячные срезы обеспечивают стратегическое видение — помогаем продуктам становиться надёжнее с каждым релизом.
Всё это — часть нашей философии: не просто фиксировать ошибки, а постоянно улучшать процессы и качество продукта.
Отчеты для QA-лида
Чтобы QA‑лид мог держать руку на пульсе, у нас есть несколько ключевых отчетов. Они показывают не просто «цифры», а реальную картину работы команды — от планирования до финального релиза.
1. «Динамика поступления задач»
Этот отчёт — своего рода «кардиограмма» подготовки к релизу. С его помощью лид видит:
как команда подходила к выпуску версии;
сколько проблем накопилось к дедлайнам;
было ли у тестировщиков «время тишины» — периоды, когда можно было спокойно перепроверить уже найденные баги:
Поступление задач в период подготовки релиза
Это помогает тестированию синхронизироваться с командой разработки — смотрим динамику поступления задач в разработку, в тестирование, соотносим это с дедлайнами и делаем выводы на будущее.
2. «Скорость обработки задач»
Тут всё про эффективность: отчёт показывает, сколько времени уходило на разбор каждой задачи. Это помогает:
выявить «узкие места» в процессах;
понять, где команда работала оперативно, а где возникали задержки;
спланировать нагрузку на будущие релизы.
Скорость обработки задач в период подготовки релиза 25.5100
Благодаря этим данным мы понимаем, что при подготовке версии не было зависших задач на тестировании. Также мы понимаем, что не было ситуации, когда к проверке важных задач приступили поздно, из-за чего пришлось править ошибки в последний момент. Если зависшие задачи случаются, то обсуждаем причины этого с командой.
3. Ручные отчеты от тестировщиков
Помимо автоматических сводок, каждый тестировщик может сформировать два важных отчёта вручную:
Отчёт о перенесенных ошибках — сюда попадают баги, которые нашли при проверке версии, но решили исправить позже. Это помогает:
не потерять из виду «отложенные» проблемы;
спланировать работу на следующие релизы;
оценить, насколько оправданным было решение о переносе.
Мы стараемся заранее показать отчет о перенесенных из вехи ошибках менеджеру и ответственному разработчику. Так есть шанс вернуть в веху критическую для пользователей доработку или ошибку, которая обязательно бы «выстрелила» на проде.
Отчет об ошибках релиза — в нём только баги, которые добрались до продакшена за выбранный период. Это «зеркало» качества релиза:
видно, какие проблемы пропустили на этапе тестирования;
можно проанализировать, почему они возникли;
есть база для обсуждения улучшений с разработчиками.
Отчет помогает получать данные для глубокого анализа: какого типа ошибки я обычно пропускаю? Как мне улучшить свою работу? Если причина не во мне, что я могу обсудить с коллегами из других отделов, чтобы улучшить процессы и предотвратить ситуацию в будущем? В общем, философия «кайдзен» тут проявляется в полный рост.
Что нам нравится в отчетах Saby
Есть всё необходимое для наглядного контроля процессов. Как и в топовых инструментах вроде Jira, Яндекс Трекера и Kaiten, здесь есть встроенные отчёты и графики. Но есть и свои козыри:
Универсальность отчётов. В Saby можно строить отчёты не только по проектам (как в Jira или Яндекс Трекере), но и по сотрудникам, проверкам и другим объектам. Это даёт более полную картину работы команды.
Гибкость настройки. Как и Kaiten, Saby позволяет легко адаптировать отчёты под свои нужды.
Удобный экспорт. Как и Kaiten, Saby даёт возможность выгружать данные в файлы — это удобно для дальнейшей работы в Excel или других инструментах.
Что мы могли бы улучшить
Дашборды. В Jira и Яндекс Трекере дашборды — это полноценные рабочие панели с метриками (например, MTTR в Jira) и визуальными элементами. В Saby было бы здорово расширить возможности дашбордов, добавив больше готовых виджетов и метрик.
Рис. Дашборд в Jira (взято с оф.сайта)
Интеграции. Jira умеет «дружить» с Confluence и CI/CD‑системами, а Яндекс Трекер — с Yandex DataLens для глубокой аналитики. Saby в будущем мог бы предложить аналогичные интеграции, чтобы пользователи не переключались между сервисами. Но внутри нашей экосистемы, без выхода на рынок, это не актуально.
Диаграммы Ганта. В Saby реализованы встроенные отчеты и графики для проектов, сотрудников, проверок и других объектов, но нет такого разнообразия как в Jira и Kaiten.
Заключение
За годы развития мы создали полноценную экосистему для тестирования, которая позволяет:
Эффективно планировать релизы через систему вех с наглядной визуализацией прогресса.
Управлять качеством через комплексный подход к тестированию с помощью системы «Кайдзен».
Отслеживать ошибки в единой системе с чётким флоу и автоматизацией рутинных процессов.
Анализировать результаты через мощную систему отчётов и метрик.
Понимая, что далеки от совершенства, мы не опускаем руки и день за днем стараемся развивать свои инструменты, процессы, учиться на ошибках. Делаем ставку на создание удобной для работы и вбирающей в себя максимально широкий функционал среды для тестирования и обеспечения качества.
На наш взгляд, во многом это удается: экосистема Saby дает тестировщику все возможности для эффективной работы: она логична, хорошо структурирована и оптимизирована, обладает большими возможностями без необходимости интеграции со сторонними инструментами, поэтому новичку её бояться точно не нужно.
Есть и пространство для улучшений: аналоги обладают в целом более гибкими подходами к управлению разработкой, у них немного ниже порог входа, чуть более дружелюбный и отзывчивый интерфейс и лучше визуализация процессов.
Будем рады комментариям, мнениям, и вашим историям, и спасибо за внимание :-)
