ควร“ ระหว่าง x และ y” ควรสลับกันหรือไม่

26

ในแอปพลิเคชันของฉันมีเทมเพลตนิพจน์ที่กำหนดไว้ล่วงหน้าที่สามารถใช้กรองข้อมูลได้ หนึ่งในนั้นคือ " between x and y" วิศวกรควบคุมคุณภาพอ้างว่ามีข้อบกพร่องในคำจำกัดความเนื่องจาก " 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" ควรสลับกันหรือไม่

requirements

— pkalinow
แหล่งที่มา

11

ไม่ แต่บางที UI ของคุณควรเปลี่ยนเป็นสีแดงเมื่อมีคนเติมผิด

— Ewan

3

นอกจากนี้ยังเป็นหนึ่งในนั้น> = <= ควรเป็นแบบพิเศษเพื่อให้คุณสามารถเชื่อมโยง 100-> 200 200-> 300 ฯลฯ โดยไม่ทับซ้อนกัน

— Ewan

23

ไม่ชัดเจนว่าbetweenควรรวมหรือแยกค่าต่ำและสูงกว่า บุคคล QA อาจเป็นคนคล่องแคล่ว แต่ตราบใดที่มีความไม่แน่นอนที่ใครบางคนจำเป็นต้องชี้แจงเรื่องราว / ข้อกำหนดของผู้ใช้ มันอาจกลายเป็นว่าสิ่งที่พวกเขาทำมันคือวิธีที่ควรจะเป็น แต่ต้องมีการตัดสินใจ

— Bent

11

มันไม่ใช่กรณีของถูกหรือผิด เป็นกรณีของ ... ธุรกิจต้องการให้แอปพลิเคชันทำงานอย่างไร คำตอบคือสิ่งที่คาดว่าจะทำงาน การถกเถียงทางเทคนิคไม่ได้ทำให้เกิดการใช้งานที่จำเป็น ฟังก์ชั่นที่ต้องการผลักดันการถกเถียงทางเทคนิคและหวังว่าจะเป็นแรงบันดาลใจให้ทางออกที่ดีที่สุดสำหรับธุรกิจ

— แบรดโธมัส

2

คำถามนี้เกี่ยวกับสิ่งที่ผู้ใช้คาดหวังมากกว่าสิ่งที่โปรแกรมเมอร์คาดหวัง ดังนั้นจะเหมาะสมกับประสบการณ์ผู้ใช้มากขึ้น

— Makyen

32

หากข้อมูลจำเพาะปัจจุบันของคุณไม่ได้กำหนดไว้พฤติกรรมดังกล่าวจะเป็นไปโดยพลการไม่มีข้อกำหนด "ถูกต้อง" หรือ "ผิด" ดังนั้นหากวิศวกรควบคุมคุณภาพของคุณไม่สามารถชี้ให้คุณเห็นถึงย่อหน้าที่ถูกต้องในสเปคที่มีการกำหนดพฤติกรรมนี้คุณอาจปฏิเสธคำขอของเขาได้ หากคุณทั้งสองไม่สามารถหาฉันทามติคนในทีมของคุณจะต้องตัดสินใจว่าอะไรสำคัญกว่าในบริบทของแอปพลิเคชัน:

ทำตามมาตรฐาน SQL ให้ใกล้เคียงที่สุด
ไม่ปฏิบัติตามเพราะการยศาสตร์การใช้งานเฉพาะกรณีหรือข้อกำหนดอื่น ๆ

ไม่ว่าทีมของคุณจะตัดสินใจอะไรก็ตามมันอาจเป็นความคิดที่ดีที่จะจัดทำเอกสารพฤติกรรมและเหตุผลที่ทำให้การตัดสินใจเกิดขึ้น

— หมอบราวน์
แหล่งที่มา

57

คุณอาจปฏิเสธคำขอของเขาได้ => ฉันจะบอกว่าจริงแล้วสิ่งแรกคือพฤติกรรมที่ควรกำหนด จากนั้นคุณสามารถขอบคุณ QA guy สำหรับการชี้ให้เห็นปัญหาและบอกว่าตอนนี้มันถูกระบุให้ทำงานใน <วิธีเฉพาะ> (และตรวจสอบให้แน่ใจว่ารหัสตรงกับข้อมูลจำเพาะ)

— Matthieu M.

1

@MatthieuM ฉันคิดว่านั่นเป็นคำตอบที่แยกต่างหากที่ควรมี 33 upvotes ของตัวเอง ;)

— jpmc26

1

แปลงข้อผิดพลาดเพื่อปรับปรุงและเก็บไว้ใน Backlog เพื่อความยั่งยืน ขอบคุณ QA สำหรับความขยันของพวกเขา

— Sandy Chapman

1

@MatthieuM ใช่ในโลกอุดมคติจะมีข้อกำหนดที่ชัดเจนสำหรับทุกรายละเอียด ในกรณีเช่นนี้ฉันจะไม่ต้องถามคำถามเกี่ยวกับกองแลกเปลี่ยน :)

— pkalinow

@pkalinow: ฉันคิดว่าคุณเข้าใจผิดความคิดเห็นของฉัน ประเด็นของฉันคือก่อนที่จะปิดบั๊กคุณควร (1) ขอบคุณผู้ควบคุมคุณภาพที่ชี้ให้เห็นถึงโค้ดที่ไม่ได้ระบุไว้และ (2) นั่งด้วยกันกับใครก็ตามที่สนใจที่จะระบุพฤติกรรมจริง ๆ นี่อาจหมายถึงการมอบหมายรายงาน QA ให้กับผู้ที่รับผิดชอบในการเขียนข้อกำหนดให้กับเจ้าของผลิตภัณฑ์หากคุณมีสิ่งต่าง ๆ เช่นนั้น ... จากนั้นเมื่อพฤติกรรมที่ควรได้รับการตกลงกันคุณสามารถประเมินได้ว่าซอฟต์แวร์ต้องการการเปลี่ยนแปลงหรือไม่ หรือไม่. บางทีมันอาจหมายถึงการเปลี่ยนซอฟต์แวร์บางทีมันอาจหมายถึงการปิดรายงาน ...

— Matthieu M.

13

นี่เป็นคำถามการใช้งานหรือประสบการณ์ผู้ใช้ การทำงานของ SQL หรือระบบอื่น ๆ นั้นไม่เกี่ยวข้องกับคำถามนั้นเป็นสิ่งที่เหมาะสมที่สุดจากมุมมองของผู้ใช้

พฤติกรรมปัจจุบันไม่สมเหตุสมผลจากมุมมองของผู้ใช้ ทั้ง x และ y ควรจะใช้แทนกันได้หรือไม่ก็ไม่ควรได้รับอนุญาตให้เลือก x ขนาดใหญ่กว่าปี การอนุญาตให้ x มีขนาดใหญ่กว่า y แต่การส่งคืนเซตว่างจะทำให้เกิดข้อผิดพลาดที่ไม่จำเป็นโดยไม่ให้ประโยชน์ใด ๆ

ดังนั้นวิศวกร QA นั้นถูกต้องมีข้อบกพร่อง แต่วิธีแก้ปัญหาที่เสนอนั้นไม่จำเป็นต้องดีที่สุด คุณต้องทำการทดสอบความสามารถในการใช้งานตัดสินใจอย่างนี้หรืออย่างน้อยก็ขอให้ผู้ใช้ตัวแทนบางคนเห็นว่าเป็นเรื่องธรรมดาที่สุดสำหรับพวกเขา

หรือคุณสามารถถามคำถามมากกว่าที่https://ux.stackexchange.com/ ผู้คนที่นั่นรู้สิ่งหนึ่งหรือสองเกี่ยวกับประสบการณ์ของผู้ใช้

— JacquesB
แหล่งที่มา

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

— Caleth
แหล่งที่มา

หมายเหตุ: value >= min(x, y) and value <= max(x, y)โปรดอย่าทำให้คำสั่งของตัวเอง ประเมินสิ่งที่คุณสามารถทำได้เพื่อบันทึกเซิร์ฟเวอร์ฐานข้อมูลของคุณโดยเฉพาะอย่างยิ่งถ้ามันซ้ำซ้อนเช่นนั้น (คุณสามารถดำเนินการที่เกี่ยวข้องเพียงครั้งเดียวและตั้งค่าผลลัพธ์ทั้งคู่ให้สอดคล้องกัน) มันอาจไม่สำคัญขึ้นอยู่กับเซิร์ฟเวอร์ฐานข้อมูลและค่าเฉพาะที่คุณป้อน แต่เซิร์ฟเวอร์ SQL ที่เขียนไม่ดีอาจทำงานได้ดีminและmaxสำหรับทุกเร็กคอร์ดหากคุณใส่ไว้ในwhereและถ้าคุณสามารถใช้ความพยายามนั้นได้ ไม่มีเหตุผลที่จะไม่ทำ

— คดีฟ้องร้องกองทุนโมนิก้า

6

โปรดอย่าฟัง QPaysTaxes การเพิ่มประสิทธิภาพของสิ่งต่าง ๆ โดยไม่ต้องวัดความจำเป็นนั้นเป็นสิ่งที่ Knuth เรียกว่า "การเพิ่มประสิทธิภาพผึ้งก่อนกำหนดโดยการหยั่งรากของความชั่วร้ายทั้งหมด" โอกาสสูงมากในรหัสโลกแห่งความเป็นจริงคุณจะไม่สังเกตเห็นความแตกต่างของความเร็วถ้ามีการคำนวณ Min และ Max สำหรับทุกเร็กคอร์ด แต่ค่าการคำนวณล่วงหน้า (และการแนะนำรหัสพิเศษและความซ้ำซ้อนพิเศษ) จะทำให้โปรแกรมนั้น

— Doc Brown

@DocBrown ฉันยอมรับว่าเราไม่ควรทำการเปลี่ยนแปลงสำหรับการเพิ่มประสิทธิภาพที่เป็นไปได้โดยไม่ต้องวัด แต่ตรงกันข้ามกับการเรียกร้องของคุณฉันจะพบว่าขอบเขตที่คำนวณไว้ล่วงหน้าสามารถอ่านได้ง่ายกว่าหนึ่งซับและทำให้สามารถบำรุงรักษาได้มากขึ้น

— Jacob Raihle

@JacobRaihle: นี่อาจจะเป็นความเห็น แต่สำหรับรสนิยมของฉันvalue >= min(x, y) and value <= max(x, y)เป็นที่อ่านได้เป็นvalue >= minXY and value <= maxXYที่ไหนminXYและmaxXYมีขอบเขต precalculated อย่างไรก็ตามสำหรับอันหลังจะต้องเขียนโค้ดบางอย่างเพื่อเพิ่มตัวแปรใหม่สองตัวนี้ลงในระบบให้เติมไว้ล่วงหน้าอย่าลืมอัปเดตค่าเหล่านี้เมื่อ x และ y เปลี่ยนไปเรื่อย ๆ ข้อมูลที่ซ้ำซ้อนทำให้เกิดความเสี่ยงต่อข้อผิดพลาดได้เสมอ

— Doc Brown

5

ในการตั้งค่าแบบไม่โต้ตอบที่ขอบเขตของคุณจะถูกสร้างขึ้นโดยสคริปต์มันมักจะทำให้รู้สึกถึงความต้องการที่จะต้องอยู่ในลำดับ สิ่งนี้สร้างการตรวจสอบความถูกต้องน้อยกว่าหนึ่งการตรวจสอบทำให้มีความหมายมากขึ้นและมีความสำคัญต่อการจัดการ

ในการตั้งค่าแบบโต้ตอบคุณต้องการช่วยเหลือผู้ใช้ หากเป็นไปได้ให้สร้าง GUI ที่ไม่อนุญาตให้มีการสลับช่วงหรืออย่างน้อยก็ทำให้ง่ายที่สุดในการป้อนช่วงตามลำดับ หากคุณกำลังเข้าสู่ช่วงด้วยข้อความให้นำหน้าจากกลุ่มที่มีประโยชน์การใช้งานนั้นและแจ้งให้ผู้ใช้สลับช่วงที่กลับรายการโดยอัตโนมัติ:

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

หากวิศวกรควบคุมคุณภาพของคุณไม่มีอะไรในทางของ UX ที่จะแสดงให้เขาเห็นว่าช่วงกลับหัวจะไม่เป็นที่พึงปรารถนาจากนั้นเขาก็ตั้งสมมติฐานที่สมเหตุสมผล

— Karl Bielefeldt
แหล่งที่มา

2

ตรงไปตรงมา? อย่าใช้ "ระหว่าง" เลย

อย่างแรกคำศัพท์ไม่ชัดเจนอย่างไม่น่าเชื่อโดยเฉพาะในภาษาอังกฤษ มันเป็นการสลับหรือไม่ เงื่อนไขเป็นพิเศษหรือไม่? Inclusive?

ประการที่สองถ้าคุณทำอินเทอร์เฟซที่หย่าจากแบ็กเอนด์ไม่ต้องกังวลกับพฤติกรรมแบ็กเอนด์ และอย่าให้ผู้ใช้ของคุณรับพฤติกรรมที่สืบทอดมาเช่นกัน แน่นอนว่า SQL จะกำหนดให้BETWEENเป็นแบบรวม แต่แทบจะไม่เคยมีพฤติกรรมที่ต้องการ (ตัวอย่างเช่น - ถ้าคุณทำบางอย่างเช่นrows BETWEEN :start and :start + :strideคุณจะได้stride + 1แถวมา)

คุณควรแสดงรายการการเปรียบเทียบสำหรับปลายทางอย่างชัดเจน "มากกว่าหรือเท่ากับ x" "ก่อนวันนี้" สิ่งนี้จะลบความกำกวม นอกจากนี้ยังช่วยเขียนโค้ดที่สะอาดขึ้นและหลีกเลี่ยงข้อผิดพลาดที่ร้ายกาจ ตัวอย่างแถวจากก่อนหน้านี้เป็นหลักโพสต์ Djikstra เกี่ยวกับการจัดทำดัชนี และการอนุญาตให้ SQL ใช้ขอบเขตบนแบบรวมบนบางประเภทอาจส่งผลให้มีการเลือกข้อมูลที่ไม่ถูกต้อง

— ลาน-Muse
แหล่งที่มา

มันก็คุ้มค่าที่จะคิด และขอบคุณสำหรับลิงค์ โพสต์ Dijkstra 'อาจไม่เกี่ยวข้องมาก แต่น่าสนใจ :)

— pkalinow

นี่ไม่ได้ตอบคำถาม OP จริง ๆ แต่จะเพิ่มความสับสน

— Roland Tepp

1

มันไม่มีประสิทธิผลที่จะโต้เถียงกับ QA ของคุณเกี่ยวกับผู้ที่ "ถูกต้อง" และผู้ที่ "ผิด" คุณตีความสเป็คแตกต่างจากที่พวกเขาทำ นั่นหมายความว่าข้อมูลจำเพาะมีความคลุมเครือเพียงพอที่จะต้องมีการชี้แจง

หากอินเทอร์เฟซผู้ใช้เป็นสเป็คและไม่ใช่พฤติกรรมที่ QA คาดไว้นั่นจะไม่เป็นพฤติกรรมที่ผู้ใช้บางคนคาดหวัง นั่นแสดงว่าเป็นปัญหาการใช้งาน (แม้ว่าคุณต้องการโต้แย้ง PEBKAC) ทำงานร่วมกับ QA ของคุณเพื่อหาทางออกที่น่าพอใจ

โดยทั่วไปควรระวังด้วยคำเช่น "ระหว่าง" ที่ดูเหมือนชัดเจน แต่ไม่ใช่ นอกเหนือจากความไม่เห็นด้วยของคุณเกี่ยวกับว่าควรจะเดินทางหรือไม่ปัญหาของพวกเขาคือความไม่แยแสต่อทั้งสองด้านและอาจหมายถึงสิ่งที่แตกต่างกันในโดเมนที่ต่างกัน (ตัวอย่างเช่น "ระหว่างวันศุกร์ถึงวันจันทร์") ศุกร์ ")

— Martijn
แหล่งที่มา

1

ฉันจะแยกหลักการ UNIX ที่พูดถึงอินเตอร์เฟสที่เรียบง่าย

ไม่ว่าจะมีส่วนต่อประสานที่คุณเสนอให้กับโลกภายนอกให้ทำสิ่งที่น่าประหลาดใจที่สุดให้น้อยที่สุด!

ตอนนี้ฉันได้ลดคำแถลงปัญหาให้เป็นจริงมากขึ้นฉันคิดว่ามันจะใช้เวลาคุณสักครู่ที่จะตระหนักว่าเมื่อระบุช่วงจำนวนมันเป็นที่ชัดเจนว่า *** ให้เล็กลงเป็นอดีต *** หากยังคงเป็นปริศนาให้คิดเช่นนี้ - คุณใช้วิธีย้อนกลับของการแสดงตัวเลขสองจำนวนกี่ครั้งในขณะที่บอกเด็ก ๆ ว่าจะเปรียบเทียบอย่างไร

หากวิศวกรควบคุมคุณภาพของคุณเรียกมันว่าบั๊กบอกเขาอย่างสุภาพว่าคุณคาดหวังข้อบกพร่องจริงๆ และไม่ใช่วิธีที่จะส่งพลังงานราคาแพงไปสู่สิ่งที่น่ารำคาญ

— an4
แหล่งที่มา

0

ทำให้รหัส debug ของคุณโยนเงื่อนไขข้อผิดพลาดหรือบันทึกคำเตือนทุกครั้งที่มันผ่านค่าในลำดับที่ไม่ถูกต้อง วิธีนี้รหัสการโทรสามารถตรวจสอบและแลกเปลี่ยนพารามิเตอร์หากจำเป็น วิธีนี้ทำให้ผู้ใช้งาน 'คุณสมบัติ' นี้จะรับรู้และทำสิ่งที่ถูกต้อง (ซึ่งคุณไม่ทราบล่วงหน้า)

— Grimaldi
แหล่งที่มา