กระบวนการจัดการข้อบกพร่องในการทดสอบซอฟต์แวร์

กระบวนการจัดการข้อบกพร่องคืออะไร?

การขอ กระบวนการจัดการข้อบกพร่อง วงจรชีวิตของซอฟต์แวร์ (Lifecycle of Quest หรือ LSCM) คือวิธีการที่เป็นระบบที่ใช้ในการทดสอบซอฟต์แวร์เพื่อระบุ จำแนก แก้ไข และตรวจสอบข้อบกพร่องก่อนที่จะปล่อยซอฟต์แวร์ออกสู่ตลาด วงจรชีวิตนี้ประกอบด้วยหกขั้นตอนหลัก ได้แก่ 1) การค้นพบข้อบกพร่อง 2) การจำแนกประเภท 3) การแก้ไขโดยนักพัฒนา 4) การตรวจสอบโดยผู้ทดสอบ 5) การปิดโครงการ และ 6) การรายงานข้อบกพร่องเมื่อสิ้นสุดโครงการ

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

ทำไมคุณถึงต้องมีกระบวนการจัดการข้อบกพร่อง?

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

หนึ่งสัปดาห์ต่อมา นักพัฒนาตอบกลับมาด้วยความเข้าใจที่แตกต่างออกไปเกี่ยวกับปัญหาดังกล่าว

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

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

ขั้นตอนที่ 1) การค้นพบ

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

ในสถานการณ์ตัวอย่าง ผู้ทดสอบพบข้อบกพร่อง 84 รายการบน Guruเว็บไซต์ของธนาคาร 99

อย่างไรก็ตาม ผู้ทดสอบและนักพัฒนาไม่ได้เห็นพ้องกันเสมอไป ลองดูตัวอย่างต่อไปนี้ ซึ่งทีมทดสอบระบุปัญหาใน... Guruเว็บไซต์ของธนาคาร 99 รายงานปัญหาดังกล่าว แต่ทีมพัฒนาโต้แย้งว่าไม่ใช่ข้อบกพร่อง:

ในกรณีเช่นนี้ ในฐานะผู้จัดการทดสอบ คุณควรทำอย่างไร?

ก) เห็นด้วยกับทีมทดสอบว่านี่คือข้อบกพร่อง
B) สวมบทบาทเป็นผู้พิพากษาและตัดสินว่าปัญหาดังกล่าวเป็นข้อบกพร่องหรือไม่
ค) เห็นด้วยกับทีมพัฒนาว่าไม่ใช่ข้อบกพร่อง

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

ขั้นตอนที่ 2) การจัดหมวดหมู่

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

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

1. เว็บไซต์ทำงานช้าเกินไป
2. ฟังก์ชันการเข้าสู่ระบบของเว็บไซต์ใช้งานไม่ได้อย่างถูกต้อง
3. ส่วนติดต่อผู้ใช้แบบกราฟิก (GUI) ของเว็บไซต์แสดงผลไม่ถูกต้องบน โทรศัพท์มือถือ อุปกรณ์
4. เว็บไซต์ไม่สามารถจดจำข้อมูลการเข้าสู่ระบบของผู้ใช้ได้
5. บางลิงก์ใช้งานไม่ได้

ต่อไปนี้คือคำตอบที่แนะนำ:

ลำดับ	Descriptไอออน	ลำดับความสำคัญ	คำอธิบาย
1	ประสิทธิภาพของเว็บไซต์ช้าเกินไป	จุดสูง	ปัญหาด้านประสิทธิภาพสร้างความไม่สะดวกอย่างมากให้กับผู้ใช้งาน
2	ฟังก์ชันการเข้าสู่ระบบใช้งานไม่ได้อย่างถูกต้อง	วิกฤต	การเข้าสู่ระบบเป็นฟังก์ชันหลักของเว็บไซต์ธนาคาร หากการเข้าสู่ระบบล้มเหลว กระบวนการใช้งานของผู้ใช้ทั้งหมดก็จะหยุดชะงัก
3	ส่วนติดต่อผู้ใช้ (GUI) แสดงผลไม่ถูกต้องบนอุปกรณ์มือถือ	กลาง	ข้อบกพร่องนี้ส่งผลกระทบต่อผู้ใช้งานที่เข้าชมเว็บไซต์ผ่านสมาร์ทโฟน
4	เว็บไซต์ไม่สามารถจดจำเซสชันการเข้าสู่ระบบของผู้ใช้ได้	จุดสูง	ผู้ใช้สามารถล็อกอินได้ แต่ไม่สามารถทำธุรกรรมอื่นใดได้
5	ลิงก์บางส่วนใช้งานไม่ได้	ต่ำ	วิธีนี้แก้ไขได้ง่ายสำหรับนักพัฒนา และผู้ใช้ยังคงสามารถเข้าถึงส่วนอื่นๆ ของเว็บไซต์ได้

ขั้นตอนที่ 3) การแก้ไขข้อบกพร่อง

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

คุณสามารถทำตามขั้นตอนเหล่านี้เพื่อแก้ไขข้อบกพร่อง:

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

ขั้นตอนที่ 4) การยืนยัน

หลังจากที่ทีมพัฒนาได้ดำเนินการแล้ว การแก้ไข และ รายงาน ข้อบกพร่อง ทีมทดสอบ ตรวจสอบแล้ว ปัญหาต่างๆ ได้รับการแก้ไขแล้ว

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

ขั้นตอนที่ 5) การปิด

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

ขั้นตอนที่ 6) การรายงานข้อบกพร่อง

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

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

ตัวชี้วัดข้อบกพร่องที่สำคัญ

กลับมาที่สถานการณ์เดิม ทีมพัฒนาและทีมทดสอบจะตรวจสอบข้อบกพร่องร่วมกัน ผลลัพธ์โดยรวมแสดงอยู่ด้านล่าง

คุณจะวัดและประเมินคุณภาพของการดำเนินการทดสอบได้อย่างไร?

นี่เป็นคำถามสำคัญทุกๆ ตัวจัดการการทดสอบ ต้องการตอบคำถาม โดยทั่วไปจะใช้พารามิเตอร์หลักสองประการ:

ในสถานการณ์ข้างต้น อัตราส่วนการปฏิเสธข้อบกพร่อง (DRR) คำนวณได้เป็น 20/84 = 0.238 (23.8%)

ยกตัวอย่างเช่น สมมติว่า Guruเว็บไซต์ของ 99 Bank มีทั้งหมด 64 มีข้อบกพร่อง แต่ทีมทดสอบตรวจพบเพียงบางส่วนเท่านั้น 44 - ความหมาย 20 ข้อบกพร่องถูกมองข้ามไป อัตราส่วนการรั่วไหลของข้อบกพร่อง (DLR) คำนวณได้เป็น 20/64 = 0.312 (31.2%)

โดยสรุป คุณภาพการดำเนินการทดสอบจะถูกประเมินโดยใช้พารามิเตอร์สองตัวดังต่อไปนี้:

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

• ปรับปรุง ทักษะการทดสอบของสมาชิกในทีม
• ใช้เวลามากกว่านี้ ในการดำเนินการทดสอบ โดยเฉพาะอย่างยิ่งเมื่อตรวจสอบผลลัพธ์ของการดำเนินการ

แนวปฏิบัติที่ดีที่สุดสำหรับการจัดการข้อบกพร่องอย่างมีประสิทธิภาพ

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

ต่อไปนี้คือแนวทางปฏิบัติที่ดีที่สุดที่ผู้ทดสอบระดับเริ่มต้นและระดับกลางควรนำไปใช้ทันที:

1. กำหนดมาตรฐานแม่แบบรายงานข้อบกพร่อง: ใช้เทมเพลตรายงานข้อบกพร่องแบบตายตัว ซึ่งมีช่องต่างๆ เช่น รหัสข้อบกพร่อง Descriptข้อมูลที่แสดงควรประกอบด้วย ขั้นตอนการจำลองปัญหา ระดับความรุนแรง ลำดับความสำคัญ สภาพแวดล้อม และไฟล์แนบ ความสม่ำเสมอจะช่วยลดการสื่อสารไปมาระหว่างผู้ทดสอบและนักพัฒนา
2. จัดลำดับความสำคัญก่อนมอบหมายงาน: ควรจัดประเภทข้อบกพร่องตามระดับความรุนแรงและลำดับความสำคัญก่อนส่งให้ผู้พัฒนาเสมอ เพื่อให้แน่ใจว่าปัญหาสำคัญจะไม่ถูกมองข้ามไปเพราะเป็นเพียงปัญหาเล็กน้อย
3. โปรดทำซ้ำก่อนรายงาน: ควรจำลองข้อบกพร่องนั้นอย่างน้อยสองครั้งในสภาพแวดล้อมที่สะอาดก่อนที่จะแจ้งเรื่อง ข้อบกพร่องที่จำลองได้จะได้รับการแก้ไขเร็วขึ้นและลดอัตราการปฏิเสธลง
4. ยอมรับข้อบกพร่อง tracเครื่องมือราชา: ใช้เครื่องมือเช่น จิระ, Bugzillaหรือ ตั๊กแตนตำข้าว เพื่อรวมศูนย์ tracกษัตริย์ ประวัติศาสตร์ และการรายงานข่าว
5. จัดการประชุมเพื่อประเมินสถานการณ์เบื้องต้น: จัดประชุมคัดกรองข้อบกพร่องระยะสั้นและตรงประเด็น เพื่อให้ทีม QA, ทีมพัฒนา และทีมผลิตภัณฑ์ สามารถจัดลำดับความสำคัญให้สอดคล้องกัน
6. วัดการรั่วไหลและการปฏิเสธ: Tracตรวจสอบค่า DLR และ DRR ในทุกสปรินต์หรือรอบการทดสอบ อัตราการรั่วไหลที่เพิ่มสูงขึ้นเป็นสัญญาณเตือนล่วงหน้าว่าการครอบคลุมการทดสอบไม่สมบูรณ์
7. ดำเนินการวิเคราะห์หาสาเหตุที่แท้จริง: สำหรับข้อบกพร่องที่เกิดขึ้นซ้ำๆ หรือมีความร้ายแรงสูง ให้ทำการวิเคราะห์หาสาเหตุที่แท้จริง เพื่อป้องกันไม่ให้ข้อบกพร่องประเภทเดียวกันนี้กลับมาเกิดขึ้นในเวอร์ชันต่อๆ ไป
8. ปิดช่องว่างด้วยการรายงาน: แชร์แดชบอร์ดรายงานข้อบกพร่องรายสัปดาห์กับผู้มีส่วนได้ส่วนเสีย เพื่อให้ปัญหาต่างๆ ปรากฏให้เห็นและสามารถดำเนินการแก้ไขได้ทันท่วงที

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

แหล่งข้อมูล:

ดาวน์โหลดตัวอย่างเทมเพลตการรายงานข้อบกพร่อง

คำถามที่พบบ่อย