"x와 y 사이"는 정식이어야합니까?

26

내 응용 프로그램에는 데이터를 필터링하는 데 사용할 수있는 미리 정의 된 식 템플릿이 있습니다. 그들 중 하나는 " 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에서 연산자가 정식 적이 지 않다는 것을 의미합니다.

그렇다면 " between x and y"은 정식이어야 한다는 QA의 권리 입니까?

requirements

— pkalinow
소스

11

아니요, 그러나 누군가가 잘못 입력하면 UI가 빨간색으로 바뀌어야합니다.

— Ewan

3

또한 오버랩없이 100-> 200 200-> 300 등을 체인 할 수 있도록> = <= 배타적이어야합니다.

— Ewan

23

between더 낮은 값과 더 높은 값을 포함하거나 제외해야하는지 명확하지 않습니다 . 품질 보증 담당자는 현혹적일 수 있지만 불확실성이있는 한 누군가가 사용자 스토리 / 요구 사항을 명확히해야하는 경우. 그들이 행해지는 방식은 그것이 어떻게되어야하는지 결정될 수 있지만, 결정이 내려져야합니다.

— 벤트

11

옳고 그른 경우는 아닙니다. 비즈니스가 애플리케이션의 작동을 원하는 방식은 무엇입니까? 대답은 어떤 기능이 기대 되는가입니다. 기술 토론은 필요한 기능을 주도하지 않습니다. 필수 기능은 기술 토론을 주도하고 비즈니스에 가장 적합한 솔루션을 제공하기를 희망합니다.

— 브래드 토마스

2

이 질문은 프로그래머가 기대하는 것보다 사용자가 기대하는 것에 관한 것입니다. 따라서 사용자 경험 에 더 적합합니다 .

— Makyen

32

현재 사양에서이 정의를 정의하지 않은 경우 동작은 완전히 임의적이며 "올바른"또는 "잘못된"정의는 없습니다. 따라서 QA 엔지니어가이 동작이 정의 된 사양의 정확한 단락을 가리킬 수없는 경우 요청을 거부 할 수 있습니다 (요청을 구현하는 데 많은 노력이 필요한 요구 사항은 아닌 것 같습니다). 둘 다 합의를 찾지 못하면 팀의 한 사람이 응용 프로그램과 관련하여 더 중요한 것을 결정해야합니다.

SQL 표준을 최대한 밀접하게 준수
인체 공학, 특정 사용 사례 또는 기타 요구 사항으로 인해 따르지 않음

팀이 내린 결정이 무엇이든, 그 행동과 결정 이유를 문서화하는 것이 좋습니다.

— 닥 브라운
소스

57

당신은 아마 그의 요청을 거부 할 수 있습니다 => 나는 실제로 가장 먼저 행동을 정의해야한다고 말합니다. 그런 다음 문제를 지적 해 주신 QA 담당자에게 감사하고 이제는 <특정 방식>으로 작동하도록 지정되어 있습니다 (코드가 사양과 일치하는지 확인).

— Matthieu M.

1

@MatthieuM. 나는 그것이 33 개의 공감대를 가져야하는 별도의 답변이라고 생각합니다. ;)

— jpmc26

1

버그를 개선으로 변환하고 영구성을 위해 백 로그에 남겨 둡니다. 근면 한 QA에 감사드립니다.

— 샌디 채프먼

1

@MatthieuM. 그렇습니다. 이상적인 세상에서는 모든 세부 사항에 대한 명확한 요구 사항이 있습니다. 이 경우 Stack Exchange에 대해 질문 할 필요가 없습니다. :)

— pkalinow

@ pkalinow : 내 의견을 오해했다고 생각합니다. 내 요점은 그 것이었다 전에 버그 닫기 (1) 지정되지 않은 코드를 지적 해준 QA 담당자에게 감사하고 (2) 실제로 동작을 지정하려는 사람과 함께 앉아 있어야한다는 것입니다. 이는 사양을 작성하는 담당자, 제품 소유자 등이있는 경우 QA 보고서를 제품 소유자에게 할당하는 것을 의미 할 수 있습니다. 그런 다음 동작이 동의되면 소프트웨어 변경이 필요한지 여부를 평가할 수 있습니다 또는 아닙니다. 아마도 소프트웨어를 바꾸는 것을 의미 할 수도 있고, 보고서를 닫는 것을 의미 할 수도 있습니다 ...

— Matthieu M.

13

이것은 유용성 또는 사용자 경험 질문입니다. SQL이나 다른 시스템의 작동 방식은 관련이 없습니다. 문제는 사용자 관점에서 가장 의미가있는 것입니다.

현재 동작은 사용자 관점에서 의미가 없습니다. 어느 X 및 Y는 교체되어야되거나 Y는 X보다 큰 선택하도록 허용해서는 안된다. x를 y보다 크게 허용하지만 빈 세트를 반환하면 아무런 이점이없는 불필요한 오류 가능성이 발생합니다.

따라서 품질 보증 엔지니어는 결함이 있지만 제안 된 솔루션이 반드시 최상의 것은 아닙니다. 사용성 테스트를 수행하여이를 결정하거나 최소한 일부 대표 사용자에게 가장 자연스러운 것을 물어보십시오.

또는 https://ux.stackexchange.com/ 에서 질문 할 수 있습니다 . 저기있는 사람들은 실제로 사용자 경험에 대해 한두 가지를 알고 있습니다.

— 자크 B
소스

11

현명한 선택이 몇 가지 있으며 선택할 시스템의 나머지 부분과 사용자의 기대에 따라 선택할 수 있습니다.

품질 관리 엔지니어가 지적한대로 표현식을 정식으로 변환하면 번역이

between x and y => value >= min(x, y) and value <= max(x, y)

유효한 사용을 다음으로 제한 할 수 있습니다 x <= y UI에서 가능한 한 빨리 "유효한 표현식이 아닙니다"를 표시 할 수 있어야합니다.

위의 변형으로, x < y표현이 equals x있고 평가하는 것을 선호하는 경우 제한value >= x and value <= x

— 칼 레스
소스

참고 : 진술 자체를 작성하지 마십시오 value >= min(x, y) and value <= max(x, y). 데이터베이스 서버 작업을 저장하기 위해 무엇을 할 수 있는지 미리 계산하십시오 (특히 중복 된 경우) (관련 작업을 한 번 수행하고 이에 따라 두 결과를 모두 설정할 수 있음). 그것은 데이터베이스 서버와의 특정 값을 당신에게있는 거 먹이에 따라 문제가되지 않을 수 있지만, 잘못 작성된 SQL 서버는 잘을 수행 할 수 min및 max대한 모든 레코드 당신이에 넣어 경우 where, 당신은 그 노력을 제거 할 수있는 경우 하지 말아야 할 이유가 없습니다.

— 기금 모니카의 소송

6

QPaysTaxes를 듣지 마십시오. 필요성을 측정하지 않고 물건을 최적화하는 것은 Knuth가 "모든 악의 근원을 조기에 최적화하는 것"이라고 정확히 부르는 것입니다. 대부분의 실제 코드에서는 가능성이 높으며 모든 레코드에 대해 최소 및 최대가 계산되면 속도의 차이를 느끼지 못하지만 사전 계산 값 (따라서 추가 코드 및 여분의 중복성을 도입)으로 인해 프로그램 유지 관리가 훨씬 어려워집니다.

— Doc Brown

나는 우리가 측정하지 않고 잠재적 인 성능 향상을 위해 변경하지해야한다고 동의하지만, 당신의 주장에 반하는 @DocBrown 나는 한 줄보다 더 많은 읽을 수있어 경계를 미리 계산 찾을 것 보다 유지 보수.

— Jacob Raihle

@JacobRaihle :이 의견을 고집,하지만 내 취향 될 수 있습니다 value >= min(x, y) and value <= max(x, y)로 읽을 같다 value >= minXY and value <= maxXY곳 minXY과 maxXY미리 계산 된 경계가 있습니다. 그러나 후자는 새로운 두 변수를 시스템에 추가하고 미리 채우고 x와 y가 변경 될 때 이러한 값을 업데이트하는 것을 잊지 마십시오. 중복 데이터는 항상 특정 오류 위험을 초래합니다.

— Doc Brown

5

스크립트에 의해 경계가 생성되는 비대화 형 설정에서는 일반적으로 경계를 정해야합니다. 이렇게하면 유효성 검사가 한 번 덜 수행되고 의미 상 더 의미가 있으며 관리하기가 쉽지 않습니다.

대화식 설정에서 사용자를 도와 주려고합니다. 가능하면 교체 된 범위를 입력 할 수없는 GUI를 만들거나 범위를 순서대로 입력하는 것이 가장 쉬운 GUI를 만드십시오. 텍스트로 범위를 입력하는 경우 유용성의 모범 인 vim에서 페이지를 가져 와서 반전 된 범위를 자동으로 바꾸도록 사용자에게 프롬프트하십시오.

Backwards range given, OK to swap (y/n)?

QA 엔지니어가 UX 방식으로 거꾸로 범위를 보여주는 것이 바람직하지 않다면 합리적인 가정을 세웠습니다.

— 칼 빌레펠트
소스

2

솔직히? "사이"를 사용하지 마십시오. 조금도.

첫째,이 용어는 특히 영어로 매우 모호합니다. 정류인가? 배타적 인 용어입니까? 포함한?

둘째, 백엔드와 분리 된 인터페이스를 수행하는 경우 백엔드 동작에 대해 걱정하지 마십시오. 또한 사용자가 상속 된 행동을 가정하지 않도록합니다. 물론 SQL은 BETWEEN포괄적 인 것으로 정의 하지만 이것은 거의 원하는 동작이 아닙니다 (예 : 행 rows BETWEEN :start and :start + :stride을 얻는 것과 같은 일을하는 경우 stride + 1).

대신, 엔드 포인트에 대한 비교를 명시 적으로 나열해야합니다. "x보다 크거나 같습니다". "오늘 전에". 모호성을 제거합니다. 또한 깔끔한 코드를 작성하는 데 도움이되고 교활한 오류를 피할 수 있습니다. 이전 행 예제는 기본적으로 Djikstra의 인덱싱 게시물 입니다. 또한 SQL이 일부 유형에서 포괄적 인 상한을 사용하도록 허용 하면 잘못된 데이터가 선택 될 수 있습니다 .

— 시계 뮤즈
소스

생각해 볼 가치가 있습니다. 그리고 링크 주셔서 감사합니다. Dijkstra의 게시물은 아마 관련성이 없지만 흥미 롭습니다 :)

— pkalinow

이것은 실제로 OP 질문에 답하지 않고 혼란을 더합니다.

— Roland Tepp

1

누가 "옳고"누가 "잘못"했는지에 대해 품질 보증팀과 논쟁하는 것은 비생산적입니다. 스펙과 다르게 해석했습니다. 즉, 사양이 명확해야하기 때문에 사양이 충분히 모호하다는 것을 의미합니다.

사용자 인터페이스가 사양이고 QA가 예상하는 동작이 아닌 경우 적어도 일부 사용자가 기대하는 동작이 아닙니다. 그것은 PEBKAC를 주장하고 싶더라도 유용성 문제를 나타냅니다. QA와 협력하여 만족스러운 솔루션을 찾으십시오.

일반적으로 명확하지만 보이지 않는 "사이"와 같은 단어에주의하십시오. 출퇴근 여부에 대한 귀하의 의견 불일치 이외에도, 그들은 어느 쪽이든 포용성에 문제가 있으며, 직관적으로 다른 영역에서 다른 것을 의미 할 수 있습니다 (예 : "금요일과 월요일 사이")는 "월요일과 월요일 사이"와 다른 사람들을 의미합니다 금요일")

— 마틴
소스

1

간단한 인터페이스에 대해 이야기하는 UNIX 원칙을 설명하겠습니다.

당신이 외부 세계에 제공하는 인터페이스가있는 곳에는, 가능한 한 가장 놀라운 것을 유지하십시오!

문제 진술을 좀 더 실용적인 것으로 축소 했으므로 숫자 범위를 지정할 때 작은 것을 전자로 유지하는 것이 분명하다는 것을 깨닫는 데 약간의 시간이 걸릴 것이라고 생각합니다. 여전히 수수께끼라면 다음과 같이 생각하십시오. 두 번의 숫자를 나타내는 역 방법을 사용하여 아이들에게 그 숫자를 비교하는 방법을 말한 적이 있습니까?

품질 보증 엔지니어가 버그라고 부르는 경우 사소한 일에 값 비싼 에너지를 방출 할 수있는 방법이 아니라 실제 버그를 예상하고 있다고 정중하게 말하십시오.

— an4
소스

0

디버그 코드가 잘못된 순서로 값을 전달할 때마다 오류 조건을 발생 시키거나 경고를 기록하십시오. 이를 통해 호출 코드는 필요한 경우 매개 변수를 확인하고 교환 할 수 있습니다. 이런 식으로이 '기능'사용자는 사전에 알지 못하는 올바른 일을 인식하고 수행합니다.

— 그리말디
소스