การแยกข้อบกพร่อง/ข้อบกพร่องในการทดสอบซอฟต์แวร์
ทีมบรรณาธิการ
⚡ สรุปอย่างชาญฉลาด
การคัดกรองข้อบกพร่องเป็นการประชุมทบทวนที่หัวหน้าทีมทดสอบ หัวหน้าทีมพัฒนา และผู้จัดการโครงการจะจัดลำดับข้อบกพร่องที่รายงานแต่ละรายการตามความรุนแรง ความสำคัญ และความเสี่ยง จากนั้นจึงมอบหมายผู้รับผิดชอบและตกลงกำหนดตารางการแก้ไขที่เป็นไปได้จริง
'การตรวจสอบข้อบกพร่อง' คืออะไร?
การคัดแยกข้อบกพร่อง (Defect triage) คือกระบวนการที่แต่ละข้อบกพร่องจะได้รับการจัดลำดับความสำคัญตามความรุนแรง ความถี่ ความเสี่ยง ฯลฯ คำว่า Triage ใช้ในบริบทนี้ การทดสอบซอฟต์แวร์ / ฝ่ายควบคุมคุณภาพจะกำหนดความรุนแรงและลำดับความสำคัญของข้อบกพร่องใหม่ ๆ
ชื่อนี้มีที่มาจากเวชศาสตร์ฉุกเฉิน ซึ่งการคัดแยกผู้ป่วยตามความเร่งด่วนเกิดขึ้นเมื่อทรัพยากรมีจำกัด ทีมควบคุมคุณภาพก็เผชิญกับข้อจำกัดเดียวกันนี้เช่นกัน คือ รายการข้อบกพร่องมักยาวกว่าเวลาที่มีอยู่ก่อนวันวางจำหน่าย ดังนั้นจึงต้องมีคนตัดสินใจว่าอะไรควรแก้ไขตอนนี้ อะไรควรแก้ไขในภายหลัง และอะไรควรเลื่อนออกไป การคัดแยกผู้ป่วย (Triage) คือการประชุมที่ทำการตัดสินใจและบันทึกไว้
ทำไมเราจึงต้องมี 'Defect Triage'?
เป้าหมายของ Bug Triage คือการประเมิน จัดลำดับความสำคัญ และกำหนดการแก้ไขข้อบกพร่อง ทีมงานจำเป็นต้องตรวจสอบความถูกต้องของข้อบกพร่อง ทำการเปลี่ยนแปลงตามความต้องการ สรุปการแก้ไขข้อบกพร่อง และมอบหมายทรัพยากร ส่วนใหญ่ใช้ในการจัดการโครงการแบบคล่องตัว
หากไม่มีการคัดแยกปัญหา ข้อบกพร่องก็จะยังคงอยู่ในระบบ tracปัญหาจะถูกประเมินด้วยระดับความรุนแรงตามที่ผู้ทดสอบรายงานเลือก และนักพัฒนาจะเลือกงานตามความชอบส่วนตัวมากกว่าผลกระทบทางธุรกิจ แบนเนอร์ด้านล่างสรุปเหตุผลที่ทีมยังคงกำหนดการประชุมไว้ในปฏิทิน
จำเป็นต้องดำเนินการ 'Defect Triage' ในรุ่นบ่อยแค่ไหน
ความถี่ของการประชุมคัดแยกข้อบกพร่องไม่ได้รับการแก้ไข ขึ้นอยู่กับสถานการณ์ของโครงการ
ต่อไปนี้เป็นปัจจัยสำคัญบางประการที่เป็นตัวกำหนดความถี่ของการประชุมคัดแยกข้อบกพร่อง:
ปัจจัยสำคัญเหล่านี้คือ:
- ตามกำหนดการของโครงการ
- จำนวนข้อบกพร่องในระบบ
- ผลกระทบต่อตารางความพร้อมของสมาชิกในทีม
- ความสมบูรณ์ของโครงการโดยรวม
โดยปกติแล้ว การประชุมคัดแยกข้อบกพร่องจะจัดขึ้นสองหรือสามครั้งในหนึ่งสัปดาห์
จังหวะการทำงานจะกระชับขึ้นเมื่อใกล้ถึงกำหนดปล่อยเวอร์ชันใหม่ ทีมงานจะทำงานในระยะเวลาสั้นๆ การทะเลาะกัน โดยปกติแล้ว การทำงานแบบวนซ้ำมักจะรวมการคัดกรองเบื้องต้นสั้นๆ เข้าไปในกิจวัตรประจำวันในช่วงสปรินต์สุดท้าย ในขณะที่โครงการที่มีวงจรการทำงานที่ขับเคลื่อนด้วยแผนระยะยาว อาจมีการคัดกรองสัปดาห์ละครั้งจนกว่าจะเสร็จสิ้น การทดสอบการถดถอย เฟสเริ่มต้นขึ้น
ใครคือผู้เข้าร่วมที่ได้รับมอบอำนาจและผู้เข้าร่วมรายอื่นของ 'Defect Triage'
ผู้เข้าร่วมบังคับ
สมาชิกโครงการด้านล่างนี้จะมีส่วนร่วมในการประชุม Defect Triage เสมอ
- Project Manager
- หัวหน้าทีมทดสอบ
- หัวหน้าฝ่ายเทคนิค
- หัวหน้าทีมพัฒนา
ผู้เข้าร่วมทางเลือก
- นักพัฒนา
- ทดสอบ
- นักวิเคราะห์ธุรกิจ
ผู้เข้าร่วมที่ไม่บังคับจะได้รับเชิญเมื่อมีข้อบกพร่องเฉพาะที่ต้องการข้อมูลจากพวกเขา ตัวอย่างเช่น เมื่อนักวิเคราะห์ธุรกิจต้องยืนยันว่าพฤติกรรมที่รายงานนั้นขัดแย้งกับข้อกำหนดจริงหรือไม่ หรือเป็นการขอเปลี่ยนแปลงที่แฝงมาในรูปแบบอื่น
บทบาทและความรับผิดชอบของผู้เข้าร่วมระหว่าง 'การตรวจสอบข้อบกพร่อง'
ผู้เข้าร่วมประชุมทุกคนจะต้องรับผิดชอบหน้าที่ที่แตกต่างกัน และการประชุมจะดำเนินไปตามกำหนดเวลาได้ก็ต่อเมื่อทั้งสามคนเตรียมตัวล่วงหน้ามาอย่างดี
หัวหน้าทีมทดสอบ
- กำหนดการประชุมคัดแยกข้อบกพร่องและส่งการแจ้งเตือนการประชุมให้กับผู้เข้าร่วม
- สร้างรายงานข้อบกพร่องและส่งให้ผู้เข้าร่วมประชุมทุกคนก่อนการประชุม
- กำหนดลำดับความสำคัญและ ความรุนแรง ของข้อบกพร่อง
- นำเสนอเพื่อให้สมาชิกท่านอื่นเข้าใจถึงสาเหตุที่แท้จริงของข้อบกพร่อง
- บันทึกการประชุมทุกรายการจะถูกบันทึกและส่งไปยังผู้เข้าร่วมประชุม
หัวหน้าฝ่ายพัฒนา
- ช่วยในการจัดลำดับความสำคัญของข้อบกพร่อง
- หารือเกี่ยวกับปัญหาข้อบกพร่องและอธิบายความเสี่ยงที่เกี่ยวข้องเนื่องจากข้อบกพร่องนั้น
- จัดสรรงานแก้ไขข้อบกพร่องให้กับผู้พัฒนาที่เกี่ยวข้อง
- อัปเดตการแก้ไขข้อบกพร่องและรวมบันทึกการพัฒนาไว้ในกรณีที่ข้อมูลขาดหายไปหรือข้อมูลเพิ่มเติมใดๆ ที่นักพัฒนาต้องการ
Project Manager
- ช่วยในการจัดลำดับความสำคัญของข้อบกพร่อง
- หารือเกี่ยวกับวันที่เผยแพร่การทำซ้ำครั้งถัดไปสำหรับ QA
- จำเป็นต้องตรวจสอบให้แน่ใจว่าตัวแทนผู้ใช้ที่เกี่ยวข้องได้รับเชิญให้เข้าร่วมการประชุมคัดแยกจุดบกพร่องด้วย
ผู้จัดการโครงการเป็นผู้กำหนดวันวางจำหน่าย ดังนั้นการตัดสินใจขั้นสุดท้ายเกี่ยวกับข้อบกพร่องที่มีข้อโต้แย้งมักตกอยู่กับผู้จัดการโครงการ ดังแสดงในภาพด้านล่าง
จะเกิดอะไรขึ้นในระหว่างการประชุม 'Defect Triage'
- หัวหน้าทีมทดสอบส่งรายงานข้อบกพร่องพร้อมข้อบกพร่องใหม่ออกไป ในระหว่างการประชุมคัดแยกข้อบกพร่อง ข้อบกพร่องแต่ละรายการจะได้รับการวิเคราะห์เพื่อดูว่ามีการจัดลำดับความสำคัญและความรุนแรงที่ถูกต้องหรือไม่
- ลำดับความสำคัญจะถูกจัดเรียงใหม่หากจำเป็น
- ข้อบกพร่องจะได้รับการวิเคราะห์และประเมินตามระดับความรุนแรง
- รวมถึงการหารือเกี่ยวกับความซับซ้อนของข้อบกพร่อง ความเสี่ยง การปฏิเสธ และการมอบหมายข้อผิดพลาดใหม่
- การอัปเดตจะถูกบันทึกไว้ในบั๊ก tracระบบกษัตริย์
- วิศวกร QA จะทำการเปลี่ยนแปลงข้อบกพร่องแต่ละข้อและหารือกับผู้เข้าร่วมแต่ละคน
- ช่อง "ความคิดเห็น" ได้รับการอัปเดตอย่างถูกต้องโดยระบุประเด็นสำคัญของการประชุม
เวลาส่วนใหญ่ในการอภิปรายจะหมดไปกับสองประเด็นที่มักทำให้เกิดความสับสนได้ง่ายที่สุด นั่นคือ ระดับความรุนแรงและลำดับความสำคัญ ซึ่งถูกกำหนดแยกจากกัน และข้อบกพร่องหนึ่งๆ อาจได้คะแนนสูงในด้านหนึ่งและคะแนนต่ำในอีกด้านหนึ่ง
| แง่มุม | ความรุนแรง | ลำดับความสำคัญ |
|---|---|---|
| มันวัดอะไร | ความเสียหายที่เกิดขึ้นนั้นส่งผลกระทบต่อผลิตภัณฑ์หรือฟังก์ชันการทำงานมากน้อยเพียงใด | ต้องแก้ไขข้อบกพร่องนี้ให้เสร็จเร็วแค่ไหนเมื่อเทียบกับงานอื่นๆ |
| ปกติกำหนดโดย | ผู้ทดสอบที่รายงานข้อบกพร่อง | เห็นพ้องกันในขั้นตอนการคัดกรอง โดยมีผู้จัดการโครงการและฝ่ายผลิตภัณฑ์เป็นผู้นำ |
| ขับโดย | ผลกระทบทางเทคนิคและฟังก์ชันการทำงานที่ได้รับผลกระทบ | ผลกระทบทางธุรกิจ การมองเห็นของลูกค้า และวันวางจำหน่าย |
| ตัวอย่างของความไม่ตรงกัน | ความรุนแรงสูง แต่ลำดับความสำคัญต่ำ: ข้อผิดพลาดในฟังก์ชันที่ไม่มีใครใช้จนกว่าจะถึงไตรมาสถัดไป | ความรุนแรงต่ำ แต่ความสำคัญสูง: ชื่อบริษัทสะกดผิดบนหน้า Landing Page |
เคล็ดลับ: ควรจำกัดขอบเขตการอภิปรายเกี่ยวกับข้อบกพร่องแต่ละข้อให้สั้น หากไม่สามารถแก้ไขปัญหาได้ภายในสองสามนาที ให้พักเรื่องนั้นไว้ก่อน มอบหมายผู้รับผิดชอบให้ตรวจสอบ และนำกลับมาพูดคุยในครั้งต่อไป แทนที่จะปล่อยให้ข้อบกพร่องเพียงข้อเดียวใช้เวลาในการประชุมทั้งหมด
ผลลัพธ์ของ 'Defect Triage' คืออะไร?
เมื่อสิ้นสุดการประชุมทุกครั้ง ระบบจะจัดเตรียม Defect Triage Metrics และมอบให้กับผู้เข้าร่วมประชุมทุกคน รายงานนี้ทำหน้าที่เป็นรายงานการประชุมซึ่งจะเป็นประโยชน์สำหรับการประชุมครั้งต่อไป
รายงานฉบับนี้เป็นจุดเชื่อมโยงระหว่างการคัดกรองเบื้องต้นกับภาพรวมที่กว้างขึ้น กระบวนการจัดการข้อบกพร่องโดยทั่วไปแล้ว ทีมต่างๆ มักจะบันทึกข้อมูลต่อไปนี้ลงในไฟล์นี้:
- ข้อบกพร่องที่ได้รับการตรวจสอบในระหว่างการประชุม พร้อมระบุระดับความรุนแรงและลำดับความสำคัญที่ตกลงกันไว้สำหรับแต่ละข้อบกพร่อง
- ข้อบกพร่องที่ได้รับการกำหนดใหม่ พร้อมด้วยนักพัฒนาที่เป็นเจ้าของข้อบกพร่องเหล่านั้น
- ข้อบกพร่องที่ถูกเลื่อนออกไป ปฏิเสธ หรือทำเครื่องหมายว่าเป็นของซ้ำ โดยมีการบันทึกเหตุผลไว้
- จำนวนข้อบกพร่องที่เปิดอยู่จำแนกตามระดับความรุนแรง เพื่อให้เห็นแนวโน้มตลอดช่วงเวลาต่างๆ
- การดำเนินการต่างๆ จะถูกนำไปดำเนินการต่อในการประชุมครั้งต่อไป
เพราะทุกการเปลี่ยนแปลงจะถูกบันทึกกลับเข้าไปในระบบ tracker สถานะของแต่ละรายการจะสอดคล้องกับตำแหน่งของมันใน วงจรชีวิตข้อบกพร่องและการประชุมครั้งต่อไปจะเริ่มต้นจากรายการที่ถูกต้องแม่นยำ แทนที่จะเป็นรายการที่ล้าสมัย
