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

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

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

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

ฉันชื่อ Evgeny Domnin ฉันเป็น QA และจะพยายามแบ่งปันมุมมองของฉันเกี่ยวกับสิ่งที่ทำให้รายงานข้อบกพร่องดี ขออภัยที่อธิบายยาวไปหน่อย มาเริ่มกันเลยดีกว่า

ชื่อ

ลองตอบคำถามสามข้อในหัวข้อตั๋ว:

1. มันเกิดขึ้นที่ไหน?
2. เกิดอะไรขึ้น?
3. ภายใต้สถานการณ์ใด?

นักพัฒนาที่มีประสบการณ์จะต้องดูแค่ชื่อเรื่องเพื่อทำความเข้าใจปัญหา ตัวอย่างเช่น:

หน้าเข้าสู่ระบบ: ช่องจะไม่ถูกเน้นเมื่อป้อนรหัสผ่านไม่ถูกต้อง

สิ่งแวดล้อม

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

เข้าสู่ระบบสภาพแวดล้อมการจัดเตรียมด้วยบัญชีผู้ดูแลระบบ

เมื่อพูดถึงขั้นตอน...

ขั้นตอนการผลิตซ้ำ

ส่วนที่สำคัญที่สุดส่วนหนึ่งคือคำแนะนำในการทำซ้ำจุดบกพร่อง ฉันจะเน้นสองส่วนที่ควรเน้น: การจัดรูปแบบของขั้นตอน (ภาพ) และเนื้อหา (ข้อมูลภายใน)

ส่วนภาพ

รักษาโครงสร้าง

รายงานข้อบกพร่องมีอยู่หลายรูปแบบ แต่โดยทั่วไปแล้ว รายงานข้อบกพร่องควรประกอบด้วยส่วนต่าง ๆ ต่อไปนี้:

1. ขั้นตอน
2. ผลลัพธ์ที่คาดหวัง
3. ผลลัพธ์ที่เกิดขึ้นจริง

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

ใช้รายการที่มีหมายเลข

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

เมื่อเป็นไปได้ ให้เขียนโดยไม่ผิดพลาดด้านไวยากรณ์

ต่อไปมาดูเนื้อหาของขั้นตอนเหล่านี้กัน

สามัญสำนึกในการบรรยาย

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

แย่ :

1. ไปที่ test.com/login

2. คลิกที่ช่องเข้าสู่ระบบ
3. เข้าสู่ระบบ
4. คลิกที่ช่องรหัสผ่าน
5. กรอกรหัสผ่าน

   
   

ดี :

1. ไปที่ test.com/login และเข้าสู่ระบบด้วยบัญชีใดก็ได้

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

หลีกเลี่ยงความคลุมเครือ

ให้เสริมขั้นตอนด้วยการขอให้ตรวจสอบในแต่ละขั้นตอนอย่างชัดเจน และเขียนปุ่มที่ต้องกดโดยเฉพาะ (โดยเฉพาะหากมีปุ่มที่มีชื่อเดียวกัน)

รวมข้อมูลการทดสอบ

ระบุข้อมูลการเข้าสู่ระบบหากข้อผิดพลาดเกี่ยวข้องกับบัญชีของคุณ และอย่าลังเลที่จะรวมข้อมูลการทดสอบที่ช่วยสร้างจุดบกพร่องซ้ำ

ทบทวนขั้นตอนของคุณอีกครั้ง

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

ผลลัพธ์ที่คาดหวัง

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

ผลลัพธ์ที่แท้จริง

ที่นี่ เราจะเขียนสิ่งที่เกิดขึ้นจริงเมื่อเราทำตามขั้นตอนต่างๆ ความจำเพาะเจาะจงก็มีความสำคัญเช่นกัน อย่าเขียนแค่ว่า “ทุกอย่างพังหมด” (แม้ว่านั่นอาจจะเป็นสิ่งที่เกิดขึ้น) อธิบายตัวบ่งชี้ที่แสดงว่าทุกอย่างพังหมด ตัวอย่างเช่น:

ข้อผิดพลาด 500 ถูกส่งกลับใน คำขอ GET /accounts และ UI จะถูกบล็อก ผู้ใช้ไม่สามารถออกจากหน้าหรือคลิกบนองค์ประกอบได้

การรีเฟรชหน้าจะทำให้เกิดการร้องขออีกครั้งและทำให้เกิดข้อผิดพลาดเดิม

กล่าวอีกนัยหนึ่ง อธิบายผลที่แท้จริงและผลกระทบต่อการใช้งานของผู้ใช้

ไฟล์เพิ่มเติม

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

ภาพหน้าจอของข้อผิดพลาด

จะดีกว่าถ้าได้เห็นเพียงครั้งเดียวมากกว่าต้องฟังซ้ำร้อยครั้ง นี่เป็นวิธีที่ดีในการแสดงภาพว่าเกิดอะไรขึ้นและเกิดขึ้นที่ใด พยายามแนบภาพหน้าจอมาด้วยเสมอ

ขอ

หากมีคำขอที่เกิดข้อผิดพลาด คำขอนั้นควรรวมอยู่ในตั๋วเสมอ อย่างไรก็ตาม คำขอมีพารามิเตอร์ที่แตกต่างกันมากมาย ฉันเน้นสิ่งต่อไปนี้ว่าสำคัญที่จะต้องรวมไว้:

• URL ข้อผิดพลาด – คำขอซึ่งคุณสามารถรับได้จากส่วนเครือข่ายในเบราว์เซอร์ที่กำลังทำการทดสอบ

• วิธีการ – GET , POST , TRACE , OPTION เป็นต้น มีวิธีการมากมาย เช่นเดียวกับคำขอที่มี URL เดียวกันแต่มีวิธีการที่แตกต่างกัน อย่าลืมระบุในตั๋ว

• รหัสข้อผิดพลาด - จุดสำคัญอีกประการหนึ่ง คุณคงจะไม่ลืม แต่อย่าลืมจดรหัสที่ส่งกลับมาจากเซิร์ฟเวอร์

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

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

บันทึกคอนโซล

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

ทั้งหมดนี้ก็ดีและดี แต่...

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

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

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

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

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

หากคุณมีคำถาม ข้อเสนอแนะ ข้อไม่เห็นด้วย หรือข้อร้องเรียนใดๆ โปรดแสดงไว้ในความคิดเห็น—ฉันสนใจที่จะได้ยินความคิดเห็นของคุณ!