В моем приложении есть несколько предопределенных шаблонов выражений, которые можно использовать для фильтрации данных. Одним из них является " between x and y". Инженер QA утверждает, что в его определении есть дефект, потому что " between 100 and 200" дает результаты, отличные от " between 200 and 100". Выражение внутренне переводится на « value >= x and value <= y», поэтому, очевидно, нет результатов, когда вторая граница ниже первой. Я проверил, что такое же поведение в SQL - " between x and y" предполагает, что y> = x или нет результатов. Это означает, что оператор не является коммутативным, по крайней мере, в SQL.
Итак, верно ли, что QA " between x and y" должно быть коммутативным?
requirements
pkalinow
источник
источник
betweenследует ли включать или исключать более низкие и более высокие значения. Специалист по обеспечению качества может быть педантичным, но до тех пор, пока существует неопределенность, кто-то должен прояснить пользовательские истории / требования. Может оказаться, что они так и делают, как и должно быть, но решение должно быть принято.Ответы:
Если ваша текущая спецификация оставляет это неопределенным, поведение совершенно произвольное, нет «правильного» или «неправильного» определения. Поэтому, если ваш инженер по обеспечению качества не может указать вам точный абзац в спецификации, где это поведение определено, вы, вероятно, можете отклонить его запрос (хотя это не является требованием, которое требует больших усилий для его реализации). Если вы оба не можете найти консенсус, один человек в вашей команде должен принять решение, что является более важным в контексте заявки:
Независимо от того, какое решение принимает ваша команда, было бы неплохо задокументировать поведение и причину, по которой это решение было принято.
источник
Это вопрос юзабилити или пользовательского опыта. Как ведет себя SQL или любая другая система, не имеет значения, вопрос в том, что имеет смысл с точки зрения пользователей.
Текущее поведение не имеет смысла с точки зрения пользователя. Либо x и y должны быть взаимозаменяемыми, либо нельзя разрешить выбирать x больше y. Разрешение x больше чем y, но возвращение пустого набора приводит к ненужной возможности ошибок без предоставления какой-либо выгоды.
Таким образом, инженер QA является правильным, есть дефект, но предлагаемое решение не обязательно является лучшим. Вы должны выполнить юзабилити-тесты, решить это или, по крайней мере, спросить некоторых типичных пользователей, что кажется им наиболее естественным.
Кроме того, вы можете задать вопрос по адресу /ux// . Люди там действительно кое-что знают об опыте пользователя.
источник
Есть несколько разумных вариантов, и выбор зависит от остальной системы и ожиданий ваших пользователей.
Вы можете, как указывает инженер QA, просто сделать выражение коммутативным, и тогда перевод будет
between x and y=>value >= min(x, y) and value <= max(x, y)Вы можете ограничить допустимое использование
x <= y, что, скорее, требует, чтобы ваш пользовательский интерфейс отображал «это недопустимое выражение» как можно раньше.В качестве варианта вышеизложенного, ограничение,
x < yесли у вас есть выражениеequals xи предпочитаете это для оценкиvalue >= x and value <= xисточник
value >= min(x, y) and value <= max(x, y). Пересчитайте все, что вы можете, чтобы сохранить работу сервера базы данных, особенно если он такой избыточный (вы можете выполнить соответствующие операции один раз и установить оба результата соответственно). Это может не иметь значения, в зависимости от сервера базы данных и конкретных значений, которые вы вводите, но плохо написанный SQL-сервер вполне может выполнитьminиmaxдля каждой записи, если вы поместите их вwhere, и если вы сможете отменить это усилие нет причин не делать этогоvalue >= min(x, y) and value <= max(x, y)читабельнее, чемvalue >= minXY and value <= maxXY, гдеminXYиmaxXYявляются предварительно рассчитанными границами. Однако для последнего потребуется написать некоторый код, чтобы добавить эти две новые переменные в систему, заполнить их заранее, не забудьте обновить эти значения при изменении x и y и так далее. Избыточные данные всегда вносят определенный риск ошибок.В неинтерактивной среде, где ваши границы создаются скриптом, обычно имеет смысл требовать, чтобы они были в порядке. Это создает одну менее проверочную проверку, имеет больше смысла семантически и тривиально для управления.
В интерактивной обстановке вы хотите помочь пользователю. Если возможно, создайте графический интерфейс, который не позволяет вводить измененные диапазоны или, по крайней мере, упрощает ввод диапазонов по порядку. Если вы вводите диапазоны по тексту, возьмите страницу из vim, этот образец удобства и предложите пользователю автоматически поменять местами инвертированные диапазоны:
Если у вашего инженера по контролю качества не было ничего на пути UX, чтобы показать ему, что инвертированный диапазон был бы нежелателен, то он сделал разумное предположение.
источник
Откровенно? Не используйте «между». Вообще.
Во-первых, термин невероятно двусмысленный, особенно в английском. Это коммутативно? Являются ли условия эксклюзивными? Inclusive?
Во-вторых, если вы делаете интерфейс, оторванный от бэкэнда, не беспокойтесь о его поведении; и не позволяйте своим пользователям принимать унаследованное поведение, либо. Конечно, SQL определяет его
BETWEENкак включающий, но это почти никогда не является желаемым поведением (например, если вы делаете что-то подобное,rows BETWEEN :start and :start + :strideвы получаетеstride + 1строки).Вместо этого вы должны явно перечислить сравнения для конечных точек. «Больше или равно х». "До сегодня". Это устраняет двусмысленность. Это также помогает писать более чистый код и избежать некоторых коварных ошибок. Пример строк из более раннего, по сути , пост Джикстры об индексации . А разрешение SQL использовать верхнюю границу для некоторых типов может привести к неправильному выбору данных .
источник
Бесполезно спорить с вашим QA о том, кто «прав», а кто «неправ». Вы интерпретировали спецификацию иначе, чем они. Это означает, что спецификация достаточно неоднозначна, что требует уточнения.
Если пользовательский интерфейс - это спецификация, и это не то поведение, которого ожидает QA, то оно не будет таким, как ожидают некоторые пользователи. Это указывает на проблему с удобством использования (даже если вы хотите спорить с PEBKAC). Работайте со своим QA, чтобы найти удовлетворительное решение для этого.
В целом, будьте осторожны со словами типа «между», которые кажутся ясными, но не являются очевидными. Помимо вашего разногласия по поводу того, стоит ли добираться до города, это проблемы с инклюзивностью с обеих сторон, и они могут интуитивно означать разные вещи в разных доменах (например, «между пятницей и понедельником» будет означать нечто иное для большинства людей, чем «между понедельником и пятница ")
источник
Я раскошелюсь на принцип UNIX, который говорит о простых интерфейсах.
Везде, где есть интерфейс, который вы предлагаете внешнему миру, сделайте это как можно менее удивительным!
Теперь, когда я сократил формулировку задачи до более прагматичной, я думаю, что вам понадобится всего несколько минут, чтобы понять, что при указании диапазонов чисел очевидно, что *** оставит меньшее как прежнее ***. Если это все еще головоломка, подумайте так: сколько раз вы использовали обратный способ представления двух чисел, рассказывая детям, как их сравнивать?
Если ваш инженер по контролю качества называет это ошибкой, вежливо скажите ему, что вы ожидаете каких-то реальных ошибок, а не способов потратить дорогостоящую энергию на тривиальные вещи.
источник
Сделайте так, чтобы ваш код отладки выдавал состояние ошибки или регистрировал предупреждение, когда ему передаются значения в неправильном порядке. Таким образом, вызывающий код может проверять и обмениваться параметрами, если это необходимо. Таким образом, пользователи этой «функции» узнают и поступят правильно (чего вы не знаете заранее).
источник