กายวิภาคของรายงานข้อบกพร่องที่ดี

เกือบศตวรรษครึ่งวิศวกรเรียกข้อบกพร่องเล็ก ๆ น้อย ๆ ในเครื่องจักรว่า "บั๊ก" ปัจจุบัน "บั๊ก" ใช้กับปัญหาฮาร์ดแวร์และซอฟต์แวร์ในคอมพิวเตอร์และแกดเจ็ต ข้อบกพร่องของคอมพิวเตอร์มีมานานแล้วและรายงานข้อผิดพลาดก็มีมาด้วยเช่นกัน

รายงานข้อบกพร่องของคอมพิวเตอร์เป็นครั้งแรกได้รับการบันทึกเมื่อวันที่ 9 กันยายน พ.ศ. 2490 โดย Grace Murray Hopper เธอรายงานว่ามีมอดจริงติดอยู่ระหว่างหน้าสัมผัสรีเลย์ในคอมพิวเตอร์ Harvard Mark II บั๊กถูกบันทึกลงในสมุดบันทึกของคอมพิวเตอร์

สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับรายงานข้อบกพร่องแรกได้ที่นี่

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

บทความนี้ครอบคลุมถึงสิ่งที่ต้องมีในรายงานข้อบกพร่องที่ดี นอกจากนี้ยังมีตัวอย่างรายงานข้อบกพร่องที่ดีและไม่ดีรวมถึงการวิเคราะห์สั้น ๆ ของแต่ละรายงาน

รายงานข้อผิดพลาดคืออะไร?

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

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

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

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

บทความที่เกี่ยวข้อง: วิธีการพัฒนาแผนประกันคุณภาพสำหรับเว็บไซต์ WordPress ของคุณ

รายงานข้อบกพร่องควรมีอะไรบ้าง?

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

• หัวข้อ - ควรใช้เป็นข้อมูลสรุปสั้น ๆ ว่าปัญหาคืออะไร สิ่งสำคัญคือชื่อต้องเจาะจงเกี่ยวกับลักษณะของปัญหา เป็นสิ่งแรกที่นักพัฒนาเห็น
• สถานะ - นี่คือตัวบ่งชี้ว่ารายงานข้อบกพร่องอยู่ที่สถานะใด รูปปั้นอาจมีหลายประเภทขึ้นอยู่กับซอฟต์แวร์การจัดการที่ใช้ (เช่น Jira, Asana, Trello, Mantis เป็นต้น) ตัวอย่างบางส่วน:
  • ที่จะได้รับมอบหมาย - ในขณะที่ยังไม่ได้กำหนดว่าใครจะเป็นผู้ตรวจสอบปัญหาในรายงาน
  • อยู่ระหว่างดำเนินการ - เมื่อนักพัฒนากำลังดำเนินการแก้ไขข้อบกพร่องที่รายงาน สถานะนี้ยังใช้เมื่อการอัปเดตอยู่ระหว่างการทดสอบ
  • เสร็จสมบูรณ์ - สัญญาณว่าข้อบกพร่องที่รายงานได้รับการแก้ไขแล้ว
• ลำดับความสำคัญ - แสดงถึงความเร่งด่วนของข้อบกพร่องที่รายงานเมื่อเทียบกับงานและปัญหาอื่น ๆ ลำดับความสำคัญของข้อบกพร่องจะเชื่อมโยงกับความรุนแรงของข้อบกพร่องเนื่องจากเป็นการวัดผลกระทบต่อระบบที่ทดสอบ ลำดับความสำคัญที่พบบ่อยที่สุด ได้แก่ :
  • สำคัญ - ใช้สำหรับประเด็นที่กิจกรรมอื่น ๆ ทั้งหมดต้องหยุดลงและความพยายามทั้งหมดมุ่งเน้นไปที่การแก้ไขสถานการณ์ เนื่องจากปัญหาดังกล่าวส่งผลกระทบอย่างมากต่อโครงการที่ได้รับรายงานและอาจส่งผลให้เกิดความสูญเสียต่อธุรกิจ
  • สูง - ใช้สำหรับปัญหาที่ควรได้รับการแก้ไขเร็วกว่าในภายหลัง สิ่งเหล่านี้ไม่ได้ส่งผลกระทบที่สำคัญ แต่หากไม่มีปัญหาร้ายแรงใด ๆ ก็ควรได้รับการแก้ไขโดยเร็ว
  • ปานกลาง - ใช้สำหรับปัญหาที่ไม่มีผลกระทบหลักต่อฟังก์ชันการทำงานหลัก คงจะดีหากมีการแก้ไข ปัญหาดังกล่าวจำเป็นต้องได้รับการแก้ไขหลังจากปัญหาที่มีลำดับความสำคัญสูงกว่า
  • ต่ำ - ใช้เมื่อข้อบกพร่องที่รายงานเป็นเพียงเล็กน้อยและไม่มีผลกระทบต่อฟังก์ชันการทำงานหลัก อาจเป็นข้อผิดพลาดทางไวยากรณ์ในบล็อกโพสต์หรือสีของปุ่มไม่ถูกต้อง
• ความรุนแรง - ใช้เพื่อแสดงระดับผลกระทบของข้อบกพร่องที่รายงานมีต่อระบบที่ทดสอบ การจำแนกประเภทที่พบบ่อยที่สุดสำหรับความรุนแรงของข้อบกพร่องคือ:
  • สำคัญ - ฟังก์ชันหลักไม่ทำงานหรือซอฟต์แวร์ทั้งหมดไม่สามารถทำงานได้
  • หลัก - ฟังก์ชันพื้นฐานอย่างน้อยหนึ่งอย่างได้รับผลกระทบจากข้อบกพร่อง ด้วยเหตุนี้ซอฟต์แวร์ที่ทดสอบจึงไม่ได้ผลลัพธ์ที่ต้องการ ซึ่งแตกต่างจากข้อบกพร่องที่มีความรุนแรงที่สำคัญจะมีฟังก์ชันการทำงานที่ทำงานได้ตามที่ตั้งใจไว้
  • ปานกลาง - ไม่มีผลกระทบต่อฟังก์ชันการทำงานหลักของซอฟต์แวร์ที่ทดสอบ องค์ประกอบอย่างน้อยหนึ่งรายการได้รับผลกระทบทำให้เกิดพฤติกรรมที่ไม่สอดคล้องกัน
  • เล็กน้อย - ผลกระทบต่อซอฟต์แวร์ที่ทดสอบมีเล็กน้อย
  • เล็กน้อย - ข้อบกพร่องที่มีความรุนแรงนี้ไม่ส่งผลต่อการทำงานของซอฟต์แวร์ สิ่งเหล่านี้อาจเป็นข้อบกพร่องทางสายตาเล็กน้อยการแปลขาดหายไปข้อความยืนยันไม่ทำงานเป็นต้น
• รายละเอียดข้อบกพร่อง - รายละเอียดประกอบด้วยข้อมูลที่สำคัญเกี่ยวกับตำแหน่งที่พบปัญหาที่รายงาน ควรรวมข้อมูลต่อไปนี้ (แม้ว่าองค์กรต่างๆอาจต้องการรายละเอียด (จุดบกพร่อง) ที่แตกต่างกัน):
  • เบราว์เซอร์ ที่พบข้อบกพร่อง (ควรรวมเวอร์ชันด้วย)
  • ระบบปฏิบัติการ - อาจเป็นปัญหาสังเกตได้เฉพาะใน Windows นอกจากนี้ยังรวมถึงระบบปฏิบัติการมือถือเช่น Android, iOS และ PadOS
  • สาขา - ใช้สำหรับการอัปเดตที่ยังไม่ได้เผยแพร่ (คุณลักษณะใหม่หรือการอัปเดตที่แก้ไขข้อบกพร่องอื่น ๆ ที่รายงาน) สาขามีเฉพาะคอมมิตเฉพาะที่เกี่ยวข้องกับฟีเจอร์ สิ่งนี้ทำเพื่อให้การเปลี่ยนแปลงไม่รบกวนการทำงานของคนอื่นในโครงการเดียวกัน
  • เวอร์ชัน - หากซอฟต์แวร์ที่ทดสอบเป็นแอปพลิเคชันเดสก์ท็อปหรือมือถือ ขอแนะนำให้รวมเวอร์ชันที่มีการรายงานข้อบกพร่อง
• คำอธิบายข้อบกพร่อง - ผู้เชี่ยวชาญด้าน QA ต้องให้คำอธิบายที่ถูกต้องเกี่ยวกับปัญหาที่พบพร้อมกับขั้นตอนที่จำเป็นในการทำให้เกิดปัญหาขึ้นอีกครั้ง ผู้เชี่ยวชาญควรอธิบายด้วยว่าผลลัพธ์ที่คาดหวังควรจะเป็นอย่างไร สิ่งเหล่านี้เป็นสิ่งสำคัญที่จะช่วยให้ทีมพัฒนาเข้าใจว่าปัญหาคืออะไรต้องดำเนินการอะไรบ้างเพื่อสร้างซ้ำและพฤติกรรมที่ถูกต้องควรเป็นอย่างไร
• ไฟล์แนบ / ภาพหน้าจอ - ไฟล์แนบ / ภาพหน้าจอช่วยให้ผู้เชี่ยวชาญเห็นว่าปัญหาอยู่ที่ใดและบ่อยครั้ง นอกจากนี้ยังสามารถจัดเตรียมขั้นตอนที่ดำเนินการเพื่อให้เกิดปัญหากับผู้เชี่ยวชาญด้าน QA
• ความคิดเห็น - โดยทั่วไปส่วนความคิดเห็นจะไม่ใช้เมื่อมีการสร้างรายงานข้อบกพร่องใหม่ แต่สิ่งสำคัญคือต้องแบ่งปันคำสองสามคำเกี่ยวกับสิ่งที่ต้องรวมไว้ในความคิดเห็นของนักพัฒนา (และความคิดเห็นต่อไปนี้) เมื่อมีการส่งการแก้ไขข้อบกพร่องไปยัง ทีม QA สำหรับการทดสอบ นักพัฒนาต้องมีรายการต่อไปนี้:
  • ลิงก์ไปยังคอมมิตที่มีการอัพเดต
  • อธิบายว่าการอัปเดตทำอะไร
  • หากมีขั้นตอนการตั้งค่าที่ต้องดำเนินการสิ่งสำคัญคือต้องอธิบาย
  • แนบภาพหน้าจอ / แคสต์ที่แสดงการอัปเดตที่กำลังดำเนินการอยู่
  • รวมบันทึกที่ผู้เชี่ยวชาญ QA ต้องคำนึงถึงเมื่อทดสอบการอัปเดต

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

การเขียนงานสำหรับคำแนะนำและคุณสมบัติใหม่

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

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

ในทั้งสองกรณีสิ่งสำคัญคือต้องระบุคำอธิบายที่ชัดเจนเกี่ยวกับคุณลักษณะที่ต้องดำเนินการ:

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

รายงานข้อบกพร่องที่ดีและไม่ดี: ตัวอย่าง

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

ตัวอย่างที่ 1 :

นี่คือตัวอย่างของรายงานข้อบกพร่องที่มีการเขียนอย่างดี ประกอบด้วยคุณลักษณะทั้งหมดที่กล่าวถึงข้างต้น

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

ชื่อที่ดีกว่าคือ "ไม่มีรูปภาพผลิตภัณฑ์ในส่วน" ผู้ที่ซื้อสินค้านี้ก็ซื้อด้วย "" วิธีนี้ทีมพัฒนาจะมีความคิดว่ารายงานเกี่ยวกับอะไรจากชื่อเรื่อง

ตัวอย่างที่ 2 :

นี่คือตัวอย่างของรายงานข้อบกพร่องโดยรวมที่เขียนไม่ดี ปัญหาหลักของตัวอย่างนี้คือ:

• ชื่อไม่ได้เจาะจงว่าราคาที่หายไปคือที่ไหน
• คำอธิบายไม่ได้ระบุว่าพบปัญหาที่ใด
• ผลลัพธ์ที่คาดหวังไม่ได้อธิบายว่าพฤติกรรมที่ถูกต้องคืออะไร

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

ตัวอย่างที่ 3 :

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

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

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

สรุปแล้ว

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

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