SALar, в чем фича-то? Почему не баг.Логично. Это ограничений (фича) системы. Не баг.
- Форум тестировщиков
- → Публикации galogenIt
64 публикаций создано galogenIt (учитываются публикации только с 30 марта 2023)
Отправлено автор: galogenIt 08 февраля 2012 - 16:49 в Управление тестированием
SALar, в чем фича-то? Почему не баг.Логично. Это ограничений (фича) системы. Не баг.
Отправлено автор: 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, то это правильно для финансового отчета - пятерка округляется к четному числу.
Спрашиваю просто на всякий случай, а то мало ли.
Отправлено автор: galogenIt 08 февраля 2012 - 13:35 в Управление тестированием
Отправлено автор: galogenIt 08 февраля 2012 - 10:17 в Управление тестированием
Если у вас есть такая возможность, то вы можете ею воспользоваться. Всё в ваших руках. Предсказать какую роль может сыграть найденный вами баг, в вашем проекте, никто не сможет на данном форуме. Если вы считаете его критичным, то действуйте.
Я бы сюда не писал, а просто блокировал бы выпуск релиза :)
Отправлено автор: galogenIt 08 февраля 2012 - 08:58 в Управление тестированием
Я думаю, если все области/случаи с более высоким приоритетом протестированы, а время свободное осталось :), то надо проверять и такие случаи. ВНЕЗАПНО может оказаться, что для заказчика это высокоприоритетный баг.
Тема вопроса, прав ли руководитель, советующий (приказывающий) мне не тестировать космос (т.е. заведомо некорректные данные) или я, как истинный тестировщик, который тестирует разные ситуация, возможные и невозможные, но которые явно приводят к ошибке?
Отправлено автор: galogenIt 08 февраля 2012 - 08:49 в Управление тестированием
Я тоже не совсем понял этого термина, полагаю, что значение коэффициента может иметь точность только до 2 знаков. Данные с точностью 3 знака признаются ошибочными (видимо)
Выяснилось, что сейчас хранимая точность значения не может быть лучше 2 знаков после запятой, т.е. значение 0.325 или 0.375 является некорректным.
"хранимая точность значения" - это что?
И о каких данных идет речь?
Отправлено автор: galogenIt 08 февраля 2012 - 08:47 в Управление тестированием
1. Ошибку надо записывать всегда
2. Приоритет её определяет менеджер, как и дальнейшую работу по ней
3. Разработчик должен просыпаться в холодном поту с мыслью, что в его коде есть ошибка (в каждой шутке есть доля шутки).
Отправлено автор: galogenIt 08 февраля 2012 - 08:44 в Управление тестированием
Поясню. Эти данные ранее были вполне жизненные. Дело в том, что мы используем данные некоторой эталонной базы. Т.е. большинство данных введенных в нашу эталонную базу - это данные реальных пользователей, введенные в реальных ситуациях.В данном случае интересно вот что - вы сами знаете, что данные "нежизненные"?
думаю, я ответил ранее. Да , конечно.И у вас есть возможность получить и проверить правильные боевые данные?
Нет, непосредственно с пользователем мы не общаемся. Наш интерфейс общения с ними - аналитики.Можно ли спросить у пользователей - насколько эти данные далеки от действительности?
В данный момент пока говорят. И ранее часто говорили, причем это исходит из уст руководителя. Может он прав? В багобазе как раз и написано, что с ошибкой следует разобраться, хотя проблема и не приоритетнаПро тестирование космоса вам именно говорят или это вписано в багобазу в качестве ответа на данную ошибку?
Это аналитический отчет. Если бы это было в финансовом документ. Я бы сюда не писал, а просто блокировал бы выпуск релиза :)А что именно вы тестируете? Я надеюсь, что не финансовые документы с таким округлением?:)
Отправлено автор: galogenIt 08 февраля 2012 - 07:18 в Управление тестированием
Отправлено автор: galogenIt 29 сентября 2011 - 06:11 в Автоматизированное тестирование
Отправлено автор: galogenIt 27 сентября 2011 - 11:26 в Автоматизированное тестирование
Отправлено автор: galogenIt 17 сентября 2011 - 16:34 в Автоматизированное тестирование
Отправлено автор: galogenIt 06 сентября 2011 - 18:33 в Автоматизированное тестирование
Большое спасибопереместил
Отправлено автор: galogenIt 06 сентября 2011 - 11:01 в Автоматизированное тестирование
Спасибо за совет.Лучше это перенести в форум по Автоматизации тестирования, а не с привязкой к конкретному инструменту.
Только сегодня наткнулся на отличное видео про юнит тесты. Рекомендую к просмотру вместе с программистом. Там как раз подробно объясняется, как изолироваться от внешних зависимостей.
Отправлено автор: galogenIt 06 сентября 2011 - 06:26 в Автоматизированное тестирование
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;
Отправлено автор: galogenIt 16 августа 2011 - 11:33 в Управление тестированием
1. что такое объем выполненных заказов?
Чтоб мы могли в любой момент внедрить наш продукт заказчику, а не ждать пока команда тестирования проведет свои проверки для каждого модуля умноженного на заказчика.
1) Скорость выполнения заказа более важна, чем объем выполняемых заказов в единицу времени. Т.е. вам скорее нужна не эффективность, понимаемая как <кол-во заказов>/<единицу времени * одного сотрудника>, а именно средняя скорость выполнения заказов.
Сергей, это здорово, что ты продвигаешь идеи ТОС, однако вопрос: ты не можешь привести примеры реального применения положений теории ТОС при разработке программного продукта на заказ? ну или на продажу? Спасибо2) Чтобы работать именно с тем, что нужно заказчику нужно рассматривать процесс целиком. Субоптимизация участка тестирования является классической грубейшей ошибкой.
Отправлено автор: galogenIt 15 августа 2011 - 13:57 в SmartBear (AutomatedQA) - Functional Testing
Отправлено автор: galogenIt 13 августа 2011 - 17:14 в Управление тестированием
тогда уж копипейстом :)2 galogenIt - отличное владение копипастом
Отправлено автор: galogenIt 12 августа 2011 - 07:42 в Управление тестированием
Отправлено автор: galogenIt 11 августа 2011 - 11:19 в Управление тестированием
Для визуализации точно не нужны, визуализация - это способ представления информации.1. Метрики не нужны "для контроля" или "для визуализации". Метрики нужны для принятия решений.
И в чем их различие? Можно примеры?2. Есть два типа метрик. Одни нужны для "измерения температуры больного"/"измерения эффективности предприятия" , другие для "поиска ограничений".
А каким образом ты предлагаешь фиксировать этот самый момент на стороне заказчика?3.
Это неправильное измерение. Мерять нужно от фиксации до того момента, когда заказчик "сказал спасибо" / "получил первый доллар прибыли". Исправление дефекта само по себе ничего не меняет для заказчика.Средний срок исправления, да.
Отправлено автор: galogenIt 10 августа 2011 - 17:42 в Управление тестированием
Да, по приоритетам. В целом у нас уже есть свой регламент: немедленные - исполняются в течение дня, важные - в течение недели, релизные - в течение релиза, обычные - когда руки дойдут + на "днях дезинсектора". Есть конечно внеприоритетные работы, т.е. им ставят, естественно, немедленно, но выполняются они мгновенно :)Средний срок исправления, да. Как предлагаете разделять? По приоритетам?- средний срок жизни дефекта - что это означает? средний срок устранения дефекта? Если да, то тут думаю дефекты тоже имеет смысл разделять иначе данная статистика как средняя температура по больнице.
Вероятно, я еще не очень опытный тестировщик, но затрудняюсь что-то сказать, будь я на месте аналитика или программиста, на эти вопросы: оцените глубину тестирования? - интересно, что ответят все наши "оппоненты" - мне думается, это будет пальцем в небо :)Берём и делаем опросник на простой веб-форме, после каждого выпуска рассылаем его разработчикам, аналитикам, РМу. В нём 3-5 вопросов из серии "Оцените глубину тестирования по 10-балльной шкале", "Оцените качество дефектов по 10-балльной шкале" и т.д. Оценки ничего интересного не покажут (люди разные!), а вот динамика между версиями - очень показательна.- собирать субъективные оценки по анкетам, поясните, пожалуйста, что Вы имеете в виду.
а/ я написал допустимНачнём с глубокого анализа. Почему пропускались баги. Берём конкретные баги и анализируем. У вас тесты документируются? Тестовое покрытие измеряется? Почему конкретный баг N был пропущен? Возможно, корень приведёт вас к некачественному проектированию тестов, или маленькому тестовому покрытию, или нехватке времени на тестирование, или неэффективному планированию и т.д. То есть сами по себе метрики % пропущенных багов можно собирать, только к решению проблемы эта цифра Вас не приведёт.Допустим проблема с пропусками багов - какая метрика поможет это понять, ну и ясно поможет контролировать процесс устранение проблемы?
И самое главное: Вы уверены, что пропуск багов в Вашем случае - это проблема? Докажите, убедите меня, Этуарт! :)
Отправлено автор: galogenIt 08 августа 2011 - 07:43 в Управление тестированием
Извините, Наталья. Можете за это меня несколько раз назвать каким-то Этуартом :)НаталЬя!
Post Mortem - это процесс анализа результатов проекта. Когда все участники садятся вместе за чашечкой чая и обсуждают: что было хорошо, что было плохо.
Я могу ошибаться в деталях, но в целом:Какие критерии успешности у Вашего проекта?
Спасибо, правда я не понял, поскольку не знаю, что такое:Вы можете "измерять" статус продукта: открытые баги / KLOC, открытые баги / разработчик, % реализованных требований, % реализованного функционала с учётом веса, tests pass rate и tests fail rate (желательно с учётом приоритетов) и т.д.
Можете "измерять" статус тестирования: % покрытия функционала тестами и/или автотестами, % багов, найденных после выпуска, средний срок жизни дефекта, срок нахождения критичных дефектов (в баг-трекере проставлять не только сборку обнаружения, но и при фиксе - выявленную сборку "внесения", мне эта метрика почти всегда была полезной), собирать субъективные оценки по анкетам, % reject'ов, % дополнительно запрошенных данных по багам, $/bug, % покрытия окружений и т.д. и т.д.
НО я бы не делала ничего из этого до выявления двух факторов:
- Цели вашего проекта. Измеримые и всем понятные. Поверьте, если участники вашего проекта будут одинаково понимать цели, это поможет в сто раз лучше любых метрик!
- Выявление всеми участниками процесса "слабого звена", чтобы не акцентироваться на том, что и так никого не тормозит. Проблемы с дефектами? Анализируем их. Проблемы с пропусками багов? Анализируем их. И уже на основании этих пунктов действуем, выявляем метрики.
Да, я не сержусь :) Я ну скорее недоумеваю. Я еще ничего не начал собирать (в смысле никаких метрик), я пока обогащаюсь идеями этих метрик. Поймите, да наверняка, можно засесть за книги, статьи, блоги. Таким образом составить для себя некоторый список метрик, способов их измерения и использования. Потом через анализ или методом проб и ошибок, понять, что это подходит, это не подходит. Раньше это был бы, пожалуй, единственный способ получения знания. Но сейчас есть же такие прекрасные возможности :)Пожалуйста, не сердитесь, что вам не ответили "по существу". Просто я видела не одну компанию, которая собирает метрики, прикрывается ими, и в итоге не видит реального положения вещей. Метрики без предварительного анализа и понимания, как и для чего вы их будете использовать - зло значительно более худшее, чем их отсутствие!
Отправлено автор: galogenIt 06 августа 2011 - 16:13 в Управление тестированием
Отправлено автор: galogenIt 04 августа 2011 - 06:31 в Управление тестированием
Спасибо. Очень познавательный пост. Итог, надо сказать, меня не удивил, ждал что-то подобное. Может из Вашего стиля :)Итог: Предполагалось в течении полугода пособирать числа для статистики, после уже считать что то и делать выводы, пособирали пару месяцев для интереса считали цифры (с умным видом их обсуждали :)). Потом руководитель отдела свернул эту работу в виду нехватки ресурсов для поддержания системы.
Отправлено автор: galogenIt 03 августа 2011 - 16:53 в Управление тестированием
Алексей Лянгузов Кстати, если вы тестируете на пользователях, то вот бодрый и интересный долад, который может заинтересовать http://www.addconf.r...omanYuferev/321
Про manageability. понятно - готового решения там нет, но есть интересные идеи.
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru