Перейти к содержимому

Публикации galogenIt

64 публикаций создано galogenIt (учитываются публикации только с 30 марта 2023)



#100743 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 16:49 в Управление тестированием

Логично. Это ограничений (фича) системы. Не баг.

SALar, в чем фича-то? Почему не баг.



#100725 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 13:37 в Управление тестированием


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

В исходных данных стоит 0,325 или 0.375
в отчете может отображаться
- 0.32 0.38
- 0.32 0.37
- 0.33 0.38
- 0.33 0.37


Простите за дурацкий вопрос, а у вас это происходит именно при одинаковых входных данных, как описано в примере? Потому что если 3.75 округляется до 3.8, и 3.85 округляется до 3.8, то это правильно для финансового отчета - пятерка округляется к четному числу.

Спрашиваю просто на всякий случай, а то мало ли.


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



#100724 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 13:35 в Управление тестированием

Я получил такой ответ от руководства.

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



#100704 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 10:17 в Управление тестированием


Я бы сюда не писал, а просто блокировал бы выпуск релиза :)

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


Погодите, я не спрашиваю совета, что делать. Тут все ясно. Я считаю, это ошибкой, руководство считает это ошибкой, но столь незначительной, что на нее не стоит и тратить время (зачем тестировать "космос"?). Мне говорят, ИСПРАВЬ эти данные в базе, и ошибка исчезнет. Пользователи ничего не говорят же об этом. Я же пытаюсь доказать, что прав я, что данные должны быть такими, которые позволяют выявить ошибку. А обратился сюда я, за поддержкой своей точки зрения или наоброт, что бы мне указали, что я ошибаюсь в своих выводах и почему.



#100692 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 08:58 в Управление тестированием


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

Я думаю, если все области/случаи с более высоким приоритетом протестированы, а время свободное осталось :), то надо проверять и такие случаи. ВНЕЗАПНО может оказаться, что для заказчика это высокоприоритетный баг.


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

Причем "ВНЕЗАПНО может оказаться, что для заказчика это высокоприоритетный баг".

Но в целом я понял, что я скорее прав, чем неправ :)



#100689 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 08:49 в Управление тестированием


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


"хранимая точность значения" - это что?

И о каких данных идет речь?

Я тоже не совсем понял этого термина, полагаю, что значение коэффициента может иметь точность только до 2 знаков. Данные с точностью 3 знака признаются ошибочными (видимо)



#100687 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 08:47 в Управление тестированием

1. Ошибку надо записывать всегда
2. Приоритет её определяет менеджер, как и дальнейшую работу по ней
3. Разработчик должен просыпаться в холодном поту с мыслью, что в его коде есть ошибка (в каждой шутке есть доля шутки).


1. ошибка записана.
2. была проанализирована, приоритет понижен, в моем расписании я вновь начал ее продвигать
3. скромно промолчу ...



#100685 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 08:44 в Управление тестированием

В данном случае интересно вот что - вы сами знаете, что данные "нежизненные"?

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

И у вас есть возможность получить и проверить правильные боевые данные?

думаю, я ответил ранее. Да , конечно.

Можно ли спросить у пользователей - насколько эти данные далеки от действительности?

Нет, непосредственно с пользователем мы не общаемся. Наш интерфейс общения с ними - аналитики.

Про тестирование космоса вам именно говорят или это вписано в багобазу в качестве ответа на данную ошибку?

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

А что именно вы тестируете? Я надеюсь, что не финансовые документы с таким округлением?:)

Это аналитический отчет. Если бы это было в финансовом документ. Я бы сюда не писал, а просто блокировал бы выпуск релиза :)

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



#100674 Здравый смысл и тестирование

Отправлено автор: galogenIt 08 февраля 2012 - 07:18 в Управление тестированием

Коллеги,

хотел спросить у вас, возникают ли подобные "конфликты" у вас и как они решаются? Кто прав, кто лев?

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

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

В исходных данных стоит 0,325 или 0.375
в отчете может отображаться
- 0.32 0.38
- 0.32 0.37
- 0.33 0.38
- 0.33 0.37

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

В чем конфликт
1. Я считаю, что данные хотя и "нежизненные", тем не менее фиксируют ошибку. А слеовательно они просто замечательные
2. Мне говорят, ерунда, это нереальные, несуществующие данные, подобного у пользователей не может проявится, потому нечего тестировать "космос", замените данные и не парьтесь. Есть дела поважнее.

Кто что думает по этому поводу?



#94890 VirtualBox

Отправлено автор: galogenIt 29 сентября 2011 - 06:11 в Автоматизированное тестирование

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



#94805 VirtualBox

Отправлено автор: galogenIt 27 сентября 2011 - 11:26 в Автоматизированное тестирование

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

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



#94307 VirtualBox

Отправлено автор: galogenIt 17 сентября 2011 - 16:34 в Автоматизированное тестирование

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

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



#93780 Ликбез по unit-тестированию

Отправлено автор: galogenIt 06 сентября 2011 - 18:33 в Автоматизированное тестирование

переместил

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



#93757 Ликбез по unit-тестированию

Отправлено автор: galogenIt 06 сентября 2011 - 11:01 в Автоматизированное тестирование

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

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

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

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



#93720 Ликбез по unit-тестированию

Отправлено автор: galogenIt 06 сентября 2011 - 06:26 в Автоматизированное тестирование

Коллеги,

не судите строго, но объясните на примере. Как правильно составить (вообще) как составить 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;

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

Спасибо



#92681 Повышение эффективности процесса тестирования.

Отправлено автор: galogenIt 16 августа 2011 - 11:33 в Управление тестированием


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


1) Скорость выполнения заказа более важна, чем объем выполняемых заказов в единицу времени. Т.е. вам скорее нужна не эффективность, понимаемая как <кол-во заказов>/<единицу времени * одного сотрудника>, а именно средняя скорость выполнения заказов.

1. что такое объем выполненных заказов?
2. разве объем выполненных заказов в единицу времени - это не скорость выполнения?
3. А что такое скорость выполнения заказа?
4. а средняя скорость выполнения заказов как рассчитывается?

2) Чтобы работать именно с тем, что нужно заказчику нужно рассматривать процесс целиком. Субоптимизация участка тестирования является классической грубейшей ошибкой.

Сергей, это здорово, что ты продвигаешь идеи ТОС, однако вопрос: ты не можешь привести примеры реального применения положений теории ТОС при разработке программного продукта на заказ? ну или на продажу? Спасибо



#92634 Работа с логами

Отправлено автор: galogenIt 15 августа 2011 - 13:57 в SmartBear (AutomatedQA) - Functional Testing

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



#92578 Mantis на русский

Отправлено автор: galogenIt 13 августа 2011 - 17:14 в Управление тестированием

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

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



#92524 Mantis на русский

Отправлено автор: galogenIt 12 августа 2011 - 07:42 в Управление тестированием

Русификация 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».



#92481 Метрики процесса тестирования

Отправлено автор: galogenIt 11 августа 2011 - 11:19 в Управление тестированием

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

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

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

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

3.

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

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

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



#92429 Метрики процесса тестирования

Отправлено автор: galogenIt 10 августа 2011 - 17:42 в Управление тестированием

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

Но...

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

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

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

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

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

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

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

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

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

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

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

Аривидерчи



#92311 Метрики процесса тестирования

Отправлено автор: galogenIt 08 августа 2011 - 07:43 в Управление тестированием

НаталЬя!

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

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

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


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


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

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

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

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

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


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

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

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



#92221 Метрики процесса тестирования

Отправлено автор: galogenIt 06 августа 2011 - 16:13 в Управление тестированием

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

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



#92046 Метрики процесса тестирования

Отправлено автор: galogenIt 04 августа 2011 - 06:31 в Управление тестированием

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

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

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

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

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

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



#92028 Метрики процесса тестирования

Отправлено автор: galogenIt 03 августа 2011 - 16:53 в Управление тестированием

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


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