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

Коллеги,

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

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

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

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

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

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

Коллеги,

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

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

В отчете стоит точность отображения ранвая 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. Разработчик должен просыпаться в холодном поту с мыслью, что в его коде есть ошибка (в каждой шутке есть доля шутки).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но такой подход весьма странен. Особенно когда один ПМ говорит делайте вот так и так. а два других - написали и забейте.

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

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

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

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

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

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

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

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

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

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

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

Ок!

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

уфф....
1. Вы должны тестировать Ваше ПО только на корректных входных данных?
2. Вы должны тестировать в том числе и на некорректных входных данных?

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

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

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

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

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

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

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

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

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

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