Лучше это перенести в форум по Автоматизации тестирования, а не с привязкой к конкретному инструменту.
Только сегодня наткнулся на отличное видео про юнит тесты. Рекомендую к просмотру вместе с программистом. Там как раз подробно объясняется, как изолироваться от внешних зависимостей.

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

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

Коллеги-модераторы, можете сделать это? Перенести тему.

Коллеги,

не судите строго, но объясните на примере. Как правильно составить (вообще) как составить unit-тест, например для подобного кода?

if vDoc.ClassID.InheritsFromClass(КПДокументНаПериод) and (позФИКСЦЕНА >= 0 or позНДСФИКСЦЕНА >= 0 or позСУММАФЦЗАПЕРИОД >= 0)  then
        begin
          netStrok := false;
          var ДопСостоянияДистр := ArrayToComma([СостояниеДистрибутива.Подключен, СостояниеДистрибутива.НаСкладе]);
          var ДатаНачала := EndOfDay(ToDate(vDoc.GetAttrValuesByName('ДатаНачала')));
          if fSN.AsString <> '' then
            ТекДистрибутив := Номенклатура.ВернутьДистрибутив(vDoc.Клиент, CommaGet(fSN.AsString, 0),
             Номенклатура(fArticle.AsInteger), ДопСостоянияДистр, ДатаНачала);
          if assigned(ТекДистрибутив) then
            var ФиксЦена := Rat.EvalQuery(
             SQLText
              !Select Reg.DistrFixedPrice
                From RegChangeDistributiv Reg
                Where Reg.Distributiv = &ToInt(ТекДистрибутив)&
                  and Reg.BeginDate <= &ToStr(ДатаНачала)&
                  and Reg.EndDate > &ToStr(ДатаНачала)&
                  and IsWorked = -1
                Order by Reg.BeginDate desc!
             end);
          ФиксЦена := ToFloat(ФиксЦена);
          if позФИКСЦЕНА >= 0 then
            vMas[i, позФИКСЦЕНА] := ФиксЦена;
          if позНДСФИКСЦЕНА >= 0 then
            vMas[i, позНДСФИКСЦЕНА] := Round(ToFloat(ФиксЦена) * fNDSRate.AsFloat / 100, 2, 1);
          if позСУММАФЦЗАПЕРИОД >= 0 then
          begin
            var ДатаОкончания := EndOfDay(ToDate(vDoc.GetAttrValuesByName('ДатаОкончания')));
            var КолМес := Функции_мат.КолМесяцев(ДатаНачала, ДатаОкончания);
            vMas[i, позСУММАФЦЗАПЕРИОД] := ФиксЦена * КолМес;
          end;

Т.е. на выходе будем иметь ФИКСЦЕНА или НДСФИКСЦЕНА или СУММАФЦЗАПЕРИОД. Как правильно изолироваться от реальных объектов и переменных? Мне нужно объяснить это на пальцах, а лучше показать пример программисту, чтобы мотивировать его на создание собственных юнит-тестов. :)

Спасибо

переместил

Большое спасибо

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 galogenIt - отличное владение копипастом

тогда уж копипейстом :)

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

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

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

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

Русификация Mantis

Начиная с MySQL 5.0, нужно явно задавать кодировку соединения (utf-8 или cp1251, в зависимости от выбранной русской локализации Mantis). Этот баг уже зарегистрирован http://www.mantisbt....php?bug_id=6782 , и возможно уже исправлен в последующих версиях, но в версии 1.0.6 (если база под MySQL 5.0), нужно добавить строчку-определение кодировки в функцию db_connect, файла core/database_api.php:
$t_result = $g_db->Connect($p_hostname, $p_username, $p_password, $p_database_name );
$g_db->Execute ("SET NAMES utf8");
При этом стоит использовать только «Настройки/Язык» из русских языков стоит использовать только «russian_utf8».

Может просто сохранить в 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;

Это не особенность какого-то окружения на мой взгляд. На VMW в течение 3 лет актвиной эксплуатации на разных хостовых машинах и с разными гостевыми ОС не было такого НИ РАЗУ. А при первом же запуске VB- хлабысь и хлабысь в одном и том же месте. Загадка сия великая есть

А в чем смысл выгрузки сообщений лога в текстовый файл? Лог собственно и есть ТЕКСТОВЫЙ файл. Не эффективнее ли просто разобраться с разметкой лога?
Мы, например, на VS написали программу, которая анализирует логи и формирует Excel-файл (отчет) в удобном для восприятия и работы виде. Гораздо лучше разобраться с устройством лога и научиться работать с ним. Это открывает для вас самые широкие горизонты. Для нас открыло

Странно, писал ответ. Куда исчез?

Нам никак не удается поработать с VB. Она у нас падает с ошибкой bad_coll_header или bad_pool_header. Ошибка возникает на гостевой винде. Можем повторить вручную при выполнении действий в тестируемом приложении. На VMW этого не происходит. В чем может быть проблема? VB 4+

Для прогона автотестов мы активно используем виртуальную машину. Пока используется VMWare. В самом начале выбора пытались использовать VirtualBox, но вынуждены были от нее отказаться. VB постоянно синхронизировала время с хост-машиной. А нам этого было не надо. Мы активно во время тестирования перемещаемся в прошлое и будущее. Найти ответ на вопрос, можно ли как-то отключить эту синхронизацию в то время не смогли. Потому пользовались VMWare. Однако потребности растут, приходится расширять парк машин и соответственно нужны еще лицензии на VMWare. Потому решили вернуться к экспериментам с VB. Нашли решение. Можно отключить службу VB и тогда синхронизация времени перестает быть проблемой. Но проблемой стало вообще само использования этой виртуальной машины. За все время экспериментов ни разу не удалось прогнать тесты полностью, постоянно вылезали какие-то проблемы, приводящие к зависанию VB или хоста. VB крутилась на 7. Сам файл с окружением и стендами был от VMWare.

Может кто-то поделиться опытом использования VirtualBox? Особенно интересует мнение людей кто перешел на VB с VMWare. Спасибо

Наталия, извините, я не знаком с жаргоном Post Morten. Исследование трупа? В данном случае я не могу приспособить эттот термин к желанию узнать что-то о метриках.

Да, наш разговор о метриках привратился в философский вопрос: Don't ask me ask God. Не пойму почему бы просто не рассказать о метриках и способах их сбора и использования. Как это сделал yagor. Можно будет решить имеет смысл и нам делать также или нет. Просто это выглядет примерно так. Я спрашиваю: коллеги а как вы решаете квадратное уравнение, а мне в ответ: а зачем вы его хотите решать?

Алексей Лянгузов Кстати, если вы тестируете на пользователях, то вот бодрый и интересный долад, который может заинтересовать http://www.addconf.r...omanYuferev/321
Про manageability. понятно - готового решения там нет, но есть интересные идеи.

Спасибо, правда, тестируете на пользователях - это тайна :)

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

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

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

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

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

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

1. Метрики не нужны "для контроля" или "для визуализации". Метрики нужны для принятия решений.

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

2. Есть два типа метрик. Одни нужны для "измерения температуры больного"/"измерения эффективности предприятия" , другие для "поиска ограничений".

И в чем их различие? Можно примеры?

3.

Средний срок исправления, да.

Это неправильное измерение. Мерять нужно от фиксации до того момента, когда заказчик "сказал спасибо" / "получил первый доллар прибыли". Исправление дефекта само по себе ничего не меняет для заказчика.

А каким образом ты предлагаешь фиксировать этот самый момент на стороне заказчика?

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

Спасибо. Очень познавательный пост. Итог, надо сказать, меня не удивил, ждал что-то подобное. Может из Вашего стиля :)
Не кажется ли Вам, что дело не только в нехватке ресурсов, а скорее сложности подсчетов и то, что все делается вручную? Т.е. статистика не накапливается, а ее приходится потом вводить?

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

Отчет выглядит примерно так:
ID теста Укороченное описание ошибки (выбирается из лога) Дата Статус Причина падения Примечание
Статус - это критично некритично
Причина падения - ошибка тестируемого объекта, ошибка прогона (сбой), ошибка в тестовой процедуре, изменение интерфейса или вообще изменения в тестируемой программе
Примечание - обычно указывает номер работ и ее состояние в системе управления работами

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

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

НаталЬя!

Извините, Наталья. Можете за это меня несколько раз назвать каким-то Этуартом :)

Спасибо за интерес к теме и подробные ответы-советы.

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

Понятно. Я так понимаю, подобная техника может применяться не только к анализу результатов ПРОЕКТА, но и любому этапу относительно законченной деятельности. Например, после выпуска очередного релиза?

Какие критерии успешности у Вашего проекта?

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

Вы можете "измерять" статус продукта: открытые баги / KLOC, открытые баги / разработчик, % реализованных требований, % реализованного функционала с учётом веса, tests pass rate и tests fail rate (желательно с учётом приоритетов) и т.д.
Можете "измерять" статус тестирования: % покрытия функционала тестами и/или автотестами, % багов, найденных после выпуска, средний срок жизни дефекта, срок нахождения критичных дефектов (в баг-трекере проставлять не только сборку обнаружения, но и при фиксе - выявленную сборку "внесения", мне эта метрика почти всегда была полезной), собирать субъективные оценки по анкетам, % reject'ов, % дополнительно запрошенных данных по багам, $/bug, % покрытия окружений и т.д. и т.д.

Спасибо, правда я не понял, поскольку не знаю, что такое:
- % реализованного функционала с учётом веса, что вкладывается здесь в понятие функционал и чем он отличается от требования.
- tests pass rate и tests fail rate (желательно с учётом приоритетов) - доля прошедших и доля упавших тестов? Приоритет - критичность для тестируемой системы?
- % багов, найденных после выпуска, что является основанием? Общее количество багов в релизе? А как его замерить? Когда начинать измерять основание? % найденный после выпуска - вроде понятно, а вот процент к чему нет.
- средний срок жизни дефекта - что это означает? средний срок устранения дефекта? Если да, то тут думаю дефекты тоже имеет смысл разделять иначе данная статистика как средняя температура по больнице.
- срок нахождения критичных дефектов - где? в каком состоянии? или это примерно тоже , что и средних срок пребывания заявки в системе (в системах массового обслуживания?) правда я не очень понимаю, какое это отношение имеет к тестированию, это скорее к дисциплине разработки и устранения ошибок.
- собирать субъективные оценки по анкетам, поясните, пожалуйста, что Вы имеете в виду.

НО я бы не делала ничего из этого до выявления двух факторов:
- Цели вашего проекта. Измеримые и всем понятные. Поверьте, если участники вашего проекта будут одинаково понимать цели, это поможет в сто раз лучше любых метрик!
- Выявление всеми участниками процесса "слабого звена", чтобы не акцентироваться на том, что и так никого не тормозит. Проблемы с дефектами? Анализируем их. Проблемы с пропусками багов? Анализируем их. И уже на основании этих пунктов действуем, выявляем метрики.

Допустим проблема с пропусками багов - какая метрика поможет это понять, ну и ясно поможет контролировать процесс устранение проблемы?

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

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

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

Но...

- средний срок жизни дефекта - что это означает? средний срок устранения дефекта? Если да, то тут думаю дефекты тоже имеет смысл разделять иначе данная статистика как средняя температура по больнице.

Средний срок исправления, да. Как предлагаете разделять? По приоритетам?

Да, по приоритетам. В целом у нас уже есть свой регламент: немедленные - исполняются в течение дня, важные - в течение недели, релизные - в течение релиза, обычные - когда руки дойдут + на "днях дезинсектора". Есть конечно внеприоритетные работы, т.е. им ставят, естественно, немедленно, но выполняются они мгновенно :)
Можно придумать и другие способы разделения - по исполнителю, например. Зависит от ситуации, которую требуется контролировать.
Правда мне не совсем понятно какой момент считать начальным, а какой конечный. В принципе, если следовать логике СМО, то от момента создания работы по дефекту до момента закрытия дефекта. У нас такой ЖЦ работ (не обязательно дефектов): предложена - запланирована - в работе - выполнена - проверяется - принята (естественно есть циклы и ветви)

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

Берём и делаем опросник на простой веб-форме, после каждого выпуска рассылаем его разработчикам, аналитикам, РМу. В нём 3-5 вопросов из серии "Оцените глубину тестирования по 10-балльной шкале", "Оцените качество дефектов по 10-балльной шкале" и т.д. Оценки ничего интересного не покажут (люди разные!), а вот динамика между версиями - очень показательна.

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

Допустим проблема с пропусками багов - какая метрика поможет это понять, ну и ясно поможет контролировать процесс устранение проблемы?

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

И самое главное: Вы уверены, что пропуск багов в Вашем случае - это проблема? Докажите, убедите меня, Этуарт! :)

а/ я написал допустим
б/ фраза про проблему с пропусками багов взята из Вашего предыдущего поста
в/ сама по себе метрика никак не может исправить, решить проблему - это точно так же как факт обнаружения ошибки не означает факт ее устранения или другими словами не решает проблему этой ошибки :) Так что тут у меня никаких возражений нет, да и не могло быть
г/ пропуск багов - это всегда риск. Риск предусмотренный и управляемый или непредусмотренный и неуправляемый. Пропуск ошибки - это выпуск некачественного продукта. Это определенная проблема. Всегда! Ее можно решать: ничего не делать - "сам дурак"; извинится и мгновенно устранить; обещать устранить в будущем. Пропуск багов - это лишние затраты, это риск недополучения прибыли и т.п. - это действительно проблема - серьезная или нет, it depends on
Ваш глубокий анализ верный, он вскрывает корневую причину: root problem, the problem of problems. В общем не вижу противоречий.

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

Аривидерчи

Хм, у нас тут совсем другое понимание приёмочного тестирования, и проводят его тестировщики перед выкладкой сборки на боевой сервер. Основная цель -- быстро пройти по всей функциональности (согласно бизнес процессам), чтобы выявить в первую очередь критические ошибки. Те задания, о которых говорите Вы, у нас проверяются сразу после выставления им статуса Resolved. Это и есть наша рутинная работа. Собственно потому не понимаю, чем же занимаются тестировщики у Вас большую часть времени.

Очень много чего. У нас очень сложно-хитроумный процесс. Кратко это так. Мы постоянно! тестируем одновременно три-четыре инстанса-релиза (старый релиз, молодой релиз, кандидат-релиз и транк). Связано это с тем, что у клиентов могут быть разные версии релизов но обычно в пределах 3 номеров. При этом ошибки возникают во всех релизах к сожалению.
Тестирование у нас в первую очеерд автоматизированное регрессионное. В каждом прогоне порядка 500 тестов, представляющие собой сложные бизнес-цепочки.
Работа начинается с разбора ночных прогонов, разбор тоже частично автоматизирован, формируется совокупный лог отчет. который мы потом анализируем. Чем меньше ошибок тем лучше и быстрее
Другой уровень работы - написание новых тестов для автоматизированных прогонов, расширение покрытия
Третий уровень изучение новой функциональности по транку - по необходимости написание тестов для автоматизациии и проверка прием работ
Четвертый уровенб исследовательское перманентное тестирование

Достаточно?

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

Так проще и логичнее.

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

Возможна ли такая схема? Впринципе, что как ты думаешь нужно сделать для ее реализации и успеха?

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

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

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

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

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

Считается ли это нормальной, правильной практикой? Как организуется эта работа? Следует учесть, что формализованное специфицирование требований отсутствует или недостаточно формально. Серьезных изменений в этом не будет. Предполагается, что в данной ситуации проще и быстрее обучить тестировщика "здравому смыслу заказчика". Спасибо