หากดำเนินโครงการโดยใช้ BDD ที่มีเนื้อหาครอบคลุม 100% ของเรื่องราวของผู้ใช้ด้วยการทดสอบการยอมรับอัตโนมัติสิ่งที่จะเป็นบทบาทของผู้ทดสอบ / ประกันคุณภาพ
ฉันเดาว่าฉันจะจินตนาการว่านักพัฒนาจะเขียนการทดสอบการยอมรับร่วมกับเจ้าของผลิตภัณฑ์แจ้งให้เราทราบหากนั่นดูเหมือนว่าเป็นข้อสมมุติที่โง่เขลา
คำตอบ:
บางทีฉันอาจจะล้าสมัยเกินไป แต่ถึงแม้เทคนิคการพัฒนาหรือการพัฒนาที่ทันสมัยที่สุดจะไม่สามารถทดแทนดวงตาชุดใหม่ดวงตาที่สดใสก่อนปล่อยผลิตภัณฑ์ให้กับลูกค้าของคุณ
แม้ว่าผลิตภัณฑ์ของคุณจะเป็นเพียงแค่ API สำหรับนักพัฒนารายอื่นคุณสามารถใช้ QA เพื่อคิดว่าเป็นผู้ใช้ API โดยมีสถานการณ์ทดสอบ / ใช้งานที่คุณหรือลูกค้าของคุณไม่ได้คิดล่วงหน้า
หากผลิตภัณฑ์ของคุณหนักขึ้นอยู่กับส่วนต่อประสานผู้ใช้คุณต้องการคนอื่น (ไม่ใช่คุณหรือคนในทีมของคุณ) เพื่อดูผลลัพธ์สุดท้ายก่อนที่จะส่งไปยังลูกค้า
เช่นเดียวกับคำฮิตอื่น ๆ ในอุตสาหกรรมของเรา BDD - แม้จะมีความคุ้มครอง 100% - คือไม่มี bullet
ความครอบคลุม 100% ไม่เหมือนกับการทดสอบ 100%
ฉันเห็นคน QA ในโครงการ ATDD เป็นคนที่จะช่วยเขียนการทดสอบและทำการทดสอบประเภทอื่นที่ยังคงมีอยู่ Ie UI การทดสอบการทดสอบการทำลายและการทดสอบโหลด / ความเครียด
แต่ฉันไม่เคยทำโครงการ ATDD เลย
งานของ QA คือการทำลายแอปพลิเคชันงาน devs คือการไม่ทำลายมัน ดังนั้นพวกเขาจึงเขียนการทดสอบจากมุมมองที่ต่างออกไป เช่น devs เขียนการทดสอบเพื่อดูว่าพฤติกรรมที่คาดหวังเกิดขึ้น QA เขียนการทดสอบเพื่อดูว่าเกิดอะไรขึ้นเมื่อผู้ใช้ทำสิ่งที่นักพัฒนาจะไม่พิจารณาว่าผู้ใช้จะทำ นอกจากนี้นักพัฒนามักตีความผิดข้อกำหนดและการทดสอบ QA จะจับเมื่อการตีความของพวกเขาแตกต่างจากสิ่งที่นักพัฒนาคิดว่ามันหมายถึงแล้วร่วมกับผู้มีส่วนได้เสียโครงการเพื่อตรวจสอบว่าการตีความที่ถูกต้อง การทดสอบที่เขียนโดย devs ผู้เขียนโค้ดมักจะมีจุดบอดใหญ่เนื่องจาก dev นั้นมีจุดบอดใหญ่ ตัวอย่างเช่นอาจทดสอบว่าเกิดอะไรขึ้น 97% ของเวลา แต่ไม่ใช่กรณีขอบ
ที่นายจ้างคนก่อนหน้าบทบาทของ QA คือการไม่ทดสอบผลิตภัณฑ์ แต่เพื่อรับประกันว่านักพัฒนาได้ทำสิ่งที่พวกเขากล่าวว่าพวกเขากำลังจะทำเกี่ยวกับการทดสอบการยอมรับที่กำหนดไว้ก่อนหน้าซึ่งกำหนดโดย QA
เจ้าของผลิตภัณฑ์ในทางกลับกันไม่มีอะไรเกี่ยวข้องกับการทดสอบ การจัดการกับการทดสอบในทุกระดับ IMHO ไม่ใช่บทบาทของเจ้าของผลิตภัณฑ์
ในบางจุดคุณต้องมีความมั่นใจในพนักงานของคุณ การตรวจสอบและถ่วงดุลเป็นสิ่งที่ดี แต่คุณไม่ควรบังคับให้มีการแก้ปัญหาในวงจรการพัฒนาซึ่งในความเป็นจริงแล้วจะกล่าวถึงเพียงส่วนย่อยของพนักงานในการทำงานด้านจริยธรรม
ในโลกที่สมบูรณ์แบบฉันเห็นการทำงานร่วมกันกับ dev และ QA อย่างเป็นทางการด้วยการเขียนการทดสอบการยอมรับในลักษณะร่วมกัน QA ควรนำมุมมองที่แตกต่างไปสู่ตารางเช่นเดียวกับทีมพัฒนา การประกันคุณภาพควรมีมือของพวกเขาในวงกลมที่วัยเด็กของผลิตภัณฑ์และยังคงมีส่วนร่วมตลอดทั้งวงจร เจ้าของผลิตภัณฑ์ในทางกลับกันควรมีส่วนร่วมควบคุมคุณภาพเพื่อทำความเข้าใจเกี่ยวกับสถานะปัจจุบันของผลิตภัณฑ์คือความเสี่ยง ฯลฯ ... และมุ่งเน้นไปที่ผลิตภัณฑ์ในลักษณะองค์รวม; ไม่ใช่ความแตกต่างเฉพาะที่ทำขึ้นผลิตภัณฑ์
จากประสบการณ์ของฉัน: เราใช้การทดสอบหน่วยเพื่อครอบคลุมโค้ดมากกว่า 90% นอกจากนี้ยังมีการทดสอบการรวมและการสร้างรายชั่วโมง การทดสอบ jBehave สำหรับ BDD
บทบาท QA: - การนำเรื่องราวของผู้ใช้มาใช้ในการทดสอบ - การเขียนโค้ดหลังขั้นตอน - การทดสอบการสำรวจโดยใช้ปลั๊กอิน RestClient สำหรับ IDEA (ดังนั้นเราจึงพบข้อบกพร่องที่สำคัญบางอย่าง)
ส่วนหนึ่งของ BDD กำลังใช้วิธี 3 Amigos ซึ่งผู้มีส่วนได้ส่วนเสียทำงานร่วมกันเพื่อสร้างเกณฑ์การยอมรับ QA / Dev สามารถเขียนรหัสขั้นตอนเพื่อให้สถานการณ์ดำเนินการตามการทดสอบการยอมรับ มูลค่าของ QA ในการดำเนินการทดสอบการยอมรับแบบเดียวกันที่เครื่องมือ BDD จะดำเนินการโดยอัตโนมัติอยู่ที่ไหน การเพิ่มมูลค่าของ QA คือการตรวจสอบการทดสอบการยอมรับเหล่านั้นและดำเนินการทดสอบเชิงสำรวจด้วยตนเองนอกการทดสอบการยอมรับสคริปต์ การทำสำเนามักจะให้ผลลัพธ์เดียวกัน
นักพัฒนาไม่ได้เขียนข้อกำหนดและข้อกำหนดใหม่ QA ไม่ต้องเขียนรหัสแอพใหม่อีกครั้ง ... เป็นไปได้ที่ QA จะไม่ต้องทำการทดสอบสคริปต์แบบเดียวกับที่นักพัฒนาใช้ในการทดสอบการยอมรับ ถึงเวลาแล้วที่ Devs จะสวมหมวก QA!