Оптимизация процесса анализа смоуктестов

Добрый день.

Долго выбирал разел, надеюсь, что не ошибся :)

Ситуация такова: на меня повесили новую активити: на ночь запускать автотесты и утром делать их анализ. объем тестирования - примерно 150 Юзкейсов, на то, чтобы просмотреть один из них требуется от 1 до 20 минут(суть в выявлении багов, тоесть необходимо найти первопричину ошибки, просмотреть, ошибка ли это имплементации, или же автотула тупит\недописана или же отвалилось из-за перфоманса). Все бы ничего, но он меня требуют предоставить отчет в течении часа-двух. В отчет необязательно должны входить заведенные на BTS багрепорты по найденым проблемам, хотя бы корректная формулировка проблемы и указать принадлежность к сценарию определенному. Затем я должен проработать все найденные проблемы и если необходимо завести багрепорты.
Проблема в том, что я не успеваю за час обработать данные. Вторая проблема в том, что у меня уходит весь день почти на анализ дефектов и заведение багрепортов.

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

У меня родились пока такие идеи:
1. Если юзкейс(он же сценарий - кусок функционала грубо говоря) занимаем много времени на вторичный анализ - отдавать его какому-нибудь инженеру с проекта, чтобы он прогнал этот кусок еще раз и занялся анализом самостоятельно. Таким образом на вторичный анализ время уменьшится.
2. Разбить весь скоуп на две части по приоритетам: те, которые имеют высший приоритет(покрывают ключевой фугкционал) должны быть проанализированы утром, в течении часа, а остальные сценарии могут быть протестированы уже к обеду или позже. Таким образом время на первичный анализ увеличится.

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

Если есть какие-то идеи, предложения, прошу, выкладывайте, буду очень благодарен :)

Мы занимаемся этим уже не первый год: и логи смотрим и отчет отсылаем.
Что могу посоветовать:
1. Сделать максимально удобный лог, группировать сообщения по папкам, выводить логичные сообщения и т.д.(подобное логирование очень упрощает разбор ошибок)
2. Убедить руководство, что полные результаты за час вы дать не сможете никак(технически нереально), тут есть пара выходов:
- высылать через час отчет с поверхносными результатами(например сколько тестов прошло успешно и сколько провалилось, а подробности уже когда будут готовы)
- выложить отчет на общий доступ чтобы руководство в любой момент могло смотреть текущую ситуацию по разбору логов, но тут нельзя будет филонить, придется заполнять отчет сразу же по мере обнаружения проблемы.

>>> Вопрос еще стоит в том, как наиболее эффективно использовать человеческие ресурсы в такой ситуации.
У вас одна версия продукта? Вы можете разбить функционал на части и к каждой части прикрепить ответственного, который и будет разбирать по ней лог, дорабатывать и т.д.

Спасибо за советы.

Логи ведутся вполне читабельными(точнее у нас репорт в html с ссылками, скринами), меня просили фидбэк написать, что я бы хотел там видеть, но пока ничего в голову не пришло :)
Руководство запуталось в терминологии, они считают смоуктестом полный анализ резуьтатов с выявлением руткозов всех найденых проблем и последующим фиксированием багов в виде багрепортов на BTS, на что у меня уходит два дня с таким огромным скоупом. Сейчас отбиваюсь и пытаюсь пояснить, что смоук тестом ищут шоустоперы и критичные баги, а не все подряд, и что я один с такими объемами работ никак не справлюсь, пока идeт на встречу, а там будем смотреть.

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

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

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

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

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