Контроль за процессом тестирования в TrackStudio

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

Процесс тестирования примерно таков:

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

Поначалу мы вели учёт в одном файле MS Excel. Плюсы: простота организации (сделали файл и всё), удобство создания отчётов для заказчика (фильтруем по статусу и копируем табличку в письмо). Минусы: сложность одновременной работы с файлом нескольких человек (в итоге получилось так, что все докладывали контролёру о всех изменениях статуса, а он вносил эту информацию в файл), отсутствие истории (кто что когда делал).

И вот примерно месяц тому назад мы наконец-то перенесли контроль процесса тестирования в TrackStudio. Это позволило устранить оба минуса (сложность одновременной работы и забывание истории), сохранив при этом простоту генерации отчётов (а может быть даже упростив).

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

Здесь всё достаточно очевидно, кроме, быть может, жёлтых промежуточных состояний. Смысл их заключается в том, что это точки, где происходит передача работы от одного человека к другому -- см. выше описание процесса. Жёлтое состояние нестабильное, оно означает, что предыдущий участник процесса уже работу сдал, а новый ещё не принял. Это состояние требует срочного реагирования и перехода в следующее состояние. Например, когда "контролёр" принимает новый релиз, он отдаёт его системному администратору, переводя задачу в состояние "На установку". Это сигнал -- системный администратор должен принять работу. Когда он переводит задачу в состояние "Установка", значит он принял работу. Передача установленной системы тестировщику происходит при посредничестве контролёра, из-за этого на этом участке имеется два нестабильных жёлтых состояния.

Настроенный в TrackStudio процесс выглядит так:

А текущее состояние дел отображается примерно так:

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

P.S. Поначалу мы хотели ещё сильнее автоматизировать процесс, так чтобы вообще исключить контролёра из процесса. Сообщение о готовности новой сборки приходит во входящий почтовый ящик TrackStudio, она анализирует его и самостоятельно создаёт задание на установку. После того, как установка выполнена, TrackStudio опять таки сама по заложенному в неё алгоритму выбирает тестировщика (например, того, на ком меньше всего назначенных заданий) и создаёт задание на тестирование. Сама отправляет баг-репорт или отчёт о завершении тестирования. Но после некоторого размышления отказались от этих идеалистических воззрений. Автоматическая обработка сообщения о поступлении новой сборки требует, чтобы релиз-менеджеры придерживались определённых правил при написании таких писем. Но если учесть, что они вообще стараются вместо написания письма сообщить об этом по телефону, такие нововведения вряд ли вызывали бы у них прилив энтузиазма. Для автоматического выбора тестировщика, которому нужно передать сборку на тестирование, не удалось придумать адекватный алгоритм. А после всего этого отправка баг-репортов и отчётов о тестировании уже потеряла смысл как совсем несущественная часть, от автоматизации которой выгода практически нулевая.