ทีมงานควบคุมคุณภาพควรทำการทดสอบในรูปแบบการแยกสาขาของ Gitflow


23

เราเป็นทีมใหญ่ (นักพัฒนา 10-12 คนและ 4 คน) ทำงานหลายโครงการด้วยที่เก็บ git เดียวกัน มันเป็นบริการเว็บแบ็กเอนด์ในฤดูใบไม้ผลิตาม เรากำลังมองหาการแยกทางและใช้กลยุทธ์ที่ดี นอกจากนี้เรายังมีทีมงาน qa ที่ทำให้มั่นใจว่าคุณสมบัติของเราทำงานได้ตามที่คาดไว้ (ปราศจากข้อบกพร่องในระดับหนึ่ง)

หลังจากอ่านบทความไม่กี่ฉันรู้สึกว่าแบบจำลองGitflowทำงานได้ดีสำหรับเรา ที่นี่คำถามของฉันมา

ทีม QA ของเราควรทดสอบคุณสมบัติของเราที่ไหน?

  1. พวกเขาควรทดสอบสาขาคุณลักษณะที่พวกเขาจะเพิ่มข้อผิดพลาดและนักพัฒนาจะแก้ไขและเมื่อผ่านการทดสอบ QA เรารวมการพัฒนา และ QA จะทำการทดสอบจำนวนเต็มอีกครั้งในสาขาที่กำลังพัฒนา
  2. เราควรรวมคุณสมบัติทั้งหมด (หลังการทดสอบหน่วยและการทดสอบพื้นฐานจากผู้พัฒนา) เพื่อพัฒนาสาขาและให้ทดสอบ qa จากที่นั่น การแก้ไขและการทดสอบทั้งหมดจะเกิดขึ้นในการพัฒนาเช่นกัน

ฉันอยากรู้ว่าวิธีการใดที่ทำงานได้ดีสำหรับผู้อื่น

คำตอบ:


14

QA น่าจะทำการทดสอบสองครั้ง

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

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

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


2
ข้อกังวลเล็กน้อยที่ฉันมีกับวิธีนี้คือ 1) ทุก ๆ คุณสมบัติจะต้องใช้เครื่องในการปรับใช้ บางครั้งเราทำงานบน 5 คุณสมบัติบางครั้งคู่เท่านั้น เป็นไปได้ไหมที่เราจะสามารถตั้งค่าเจนกินส์ให้หมุนวนของ VM? ทุกคนทำอะไร 2) qa จำเป็นต้องรู้ว่าบิลด์ใดอยู่บนเครื่องใด 3) ฉันสงสัยว่ามันซ้ำซ้อนหรือไม่ในขณะที่เรากำลังทำการทดสอบอย่างละเอียดในสาขาปล่อย
srini

4

เป็นคำถามที่ดีมาก ฉันไม่คิดว่าจะมีคำตอบที่ถูกต้อง 'อย่างเป็นทางการ' นี้ ขึ้นอยู่กับความเร็วในการทดสอบของคุณ

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

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

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

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

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

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

จากประสบการณ์ของฉันฉันอยากจะแนะนำ:

การทดสอบอย่างรวดเร็วของฟีเจอร์ Branch บนเครื่อง dev เพียงแค่ทำให้คุณสมบัติสมบูรณ์และผู้ทดสอบ / ผู้พัฒนาเห็นด้วยกับความต้องการ

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

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

(ผู้ชื่นชอบการต่อสู้จะบอกว่าคุณควรใส่เฉพาะการแก้ไขข้อบกพร่องใน sprint 2 แต่ให้ใช้งานได้จริง)

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


-2

ฉันเห็นด้วยกับ Thomas Owens คุณน่าจะทำการทดสอบสองครั้ง ครั้งเดียวในสาขาฟีเจอร์ก่อนที่จะถูกรวมและอีกครั้งในสาขาหลักของคุณก่อนที่คุณจะปล่อย

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

วิธีการนี้จะหมายถึงเฉพาะรหัสที่ผ่านการทดสอบโดยมนุษย์จะถึงสาขาหลักของคุณดังนั้นจึงรักษาความสมบูรณ์

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


ฉันสามารถสันนิษฐานได้ว่า downvote นั้นเป็นเพราะมีบางคนที่ทำผิดฉันถึงพูดถึงเครื่องมือของตัวเอง เครื่องมือนี้ระบุถึงข้อกังวลของ OP ที่แสดงออกมาในความคิดเห็นของคำตอบของ Thomas Owen ดังนั้นฉันไม่แน่ใจว่า downvote นั้นได้รับการรับประกัน
nlyn

ดูเหมือนโฆษณาสำหรับเครื่องมือที่ไม่ใช่ฟอสส์ของคุณดังนั้น downvotes ฉันจะให้อีกคนหนึ่งถ้าฉันทำได้
JohannesM
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.