Коллеги, кто какими метриками в тестировании пользуется, как их рассчитывает? Можете поделиться? Спасибо

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

Наверное, имеет смысл добавить. Предлагаю желающим высказаться, предложить те или иные метрики. Я постараюсь все это собрать и опубликовать в блоге (вот сочинил себе блог:) http://insectfinder.blogspot.com)

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

Работы в системе управления работами имеют флаги: Проект, Направление деятельности, Тип работы, Приоритетность + есть еще принятые шаблоны сообщений, позволяющие облегчить контекстный поиск.

В настоящее время метрика "состояние текущего (рекомендованного) релиза" определяется следующим образом:
- ночной прогон автоматических тестов
- анализ всех падений
- если некритично - состояние принимается удовлетворительным
и
метрика "состояние кандидат-релиза"
- ночной прогон автоматических тестов
- анализ всех падений
- тенденция к уменьшению ошибок
- ошибки некритичные (есть обходные пути, например, застарелые ошибки, ошибки usability ...)

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

Спасибо, Алексей. Вы не правильно меня поняли :). Я, конечно, не жду благодарности. Ну право слово, все мы бываем воспрошающими и бываем отвечающими. Я интересовался, решена ли проблема? Предложенные варианты удовлетворили топикстартера.

Но все равно, приятно получить "muchas gracias" :)

Никому не интересно? Или банальные вещи?

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

Может просто сохранить в csv формате?

tab15, совершенно прав. Проще сохранить в csv. Хотя нет никакого труда сохранить в ЛЮБОМ нужном Вам формате. Для этого нужно обратится к Excel как COM_объекту

// Excel - сохранить как----------------------------------------------------------------------------
// тип файла, если 1 - в формате "xls"
//                 6 - в формате "csv"
function SaveAs(aFileName : String; aFileType : Integer = 1) : boolean;
var
  vMsExcel : OleVariant;
begin
  _FileDelete(aFileName);
  vMsExcel := _OleObjectCreate();
  // сохраянем книгу
  vMsExcel.Workbooks.Item[1].SaveAs(aFileName, aFileType);
  vMsExcel.Quit();
  vMsExcel := nil;
  // убиваем процесс
  while Sys.WaitProcess('EXCEL').Exists do
    Sys.Process('EXCEL').Terminate();
  // проверяем, существует ли сохраняемый файл; это и будет проверкой, что данная функция отработала нормально
  result := _FileExists(aFileName);
end;

или

// Excel - сохранить как...
// тип файла, если 1 - в формате xls, 6 - в csv
function ExcelSaveAs(aFileName : String; aFileType : Integer = 1) : boolean;
var
  vMsExcel : OleVAriant;
  p1       : OleVAriant;
begin
  if aqFile.Exists(aFileName) then
    aqFile.Delete(aFileName);
  Delay(2000);  
  // ожидание открытия окна MSExcel
  p1 := Sys.WaitProcess('EXCEL', 120000, -1);
  Delay(2000); // тут уж ничего неподелаешь ... непонятные тормоза независящие от процесса  
  if not (p1.Window('XLMAIN', '*').Window('XLDESK').WaitWindow('EXCEL7', '*', 1, 120000).Exists) then
  begin
    Log.Error('Окно Excel не открылось. Тест продолжен не будет');
    if Sys.WaitProcess('EXCEL').Exists then
      p1.Terminate();
      CloseProcess;  
    Runner.Stop(true);
  end;
  p1.Window('XLMAIN', '*').Minimize(); 
  Delay(5000);
  vMsExcel := Sys.OleObject('Excel.Application');
  vMsExcel.DisplayAlerts := False;
  vMsExcel.Workbooks.Item[1].SaveAs(aFileName, aFileType);
  vMsExcel.Displayalerts := 0; // типа отключить встроенные предупреждения Excel'я
  vMsExcel.Quit();
  vMsExcel := nil;
  
  while Sys.WaitProcess('EXCEL').Exists do
    Sys.Process('EXCEL').Terminate();
    
  if aqFile.Exists(aFileName) then
  begin
    Log.Message('Файл: ' + aFileName + ' - успешно сохранен.');
    result := true
  end else
  begin
    Log.Error('Файл: ' + aFileName + ' - не сохранен.');
    result := false;
  end;
end;

да то, что автоматизированное тестироване это несколько иная -параллельная вселенная- (для меня)
отличная от ручного тестирования.

суть не меняется, но коррективы и детали внести надобно)

А в чем параллелность?

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

RUP?Маловато данных для анализа ситуации. Как организован процесс разработки и конкретно тестирования? Есть ли требования и специальные люди которые ими занимаются? Какие ресурсы имеются у тестирования: люди, навыки? Какая цель ставится перед командой?

Не, никакой не RUP. Водопад скорее, но такой неклассический, что-то от agile, что-то от других.
Процесс организован примерно так:
есть некоторые длинные работы-проекты, многорелизные.
Релиз типично занимает 2 месяца. Накануне планируется список работ к исполнению: исправление сложных ошибок, доработка, новый некрпный функционал или достаточно быстро разрабатываемый, работы на проектирование и подготовку длинных задач.
В конце периода дней за 10 - бранч. Тестирование происходит практически с момента начала нового релиза в фоновом режиме - (регрессия) + проверка релизных работ вручную с проектированием и реализацией новых автотестов.
Затем ставят на учебную базу скажем так для бета-тестирования, а потом на живую на бета-тестирование но уже в таком жестком режиме.

Группа тестирования: 6 человек. 1 системный программист, 3 прикладных тест-программиста, 1 тест-дизайнер-аналитик, 1 руководитель
2 сотрудника с годичным опытом, 1 с трехлетним, 3 в 2-2,5 годичным. Ранее нигде тестированием не занимались
Задачи: анализ логов прогонов автоматизированных тестов, прием работ над ошибками, прием релизных работ.
Цель по-моему одна - находить ошибки :) Ранее ставилась цель обеспечения устойчивости системы, отслеживание и перехват регрессии. Сейчас на раннее обнаружение ошибок, разгрузка аналитиков по приему релизных работ

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

Из опыта работы с большими (но не бааальшими) системами. А вы потом проверяете общую работоспособность системы? Регресс полностью пускаете по системе?К примеру, у нас модули связаны так, что даже когда разработчики уверяют, что вот это не трогали, то с вероятностью раз в год там что-то громко сломается :( И самое обидное, что может уже и у заказчика((

Постоянно проверяем это. Регресс крутится в автоматическом режиме без нашего участия по ночам.
У нас это легко может происходить ежедневно. Раз в год - это просто чудо :)
Проблема в том, что регресс на все не поставишь. Ясно, что там где идет интенсивное изменение и рефакторинг применяется и усиленное внимание. Однако бывает и так, что где-то тронули. Наш регресс прошел, поскольку он же не всемогущ, и проявляется у клиента :(

Спасибо за мнение, Ленчик :)

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

Не могу выделять явную проблему, хотя ...

Скажем так. Мое представление классического тестирования. Есть бааальшая система. Типично, что она поделена на системы по-меньше, те в свою очередь и т.д. Декомпозиция, ведь.

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

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

Да еще проблема, в том, что тестирование началось системно не так давно. Так что покрытие довольно слабоватое. главным образом генеральное направление и новый функционал
...

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

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

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

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

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

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

о_О

тогда многое проясняется конечно ))))
а я то голову ломала))))

Хм, девочки, все все понимают, только, видимо, я вывалился из контекста. Так что же у нас не так?

Мда, неудачно я задал вопрос, слишком двусмысленно :)

Ну спасибо за интерес к теме :)

Я имел в виду:
1) согласны ли тестировщики с тем, что они действительно недостаточно хорошо понимают логику работы приложения и/или то, как клиенты используют приложение и с какими проблемами они сталкиваются,

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

2) могут ли они предложить какие-нибудь ещё способы устранения этого недостаточного понимания, помимо отправки "на передний край" службы технической поддержки?

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

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

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

Есть ли иные альтернативы? Например, отправить на стажировку непосредственно к клиенту, чтобы он там наблюдал за всем, что и как они делают.

Альтернативы всегда есть. Отправка на стажировку исключена.

Или, действительно, на время сделать их аналитиками, а может быть техническими писателями.

А как Вы себе это видите?

Почему только один вариант решения проблемы рассматривается?

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

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

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

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

Я видимо уже вечером писал на автопилоте:), коррекции внесены подчеркнутым.

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

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

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

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

Спасибо за развернутый ответ, Татьяна. Может побеседовать в личке?

Эдуард, а что ваши тестировщики думают по этому поводу?

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

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

Да это так. Автоматизированное тестирование одно из генеральных направлений (по крайней мере было). Исследовательское тестирование производится. Достаточно регулярно. Мало или немало, не могу сказать. А как Вы определили по моим словам, что мало? А сколько надо?

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

Честно говоря, я сначала испугалась, а не так ли это? :) Потом подумала и пришла вот к чему. В течении недели я слежу за каждой задачей в отдельности. По каждой в отдельности правят баги, если требуется. Перед релизом мне выдаётся кандидат, на котором я смотрю на работу системы в целом и как в неё вписалась новая функциональность. Разве это не приёмочное?
Почему это делаем мы. Заказчик -- министерство. Задачи поступают от внедренца-аналитика, продажника, ещё одного человека, функций которого я не знаю, но реального пользователя. Т.о. нет единого центра, кто бы нёс ответственность за приёмку. Ответственность возложили на тестировщика.

А ещё у нас есть чек-листы, которые должны заполняться при проведении приёмочного. По ним, видно, что проверено и какие баги возникли.

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

Итак у Вас есть заказчки - это министерство, естественно с ним Вы не контактируете. У нас также собственно.
В момент Х вы планируете приемочное тестирование, как я понял у вас есть чек-листы. Кто их составляет? На основании чего их составляют? Как Вы понимаете, что принимаемая вами функциональность работает правильно?

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

Красиво сказали :)

Я куда клоню. Менеджер видит проблему в каком-то факте. Трактует этот факт по-своему и предлагает решение, основанное на этой трактовке. Факт мы знаем (нахождение не тех багов, которые бы хотелось найти в первую очередь), но у этого факта тоже есть свои причины. Возможно, менеджер придумал себе причину, которая на самом дере нереальна. Отсюда и предложенное решение, которое Вам не нравится. Хорошо, если мои слова не подходят для вашей ситуации, но если нет? Вот я и хочу докопаться до причины факта, побудившего затеять такие перемены.

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

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

Да под таким углом я не смотрел. Можно вопрос? Под каким углом это подавать? Сказать - ты завтра работаешь в другом месте, потому что это хорошо для тебя, бизнеса, компании?

А почему он это делает?

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

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

А какое это имеет отношение к нашей беседе?

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

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

Как важный момент - тестиовщик просто уйдет из тестирования в анализ

Это укладывается в вашу цель?

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

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

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

В рамках анализа...
На мой взгляд тестировщик весь этот анализ берет из документов аналитика. В то время как аналитик должен составить эти документы сначала.

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

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

Как важный момент - тестиовщик просто уйдет из тестирования в анализ

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

Да интересная мысль!

Я не понимаю, как тестировщики должны составлять отчёты о багах, которые находят пользователи, если они ещё не работают с пользователями? Или что-то не так поняла?

Ну у нас вся разработка не работает с пользователями непосредственно. Есть сопровождение и внедрение. На сопровождении 1 человек работает на телефоне, но в целом мы с клиентами работаем через мантис. Тестеровщик имеет доступ к мантису и может анализировать информацию от пользователей.

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

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

Вопрос. А за какое время менеджеры планируют перевести отдел тестирования на новый режим работы? Есть ли возможность испробовать "демо": на ком-то одном или на каком-то небольшом промежутке времени? Чтобы оценить реальное положение дел именно у вас, а не на основе опыта других людей.

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

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

Странно для меня это.
А если сделать тестировщика еще и разработчиком, то он и код сам писать будет. И тестировать сразу же. Чем не мастер на все руки?)

Я тоже задался этим вопросом. Но если отбросить факт разработки:) А только остановится в рамках анализа, реально в чем разница между тесировщиком и аналитиком?

Например есть такой аргумент:
аналитик получает больше, соответственно более дорогой ресурс,
тестировщик тоже должен понимать предметку и явно не хуже аналитика