วิธีการเขียนรายงานจุดบกพร่องที่ดี: คำแนะนำ

ลองนึกภาพว่าคุณเป็นนักพัฒนาและนักทดสอบนำข้อบกพร่องที่พบระหว่างการรีเกรสชันมาให้คุณ คุณต้องการแก้ไขข้อผิดพลาดนี้ ดังนั้นคุณจึงขอให้สร้างตั๋ว คุณลองนึกภาพว่าคุณจะหยิบมันขึ้นมาได้อย่างไร เชื่อมโยงคำขอแบบดึงข้อมูล และเพิ่มการประมาณการอย่างไร เพื่อที่ผู้จัดการผลิตภัณฑ์จะไม่มีคำถามใดๆ เวลาผ่านไปสักพัก ตั๋วใบใหม่ก็ปรากฏขึ้น แต่ภายในมีเพียงสองสามบรรทัดและภาพหน้าจอ คุณถอนหายใจและพยายามทำซ้ำจุดบกพร่องโดยใช้ข้อมูลนี้ แต่ไม่มีข้อผิดพลาด คุณพยายามหลายครั้ง แต่สุดท้าย คุณเขียนถึงผู้ทดสอบว่าไม่สามารถทำซ้ำจุดบกพร่องได้ และเริ่มการชี้แจงรอบใหม่ คุณกำลังใช้เวลาที่อาจนำไปใช้ในการทำงานใหม่ แก้ไขจุดบกพร่องอื่นๆ หรือแม้แต่ เพื่อรีแฟกเตอร์โค้ด ดูอนิเมะ ฉันชื่อ ฉันเป็น และจะพยายามแบ่งปันมุมมองของฉันเกี่ยวกับสิ่งที่ทำให้รายงานข้อบกพร่องดี ขออภัยที่อธิบายยาวไปหน่อย มาเริ่มกันเลยดีกว่า Evgeny Domnin QA ชื่อ ลองตอบคำถามสามข้อในหัวข้อตั๋ว: มันเกิดขึ้นที่ไหน? เกิดอะไรขึ้น? ภายใต้สถานการณ์ใด? นักพัฒนาที่มีประสบการณ์จะต้องดูแค่ชื่อเรื่องเพื่อทำความเข้าใจปัญหา ตัวอย่างเช่น: หน้าเข้าสู่ระบบ: ช่องจะไม่ถูกเน้นเมื่อป้อนรหัสผ่านไม่ถูกต้อง สิ่งแวดล้อม ฉันมักจะเห็นผู้ทดสอบลืมระบุในตั๋วว่าปัญหาเกิดขึ้นในสภาพแวดล้อมใด ซึ่งสิ่งนี้เกี่ยวข้องโดยเฉพาะในตั๋วที่เกี่ยวข้องกับ UI ที่ไม่สามารถมองเห็นที่อยู่เว็บไซต์หรือคำขอเครือข่ายได้ ควรระบุสิ่งนี้เสมอ หากมีฟิลด์แยกต่างหากในตั๋ว ก็ดี ให้ใส่ไว้ที่นั่น หากไม่มี ให้ระบุในขั้นตอนการสร้างซ้ำ ตัวอย่างเช่น: เข้าสู่ระบบสภาพแวดล้อมการจัดเตรียมด้วยบัญชีผู้ดูแลระบบ เมื่อพูดถึงขั้นตอน... ขั้นตอนการผลิตซ้ำ ส่วนที่สำคัญที่สุดส่วนหนึ่งคือคำแนะนำในการทำซ้ำจุดบกพร่อง ฉันจะเน้นสองส่วนที่ควรเน้น: การจัดรูปแบบของขั้นตอน (ภาพ) และเนื้อหา (ข้อมูลภายใน) ส่วนภาพ รักษาโครงสร้าง รายงานข้อบกพร่องมีอยู่หลายรูปแบบ แต่โดยทั่วไปแล้ว รายงานข้อบกพร่องควรประกอบด้วยส่วนต่าง ๆ ต่อไปนี้: ขั้นตอน ผลลัพธ์ที่คาดหวัง ผลลัพธ์ที่เกิดขึ้นจริง ใช้โครงสร้างนี้และยึดถือตามนี้เสมอ นี่เป็นกรณีหนึ่งที่ความสม่ำเสมอจะช่วยจัดระเบียบความคิดของคุณเมื่ออธิบายประเด็นต่างๆ ใช้รายการที่มีหมายเลข แบ่งขั้นตอนออกเป็นรายการที่มีหมายเลข บางครั้งผู้ทดสอบจะเขียนคำอธิบายโดยละเอียด แต่ให้เป็นข้อความต่อเนื่อง อย่าทำเช่นนี้ เพราะจะทำให้ทุกคนอ่านได้ง่ายขึ้นหากแยกขั้นตอนต่างๆ ออกจากกัน เมื่อเป็นไปได้ ให้เขียนโดยไม่ผิดพลาดด้านไวยากรณ์ ต่อไปมาดูเนื้อหาของขั้นตอนเหล่านี้กัน สามัญสำนึกในการบรรยาย คุณไม่จำเป็นต้องแยกการดำเนินการแต่ละอย่างออกเป็นขั้นตอนที่แยกจากกันหากไม่จำเป็นต่อการสร้างจุดบกพร่องซ้ำ เพราะขั้นตอนนี้ยากต่อการอ่านและนำไปใช้ในทางปฏิบัติ อย่ากลัวที่จะรวมการดำเนินการหลายอย่างไว้ในขั้นตอนเดียว ฉันหมายความว่าอย่างไร : แย่ ไปที่ test.com/login คลิกที่ช่องเข้าสู่ระบบ เข้าสู่ระบบ คลิกที่ช่องรหัสผ่าน กรอกรหัสผ่าน : ดี ไปที่ และเข้าสู่ระบบด้วยบัญชีใดก็ได้ test.com/login เราไม่ได้แบ่งขั้นตอนออกเป็นสิ่งที่นักพัฒนาจะต้องทำตามธรรมชาติในขณะที่ปฏิบัติตามขั้นตอนมาตรฐาน เมื่อผมเริ่มต้น ผมเคยคิดว่าการดำเนินการแต่ละอย่างต้องมีขั้นตอนของตัวเอง แต่จริงๆ แล้วไม่จำเป็น หลีกเลี่ยงความคลุมเครือ ให้เสริมขั้นตอนด้วยการขอให้ตรวจสอบในแต่ละขั้นตอนอย่างชัดเจน และเขียนปุ่มที่ต้องกดโดยเฉพาะ (โดยเฉพาะหากมีปุ่มที่มีชื่อเดียวกัน) รวมข้อมูลการทดสอบ ระบุข้อมูลการเข้าสู่ระบบหากข้อผิดพลาดเกี่ยวข้องกับบัญชีของคุณ และอย่าลังเลที่จะรวมข้อมูลการทดสอบที่ช่วยสร้างจุดบกพร่องซ้ำ ทบทวนขั้นตอนของคุณอีกครั้ง บางครั้ง คุณอาจเขียนขั้นตอนทันทีหลังจากพบจุดบกพร่อง แต่สุดท้ายแล้ว คุณอาจพลาดขั้นตอนบางขั้นตอนไปเพื่อทำความเข้าใจอย่างถ่องแท้ หรืออาจไม่สามารถทำซ้ำจุดบกพร่องได้ในภายหลัง ในกรณีนั้น อาจจำเป็นต้องค้นหาขั้นตอนที่ชัดเจนกว่านี้ ผลลัพธ์ที่คาดหวัง ส่วนแยกต่างหากคือผลลัพธ์ที่คาดหวัง ซึ่งเราจะอธิบาย (อย่างไม่น่าแปลกใจ) ถึงผลลัพธ์ที่คาดหวังเมื่อทำตามขั้นตอนต่างๆ ไม่มีคำแนะนำพิเศษมากนักนอกจากว่าต้องมีส่วนนี้ นักพัฒนาต้องเข้าใจว่าฟังก์ชันการทำงานควรนำไปสู่พฤติกรรมใด วลีเช่น "ทุกอย่างควรทำงานได้ดี" ไม่สามารถอธิบายได้ ดังนั้นควรเขียนพฤติกรรมเฉพาะเจาะจง ผลลัพธ์ที่แท้จริง ที่นี่ เราจะเขียนสิ่งที่เกิดขึ้นจริงเมื่อเราทำตามขั้นตอนต่างๆ ความจำเพาะเจาะจงก็มีความสำคัญเช่นกัน อย่าเขียนแค่ว่า “ทุกอย่างพังหมด” (แม้ว่านั่นอาจจะเป็นสิ่งที่เกิดขึ้น) อธิบายตัวบ่งชี้ที่แสดงว่าทุกอย่างพังหมด ตัวอย่างเช่น: คำขอ ข้อผิดพลาด 500 ถูกส่งกลับใน GET /accounts และ UI จะถูกบล็อก ผู้ใช้ไม่สามารถออกจากหน้าหรือคลิกบนองค์ประกอบได้ การรีเฟรชหน้าจะทำให้เกิดการร้องขออีกครั้งและทำให้เกิดข้อผิดพลาดเดิม กล่าวอีกนัยหนึ่ง อธิบายผลที่แท้จริงและผลกระทบต่อการใช้งานของผู้ใช้ ไฟล์เพิ่มเติม นี่เป็นส่วนแยกต่างหากที่ควรกล่าวถึง เป็นส่วนที่คุณแนบข้อมูลเพิ่มเติมที่อธิบายข้อบกพร่อง ฉันรู้จักนักพัฒนาบางคนที่ไม่ชอบอ่านขั้นตอนการสร้างซ้ำและไปที่ผลลัพธ์จริงโดยตรงพร้อมเอกสารเพิ่มเติมที่อธิบายเรื่องนี้ ภาพหน้าจอของข้อผิดพลาด จะดีกว่าถ้าได้เห็นเพียงครั้งเดียวมากกว่าต้องฟังซ้ำร้อยครั้ง นี่เป็นวิธีที่ดีในการแสดงภาพว่าเกิดอะไรขึ้นและเกิดขึ้นที่ใด พยายามแนบภาพหน้าจอมาด้วยเสมอ ขอ หากมีคำขอที่เกิดข้อผิดพลาด คำขอนั้นควรรวมอยู่ในตั๋วเสมอ อย่างไรก็ตาม คำขอมีพารามิเตอร์ที่แตกต่างกันมากมาย ฉันเน้นสิ่งต่อไปนี้ว่าสำคัญที่จะต้องรวมไว้: – คำขอซึ่งคุณสามารถรับได้จากส่วนเครือข่ายในเบราว์เซอร์ที่กำลังทำการทดสอบ URL ข้อผิดพลาด – , , , เป็นต้น มีวิธีการมากมาย เช่นเดียวกับคำขอที่มี URL เดียวกันแต่มีวิธีการที่แตกต่างกัน อย่าลืมระบุในตั๋ว วิธีการ GET POST TRACE OPTION - จุดสำคัญอีกประการหนึ่ง คุณคงจะไม่ลืม แต่อย่าลืมจดรหัสที่ส่งกลับมาจากเซิร์ฟเวอร์ รหัสข้อผิดพลาด – นี่คือข้อมูลที่เราส่งในคำขอไปยังเซิร์ฟเวอร์ ข้อมูลนี้ไม่ได้มีอยู่ในคำขอทุกรายการ (เช่น HEAD หรือ GET ไม่มีข้อมูลนี้) แต่ข้อมูลนี้อาจเป็นสาเหตุของข้อผิดพลาดได้ เพย์โหลด – การตอบสนองของเซิร์ฟเวอร์ บางครั้งอาจมีข้อผิดพลาดทั้งหมด แม้กระทั่งแสดงตำแหน่งที่เกิดขึ้น ในขณะที่บางครั้งก็เป็นเพียงตัวแทนค่าเริ่มต้นที่ตั้งค่าไว้สำหรับข้อผิดพลาดประเภทนั้นในแบ็กเอนด์ อย่าลืมรวมสิ่งนี้ไว้ด้วย เพราะจะช่วยประหยัดเวลาให้กับนักพัฒนาได้มาก การตอบสนอง บันทึกคอนโซล บางครั้งอาจพบข้อผิดพลาดในคอนโซล และเพิ่มข้อผิดพลาดเหล่านี้ลงในตั๋วได้ บางทีคุณอาจเคยดำเนินการนี้แล้ว แต่ฉันจะขอเน้นย้ำว่าสามารถบันทึกข้อความขนาดใหญ่เป็นไฟล์ และเพิ่มลงในตั๋วได้เสมอ วิธีนี้ช่วยให้บันทึกและตั๋วอ่านได้ง่ายขึ้น .log ทั้งหมดนี้ก็ดีและดี แต่... ทั้งหมดนี้ก็ดีอยู่แล้ว แต่เราจะหาเวลาที่ไหนมาทำให้ทุกอย่างดูดีขนาดนี้ได้ เส้นตายใกล้เข้ามาแล้ว ผู้จัดการกำลังโกรธ มีอุปสรรคในการผลิต และฉันถูกขอให้นั่งเขียนทุกอย่างออกมา ฉันจะส่งข้อความหานักพัฒนาโดยตรงเท่านั้นเอง นี่เป็นข้อโต้แย้งเชิงตรรกะที่อาจเกิดขึ้นได้ ฉันไม่ได้คิดลวงโลกที่สมบูรณ์แบบของนักทดสอบ ที่มีการจัดสรรเวลาอย่างเพียงพอสำหรับการทดสอบ ทุกอย่างเป็นไปตามกระบวนการ และมีการรักษาเอกสารที่ละเอียดถี่ถ้วนและมีคุณภาพสูง ฉันเข้าใจดีว่าบ่อยครั้งที่มันเป็นเวลาจำกัด ต้องใช้สายตาอย่างหนัก และต้องแข่งขันกันทำทุกอย่างให้เสร็จทันเวลา ข้อผิดพลาดเล็กๆ น้อยๆ มักจะสะสมกันมากขึ้น ใช้เวลานานขึ้นเนื่องจากต้องสลับบริบท และนำไปสู่แนวทางปฏิบัติที่ไม่ดี หากเราเริ่มดำเนินการปรับปรุงและติดตามการทำงานของการปรับปรุงทีละน้อย เราจะสามารถสร้างกระบวนการที่เสถียรขึ้น เป็นมาตรฐานมากขึ้น และคาดเดาได้มากขึ้นสำหรับผู้เข้าร่วมทุกคน ผู้จัดการโครงการจะเข้าใจสิ่งที่เกิดขึ้นกับผลิตภัณฑ์โดยไม่จำเป็นต้องดึงทุกคนมาอัปเดต นักพัฒนาไม่จำเป็นต้องขอให้ผู้ทดสอบชี้แจงเงื่อนไขการผลิตซ้ำ และจะไม่ดึงพวกเขาออกจากการทดสอบ และในทางกลับกัน ผู้มีส่วนได้ส่วนเสียจะมีมุมมองที่ชัดเจนเกี่ยวกับความคืบหน้าของผลิตภัณฑ์ บทความนี้มุ่งเป้าไปที่ผู้เริ่มต้นที่กำลังเริ่มต้นหรือได้เริ่มเส้นทางการทดสอบแล้ว ฉันเชื่อว่าก้าวเล็กๆ น้อยๆ จะนำไปสู่ผลลัพธ์ที่ยิ่งใหญ่ และคำแนะนำในบทความนี้จะนำไปสู่การรายงานจุดบกพร่องที่มีคุณภาพสูงขึ้น หากคุณมีคำถาม ข้อเสนอแนะ ข้อไม่เห็นด้วย หรือข้อร้องเรียนใดๆ โปรดแสดงไว้ในความคิดเห็น—ฉันสนใจที่จะได้ยินความคิดเห็นของคุณ!