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

Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 29

#1 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 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. Мне говорят, ерунда, это нереальные, несуществующие данные, подобного у пользователей не может проявится, потому нечего тестировать "космос", замените данные и не парьтесь. Есть дела поважнее.

Кто что думает по этому поводу?
  • 0
С уважением, Эдуард!

#2 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 08 февраля 2012 - 07:46

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

В данном случае интересно вот что - вы сами знаете, что данные "нежизненные"? И у вас есть возможность получить и проверить правильные боевые данные?
Можно ли спросить у пользователей - насколько эти данные далеки от действительности?
Про тестирование космоса вам именно говорят или это вписано в багобазу в качестве ответа на данную ошибку?
А что именно вы тестируете? Я надеюсь, что не финансовые документы с таким округлением?:)
  • 0

#3 AxelM

AxelM

    Активный участник

  • Members
  • PipPip
  • 118 сообщений
  • ФИО:Зверев Дмитрий
  • Город:Санкт-Петербург


Отправлено 08 февраля 2012 - 08:05

Коллеги,

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

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

В отчете стоит точность отображения ранвая 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. Мне говорят, ерунда, это нереальные, несуществующие данные, подобного у пользователей не может проявится, потому нечего тестировать "космос", замените данные и не парьтесь. Есть дела поважнее.

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


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

#4 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 08 февраля 2012 - 08:26

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


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

И о каких данных идет речь?
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#5 D2Phoenix

D2Phoenix

    Постоянный участник

  • Members
  • PipPipPip
  • 200 сообщений
  • ФИО:Чадюк Вадим
  • Город:Гродно


Отправлено 08 февраля 2012 - 08:29

А в чём собственно проблема??
Баг вроде как есть. Значит занесли его в ваш баг трекер и всё. А будут его фиксить или нет, это уже не ваша забота) Вы свою работу выполнили)
  • 0

#6 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 08 февраля 2012 - 08:43

А в чём собственно проблема??
Баг вроде как есть. Значит занесли его в ваш баг трекер и всё. А будут его фиксить или нет, это уже не ваша забота) Вы свою работу выполнили)

А вот и нет.
Будут фиксить или нет — в том числе и забота тестировщика.

Во-первых, за продукт ответственна вся команда. А если «написал и забыл» — то тут попахивает «моя хата с краю, чо хотите, то и делайте»
Во-вторых, если его пофиксят, то скорее всего придется перепроверять много чего, т.к. изменение может что-нибудь и поломать: появление новых багов, сдвиг сроков, и крайними могут оказаться как раз тестировщики.
  • 0

#7 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 08 февраля 2012 - 08:44

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

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

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

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

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

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

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

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

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

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

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

#8 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 08 февраля 2012 - 08:47

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


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

#9 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 08 февраля 2012 - 08:48

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

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

#10 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 08 февраля 2012 - 08:49


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


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

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

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

#11 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 08 февраля 2012 - 08:58


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

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


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

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

Но в целом я понял, что я скорее прав, чем неправ :)
  • 0
С уважением, Эдуард!

#12 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 08 февраля 2012 - 09:33

А вот и нет.
Будут фиксить или нет — в том числе и забота тестировщика.
.... и крайними могут оказаться как раз тестировщики.


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

Остальное нас касаться не должно.
Пофиксили его, вернут
не пофиксили - не нужно писать -напоминать про то что у нас там баг валяется.

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

Но такой подход весьма странен. Особенно когда один ПМ говорит делайте вот так и так. а два других - написали и забейте.
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#13 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 08 февраля 2012 - 09:36

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

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

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


Насколько я могу судить для отчета подобные округления могут быть фатальными.
Поэтому ошибка будет приоритетной как минимум для заказчика.

(если вы тестируете программу которая считает внесенные данные отчетности)
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#14 D2Phoenix

D2Phoenix

    Постоянный участник

  • Members
  • PipPipPip
  • 200 сообщений
  • ФИО:Чадюк Вадим
  • Город:Гродно


Отправлено 08 февраля 2012 - 09:43

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

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

#15 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 08 февраля 2012 - 10:17


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

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


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

#16 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 08 февраля 2012 - 10:28

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


Ок!

Т.е. Вы для себя разбираетесь - введенный Вами в базу тестовый набор необходим или нет?

уфф....
1. Вы должны тестировать Ваше ПО только на корректных входных данных?
2. Вы должны тестировать в том числе и на некорректных входных данных?
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#17 Outre

Outre

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Софья


Отправлено 08 февраля 2012 - 10:51

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

В исходных данных стоит 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, то это правильно для финансового отчета - пятерка округляется к четному числу.

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

#18 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 08 февраля 2012 - 13:27

Что говорят аналитики на этот баг? Может он приведет к чему-то более важному и при 2-ух знаках после запятой.
Могут ли они донести это до пользователей и узнать их мнение? Причем спросить стоит не просто про 3 знака после запятой, а так чтобы было понятно откуда растут ноги. То есть раньше такие подобные данные были и у вас и у пользователей, да? Теперь что-то поменялось в программе и отчет стал выдавать "плавающие данные". Я правильно понимаю? Как пользователи к этому отнесутся?

С другой стороны, если со всеми согласовано, что три знака уже не важны, то может руководство и право? Но ошибка все-таки странная)
  • 0

#19 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 08 февраля 2012 - 13:31


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

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

Ну вот это не самый лучший вариант, имхо. Блокировать выпуск когда начальник говорит, что ошибка минорная.. ну не очень разумно, скажем так..
  • 0

#20 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 08 февраля 2012 - 13:35

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

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


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных