การแก้ไขข้อบกพร่องโดยไม่เพิ่มคุณสมบัติใหม่เมื่อปล่อยซอฟต์แวร์สำหรับการทดสอบระบบถูกต้องหรือไม่

คำถามนี้คือผู้ทดสอบที่มีประสบการณ์หรือโอกาสในการทดสอบ นี่คือสถานการณ์จำลองจากโครงการซอฟต์แวร์:

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

ซึ่งหมายความว่าทีมงาน dev ต้องสร้างสาขาของรหัสเพียงอย่างเดียวสำหรับการแก้ไขข้อบกพร่องและสาขาอื่นที่พวกเขาพัฒนาต่อไป มีการรวมค่าโสหุ้ยมากขึ้นโดยเฉพาะกับการเปลี่ยนโครงสร้างและการเปลี่ยนแปลงทางสถาปัตยกรรม

คุณเห็นด้วยไหมถ้านี่เป็นหลักการทดสอบทั่วไป ข้อกังวลของทีมทดสอบนั้นถูกต้องหรือไม่ คุณเคยพบสิ่งนี้ในทางปฏิบัติในโครงการของคุณหรือไม่

ฉันอยากบอกว่าคุณลักษณะใหม่แต่ละรุ่นควรอยู่ในสาขาแยกต่างหาก สิ่งนี้ช่วยให้การพัฒนาและการเผยแพร่ถูกแยกออก

รุ่นของคุณกับผู้ใช้ปลายทางทำงานอย่างไรในกระบวนการนี้ ทีมทดสอบระบบของคุณควรกังวลกับตารางการพัฒนาน้อยกว่าและให้ความสำคัญกับตารางการปล่อยลูกค้า

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

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

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

เราใช้วิธีไฮบริด สำหรับการเปิดตัวของลูกค้าเรามีสาขาของตัวเองซึ่งแน่นอนสำหรับการแก้ไขข้อบกพร่องที่สำคัญเท่านั้น

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

ทั้งหมดนี้ดูดีบนกระดาษ แต่ถ้าลูกค้าต้องการฟีเจอร์ที่เฉพาะเจาะจงมันจะต้องเพิ่มสาขา 2.0 เองเนื่องจาก 3.0 นั้นไม่เสถียรพอที่จะเปิดให้ลูกค้า ซึ่งหมายความว่าทีมงาน QA จะต้องเรียกใช้ชุดการถดถอยทั้งหมดอีกครั้ง

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

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

ต้องบอกว่ามันเป็นที่เข้าใจ (ไม่จำเป็นต้องเป็นธรรม) สำหรับผู้ทดสอบที่ต้องการทดสอบการแก้ไข 'Ceteris paribus' (ทุกสิ่ง 'อื่น ๆ ' เท่ากัน)

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

คุณสามารถแก้ปัญหานี้ได้ (โดยทั่วไป) โดยการผสานทั้งสองทีมเข้าด้วยกัน

ผู้ทดสอบภายในทีมพัฒนากำลังทำการทดสอบคุณสมบัติต่างๆสามารถช่วยทีมส่วนใหญ่ในการเพิ่มคุณภาพของผลผลิต

ผมขอแนะนำให้คุณอ่านบล็อกโพสต์ที่ยอดเยี่ยมจากเฮนริก Knibergที่อธิบายกบาล คุณจะพบแนวคิดมากมายในกระบวนการต่อสู้ (หนังสือฟรีจากHenrik Kniberg )

นอกจากนี้เขายังเขียนบทความKanban VS Scrum ที่ยอดเยี่ยมในบล็อกของเขา

สนุก.

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

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

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

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

"คุณเห็นด้วยไหมถ้านี่เป็นหลักการทดสอบทั่วไป

Yes

ข้อกังวลของทีมทดสอบนั้นถูกต้องหรือไม่

Yes

คุณพบสิ่งนี้ในทางปฏิบัติในโครงการของคุณหรือไม่ "

Yes

:

and Yes Merging is the downside of it 

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

ปัญหาคือว่าถ้าพวกเขาทดสอบข้อบกพร่องในสาขาพวกเขายังคงต้องสอบซ้ำและทดสอบการถดถอยบนลำตัวเมื่อพวกเขากลับมารวมกันอีกครั้ง สิ่งนี้ไม่เพียงทำให้นักพัฒนาซอฟต์แวร์ทำงานได้มากขึ้น แต่ยังทำงานได้มากขึ้นสำหรับผู้ทดสอบ

ไม่มีคำตอบที่ถูกต้องที่นี่ แต่บางสิ่งที่คุณควรพิจารณา:

• อาจปล่อยข้อบกพร่องเหล่านี้ (โดยไม่มีฟังก์ชั่นใหม่) เคยไปที่ผู้ใช้? ถ้าเป็นเช่นนั้นจะต้องมีการแยกและทดสอบและทุกคนต้องยอมรับว่าเป็นค่าใช้จ่าย

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

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

• มีวิธีที่ดีกว่าในการใช้การควบคุมเวอร์ชันที่นี่หรือไม่ บางอย่างเช่น Mercurial (ดูที่http://hginit.com/ - อ่านได้ดี) หรือระบบควบคุมเวอร์ชันที่กระจายสาขาอื่นและผสานเข้าด้วยกันในลักษณะที่แตกต่างกันและอาจทำให้คุณสามารถแก้ไขปัญหาได้ ลองดูที่จริงเพราะฉันคิดว่ามันอาจเป็นคำตอบสำหรับปัญหาของคุณ

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

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

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

หากคุณแก้ไขข้อบกพร่องของคุณก่อนคุณจะมีรากฐานที่แข็งแกร่งสำหรับคุณสมบัติใหม่ใด ๆ ที่คุณเพิ่ม

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

พยายามแก้ไขข้อบกพร่องก่อนที่จะเพิ่มคุณสมบัติใหม่!

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