การสร้างระบบที่ซ้ำซ้อนอย่างสมบูรณ์สำหรับการประกันคุณภาพ (QA) ของการปฏิบัติอื่นที่ไม่ดีหรือไม่

ที่ทำงานเรามีระบบที่ค่อนข้างซับซ้อน เรียกระบบนี้ว่า System_A ทีมงาน QA ของเราได้สร้างระบบอื่นเรียกระบบนี้ว่า System_B เพื่อทดสอบ System_A

วิธีที่ใช้ System_B มีดังนี้ เราสร้างอินพุต (โดยใช้ System_B เอง), IN, ประมวลผลอินพุตดังกล่าวกลับผ่าน System_B และสร้างเอาต์พุต O_B ดังนั้นกระบวนการดังต่อไปนี้:

System_B(IN) -> O_B.

จากนั้นเราก็ทำเช่นเดียวกันสำหรับ System_A เพื่อสร้างผลลัพธ์ของตัวเอง O_A:

System_A(IN) -> O_A.

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

• O_A ผิด O_B ถูกต้อง
• O_A ถูกต้อง O_B ถูกต้อง
• O_A ผิด O_B ผิด
• O_A ถูกต้อง O_B นั้นผิด

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

คำถามคือ: มันเป็นวิธีปฏิบัติที่ไม่ดีในการสร้าง "ระบบทดสอบ" เพื่อทดสอบระบบจริงหรือไม่?

• แล้วความชันลื่นล่ะ? จากนั้นเราไม่สามารถโต้แย้งได้ว่าเราต้องการระบบอื่นเพื่อทดสอบ "ระบบทดสอบ" หรือไม่?
• ค่าใช้จ่ายเป็นสิ่งต้องห้ามอย่างแน่นอนเนื่องจากนักพัฒนาจำเป็นต้องเรียนรู้อย่างน้อย 2 ฐานรหัสด้วยความซับซ้อนของ System_B อาจใหญ่กว่า System_A เราจะหาปริมาณว่าการมี System_B ไปรอบ ๆ นั้นดีหรือไม่ดีสำหรับองค์กรอย่างไร
• หนึ่งในเหตุผล "ที่น่าสนใจ" ดั้งเดิมในการสร้าง System_B คือการทดสอบ "อัตโนมัติ" ตอนนี้เราภูมิใจมากที่เราเป็นแบบอัตโนมัติ (เนื่องจาก System_B สร้างอินพุตเพื่อบู๊ตกระบวนการของการใช้ตัวเองเพื่อสร้างเอาต์พุต) แต่ฉันคิดว่าเราได้ทำอันตรายมากขึ้นและเพิ่มความซับซ้อนมากขึ้นในวิธีที่ไม่ต้องสงสัย เป็นงานของ QA ที่จะเป็นไปโดยอัตโนมัติอย่างเต็มที่? เหตุผลนั้นเพียงพอที่จะสร้างระบบคู่ขนานหรือไม่?
• ความกังวลที่แท้จริงของฉันคือสิ่งนี้แม้ว่าเราทุกคนรู้ว่า System_B นั้นผิด (บ่อยครั้ง) หาก System_B ประมวลผลอินพุตได้ดีและเอาต์พุตเป็นแหล่งทองคำทำไมไม่ลองแทนที่ System_A ด้วย System_B เพื่อให้ไม่มีใครในที่ทำงานสามารถให้การตอบสนองที่น่าพอใจ

คำแนะนำใด ๆ เกี่ยวกับปัญหานี้ชื่นชม

• O_A ผิด O_B ถูกต้อง

แก้ไข A

• O_A ถูกต้อง O_B นั้นผิด

แก้ไข B

• O_A ถูกต้อง O_B ถูกต้อง

หวังว่าพวกเขายังเห็นด้วย

• O_A ผิด O_B ผิด

หวังว่าพวกเขาจะไม่เห็นด้วยดังนั้นคุณจะรู้ว่าจะทำอะไรกับมัน

ไม่มีกระบวนการจับทุกอย่าง แน่นอนว่าคุณเพิ่มโค้ดของคุณเป็นสองเท่า แต่ลองคิดดูว่ามันเหมือนกับ 2 in O (2n) ระบบควบคุมคุณภาพอัตโนมัติทุกวิธีในการทดสอบการรวมเป็นสิ่งที่ยอดเยี่ยม การทดสอบด้วยตนเองคือการลากบนการปรับปรุง โดยเฉพาะอย่างยิ่งการเปลี่ยนแปลงตัดขวางที่ต้องการการทดสอบแบบเต็ม นอกจากนี้เนื่องจากคุณจะมีโปรแกรมเมอร์ที่แตกต่างกันดำเนินการสิ่งเดียวกันคุณสามารถให้พวกเขาแข่งขัน

มันควรจะเป็นคนที่แตกต่างกันที่จะเพิ่มโอกาสในการรับข้อผิดพลาดที่แตกต่างกัน ฉันไม่แนะนำให้สร้างระบบ B โดยการเผชิญปัญหาจากระบบ A. ทั้งหมดที่ให้คุณคือการทดสอบ regresion คุณสามารถได้สิ่งเดียวกันง่ายๆโดยบันทึกสำเนาเก่าของ O_A เพื่อเปรียบเทียบกับสำเนาใหม่

คำถามคือ: มันเป็นวิธีปฏิบัติที่ไม่ดีในการสร้าง "ระบบทดสอบ" เพื่อทดสอบระบบจริงหรือไม่?

ถ้าเป็นเช่นนั้นการทดสอบทั้งหมดจะไม่ดี

• แล้วความชันลื่นล่ะ? จากนั้นเราไม่สามารถโต้แย้งได้ว่าเราต้องการระบบอื่นเพื่อทดสอบ "ระบบทดสอบ" หรือไม่?

ใช่เราสามารถโต้แย้งได้ เราจะเรียกระบบที่ 3 นี้ว่า system_A : P

• ค่าใช้จ่ายเป็นสิ่งต้องห้ามอย่างแน่นอนเนื่องจากนักพัฒนาจำเป็นต้องเรียนรู้อย่างน้อย 2 ฐานรหัสด้วยความซับซ้อนของ System_B อาจใหญ่กว่า System_A เราจะหาปริมาณว่าการมี System_B ไปรอบ ๆ นั้นดีหรือไม่ดีสำหรับองค์กรอย่างไร

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

• หนึ่งในเหตุผล "ที่น่าสนใจ" ดั้งเดิมในการสร้าง System_B คือการทดสอบ "อัตโนมัติ" ตอนนี้เราภูมิใจมากที่เราเป็นแบบอัตโนมัติ (เนื่องจาก System_B สร้างอินพุตเพื่อบู๊ตกระบวนการของการใช้ตัวเองเพื่อสร้างเอาต์พุต) แต่ฉันคิดว่าเราได้ทำอันตรายมากขึ้นและเพิ่มความซับซ้อนมากขึ้นในวิธีที่ไม่ต้องสงสัย เป็นงานของ QA ที่จะเป็นไปโดยอัตโนมัติอย่างเต็มที่? เหตุผลนั้นเพียงพอที่จะสร้างระบบคู่ขนานหรือไม่?

ความซับซ้อนของ System_B นั้นแยกได้อย่างน่าอัศจรรย์จาก System_A การเพิ่มคุณสมบัติให้กับ System_A นั้นไม่ใช่เรื่องยากเพราะมี System_B อยู่ มันเป็น infact ง่ายขึ้นเพราะ System_B ให้ความมั่นใจในการทำงานอย่างรวดเร็ว

• ความกังวลที่แท้จริงของฉันคือสิ่งนี้แม้ว่าเราทุกคนรู้ว่า System_B นั้นผิด (บ่อยครั้ง) หาก System_B ประมวลผลอินพุตได้ดีและเอาต์พุตเป็นแหล่งทองคำทำไมไม่ลองแทนที่ System_A ด้วย System_B เพื่อให้ไม่มีใครในที่ทำงานสามารถให้การตอบสนองที่น่าพอใจ

นี่คือการพิมพ์ผิดหรือไม่? System_B ค่อนข้างผิดปกติดังนั้นมาตรฐานทองคำที่คุณต้องการใช้เพื่อแทนที่ System_A คืออะไร?

ฉันจะสมมติว่าคุณหมายถึง System_A มักผิด ไม่สำคัญว่าใครจะผิดบ่อยที่สุด สิ่งใดที่ผิดคือสิ่งที่ต้องการทำงาน ระบบเหล่านี้ไม่ได้ตัดสินใจถูกและผิดนักพัฒนาก็ทำเช่นกัน สิ่งที่ทดสอบทำคือก่อให้เกิดความไม่พอใจซึ่งหมายความว่าบางสิ่งไม่ถูกต้อง นักพัฒนาเข้าใจว่ามันคืออะไร จำไว้ว่าไม่มีมาตรฐานทองคำที่ผลิตที่นี่ มีข้อตกลงหรือไม่เห็นด้วยเท่านั้น ความไม่ลงรอยกันเรียกร้องให้งานต้องทำ ส่วนหนึ่งของงานนั้นคือการหาว่าที่ไหน

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

สิ่งนี้จะเพิ่มเป็นสองเท่าดังนั้นหากระบบของคุณมีความสำคัญต่อภารกิจและต้องพร้อมให้บริการตลอด 24/7 จากนั้นคุณไม่สามารถยืนยันความหรูหราที่จะไม่มีระบบควบคุมคุณภาพได้เพราะคุณต้องลดเวลาหยุดทำงานของระบบการผลิตให้น้อยที่สุด และถ้าเป็นระบบ 24/7 ระบบจำลองที่แท้จริงของระบบการผลิตคือคำแนะนำที่แข็งแกร่งมาก

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

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

เมื่อใดก็ตามที่คุณทดสอบระบบคุณต้องรู้ว่าผลลัพธ์ที่คุณคาดหวังคืออะไร

ปัญหาของการมีระบบสร้างผลลัพธ์ที่คาดหวังนี้ชัดเจนว่า 'ฉันจะทดสอบระบบอย่างไร'

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

ในตอนท้ายของวันแม้ว่าคุณต้องการคนที่จะตีความข้อกำหนดของระบบและสร้างผลลัพธ์ที่คาดหวังด้วยตนเอง หากคุณมีระบบทำและตรวจสอบความแตกต่างเท่านั้นแล้วคุณจะข้ามการทดสอบของคุณ