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

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

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

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

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

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

QA ควรดูแลเรื่องนี้พร้อมกับมาตรการด้านคุณภาพอื่น ๆ เพื่อให้มั่นใจว่ากระบวนการไม่เพียง แต่ส่งมอบคุณภาพที่ต้องการ แต่ยังอยู่ในระดับประสิทธิภาพที่น่ากลัว

แก้ไข: การอ้างอิงคำถามดั้งเดิมเกี่ยวกับ QA ได้ถูกลบออกดังนั้นคำตอบนี้จะปรากฏขึ้น OT

เราใช้ UATs ตั้งแต่เริ่มต้น

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

การทำ UATs ตั้งแต่เริ่มต้นยังมีประโยชน์เพิ่มเติม มันเป็นการล้างความกำกวมใด ๆ ระหว่างความคาดหวังของลูกค้าและของคุณเอง

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

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

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

ในโลกที่สมบูรณ์แบบนั้นจะต้องมีการทดสอบหน่วย (xUnit) การทดสอบ - การทดสอบการรวมอัตโนมัติ (ซีลีเนียม) และผู้ใช้ทางธุรกิจ - การทดสอบการยอมรับ (FIT) พวกเขาสามารถเข้าถึงการทดสอบซึ่งกันและกัน

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