เขียนการ์ด Bug อย่างไร ให้ Dev หลงรัก

ชาว QA มาเขียนการ์ด Bug ให้ถูกใจ Dev กันเถอะ!

สวัสดีค่ะทุกคน วันนี้วันดีได้มีโอกาสมาแชร์ข้อมูลที่คิดว่าเป็นประโยชน์กับชาว QA ค่ะ เนื่องจากบทความนี้เป็นบทความแรก ยังไงก็ขอฝากเนื้อฝากตัวด้วยนะคะ :)

มาเข้าเรื่องกันเลยดีกว่าค่ะ สำหรับ QA แบบเราที่ทำงานคู่กับ Dev โดยตรง การสื่อสารจึงเป็นสิ่งสำคัญมาก โดยเฉพาะในตอนที่เราต้องเปิดการ์ด Bug ให้กับ Dev แต่เราจะทำอย่างไรล่ะ(?) กับการสื่อสารผ่านตัวอักษรที่จะทำให้ Dev เข้าใจสิ่งที่เราต้องการจะสื่อโดยไม่ต้องกลับมาถามรายละเอียดเพิ่มเติม คำตอบก็คือ การเขียนการ์ดที่มีรายละเอียดครอบคลุม และเข้าใจง่ายนั้นเอง ฉะนั้นเรามาดูวิธีการเขียนการ์ด Bug ยังไงให้ Dev เข้าใจง่ายและถูกต้องกันดีกว่าค่ะ

โดยในส่วนนี้เราจะแบ่งออกเป็นสองหัวข้อใหญ่ๆ กันนะคะ คือ การเขียนการ์ด Bug ให้มีรายละเอียดที่ครอบคลุม และ Trick ในการเขียนการ์ดที่ช่วยให้เข้าใจง่ายขึ้นค่ะ

1. การเขียนการ์ด Bug ให้มีรายละเอียดที่ครอบคลุมจะต้องมีข้อมูลที่จำเป็น 4 ส่วน ดังนี้ค่ะ

1.1 ระบุหัวข้อการ์ดให้เจาะจงและกระชับ

เราควรเขียนหัวข้อ โดยเริ่มจากการใส่ข้อมูลที่ช่วยระบุความเฉพาะเจาะจง เช่น Web หรือ Mobile, ระบบปฏิบัติการ iOS หรือ Android, Environment ต่างๆ เป็นต้น จากนั้น ระบุหัวข้อปัญหาที่พบค่ะ

เพื่อให้ Dev สามารถอ่านและเข้าใจคร่าวๆ ว่าการ์ดนี้เกี่ยวข้องกับอะไรได้ในระยะเวลาอันสั้นและสามารถ Assign การ์ดไปยัง Dev ที่ดูแลได้อย่างรวดเร็ว รวมถึงสามารถทำให้เพื่อนร่วมงานส่วนอื่น เช่น PO (Project Owner) หรือ QA คนอื่น ใช้ประโยชน์สำหรับการ Tracking และป้องกันการเปิดการ์ด Bug ซ้ำจากการอ่านแค่ชื่อการ์ดได้อีกด้วยค่ะ :)

กรณีตัวอย่าง

ในกรณีที่เราเทส Mobile Application ที่สามารถใช้งานได้ทั้ง iOS และ Andriod โดยมีทีม Dev 2 คนดังนี้
Dev#1 > รับผิดชอบฝั่งของ iOS
Dev#2 > รับผิดชอบฝั่งของ Android

หากเราเจอ Bug เกี่ยวกับแอป crash หลังกดปุ่ม Login เฉพาะแค่ฝั่ง iOS เราจะสามารถเขียนหัวข้อการ์ดบัคได้ดังตัวอย่างด้านล่างนี้ และหลังจากอ่านหัวข้อแล้ว การ์ดนี้จะถูก Assign ไปยัง Dev#1 ได้ทันทีโดยไม่ต้องเปิดอ่านรายละเอียดเลยค่ะ

ตัวอย่างการระบุหัวข้อการ์ด Bug

1.2 เขียน Steps ให้ชัดเจน

ต่อมาเป็นส่วนของการเขียนรายละเอียดในการ์ดค่ะ เริ่มด้วยการเขียน Steps ให้ชัดเจน โดยเราจะเขียนเป็นขั้นตอนตั้งแต่จุดเริ่มแรกของการเทส เช่น เข้าแอปไหนหรือเข้าเว็บอะไร และระบุขั้นตอนถัดๆมาทีละขั้น เรียงจากข้อ 1,2,3.. ลงไปเพื่อให้ง่ายต่อการอ่านค่ะ และเราสามารถจะระบุ Username และ Password ไปด้วยเลยก็ได้นะคะ เพื่อให้ Dev สามารถ Reproduce การเกิด Bug ได้ และนำไปสู่การหาสาเหตุของการเกิด Bug ต่อไปค่ะ

ตัวอย่างการเขียน Steps

1.3 เขียน Actual & Expected Result ให้ชัดเจน

รายละเอียดถัดมา ถือว่าเป็นส่วนสำคัญที่สุดเลยก็ว่าได้ค่ะ คือการระบุ Actual Result และ Expected Result ให้ชัดเจน เพื่อให้ Dev เข้าใจว่าปัญหาที่เจอปัจจุบันเป็นอย่างไร และผลลัพธ์ที่ควรจะเป็น โดยอ้างอิงจาก Requirement ต้องเป็นอย่างไร

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

ตัวอย่างการเขียน Actual Result เมื่อเทส API

• การเขียน Expected Result จะต้องระบุที่ผลลัพธ์ที่ควรจะเป็นและหากมีรูปแนบด้วยก็จะเป็นประโยชน์ให้กับ Dev มากขึ้นค่ะ Dev จะได้ไม่ต้องกลับไปหาที่ Requirement หรือ Designโดยเฉพาะกรณีที่เป็น Bug เกี่ยวกับเรื่องของ UI ค่ะ

ตัวอย่างการเขียน Actual Result และ Expected Result

1.4 ใส่ข้อมูลอื่นๆที่เป็นประโยชน์ (กรณีมีข้อมูล)

สุดท้ายแต่ไม่ท้ายสุดนี้ หากมีข้อมูลที่เพื่อนๆคิดว่าเป็นประโยชน์กับ Dev ในการ Investigate หาสาเหตุของการเกิด Bug อย่าลืมใส่ข้อมูลเหล่านั้นเข้าไปด้วยนะคะ ยกตัวอย่างเช่น ยี่ห้อและรุ่นของเครื่องที่เทส (กรณีเทส Mobile Application), Version ของเครื่องที่เทส เป็นต้นค่ะ โดยจะใส่เป็น Note เพิ่มเติมหรือระบุใน Field ที่เกี่ยวข้อง(หากมี) ก็ได้ค่ะ

ตัวอย่างการใส่ข้อมูลอื่นๆที่มีประโยชน์

2. Trick สำหรับการเขียนการ์ด Bug ที่ช่วยให้ Dev เข้าใจง่ายมากขึ้น

2.1 เขียน Actual Result และ Expected Result เป็นตาราง
กรณีที่มี Actual Result และ Expected Result มากกว่า 1 ข้อ เราสามารถใช้ตารางมาช่วยในการเขียน เพื่อให้เห็นข้อผิดพลาดและความแตกต่างของ Actual Result และ Expected Result ในแต่ละข้อได้อย่างชัดเจนและง่ายกับ Dev มากยิ่งขึ้นค่ะ โดยเฉพาะ Bug ที่เกี่ยวข้องกับ Frontend หรือ UI การเขียนแบบนี้จะทำให้ Dev เห็นปัญหากับผลลัพธ์ที่ควรจะเป็น เทียบกันได้อย่างชัดเจน เพราะอยู่ในตารางบรรทัดเดียวกัน โดยช่องซ้ายจะเป็น Bug และช่องขวาจะแสดงผลลัพธ์ที่ถูกต้องค่ะ

ลองดูตัวอย่างเปรียบเทียบการเขียน Actual & Expected Result แบบปกติ และแบบเป็นตารางจากรูปด้านล่างดูนะคะ เพื่อนๆว่าแบบไหนอ่านง่ายมากกว่ากันคะ (?)

ตัวอย่างการเขียน Actual & Expected Result แบบปกติ (ซ้าย) และแบบตาราง (ขวา)

2.2 ใช้สีเข้าช่วย

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

ตัวอย่างการใช้สีในการเขียนการ์ด Bug

2.3 ไฮไลท์บริเวณจุดที่เป็นบัค

อีกหนึ่งจุดที่ชาว QA แบบเราๆ อาจจะลืมหรือมองข้ามกันไปคือ การไฮไลท์หรือวงบริเวณจุดที่ผิดพลาด เพื่อให้ Dev เห็นภาพชัดเจนและเข้าใจตรงกันกับเรานั้นเองค่ะ!

เป็นยังไงกันบ้างคะทุกคนกับการเขียนการ์ด Bug ให้มีรายละเอียดที่ครอบคลุม และ Trick เล็กๆน้อยๆ ในการเขียนการ์ดที่จะช่วยให Dev เข้าใจง่ายขึ้นค่ะ หวังว่าบทความนี้จะเป็นประโยชน์ให้กับเหล่าชาว QA หรือบุคคลที่สนใจ ไม่มากก็น้อยนะคะ :))) ก่อนจะจากกันไป ขอขอบคุณทีม QA ที่ได้มีการแชร์ความรู้และสิ่งสำคัญของการเปิดการ์ด Bug รวมถึงทีมงาน Dev ทุกท่านที่ได้ทำงานด้วยกันมา จึงทำให้เกิดไอเดียปรับแต่งการเขียนการ์ด Bug ให้ดียิ่งขึ้นและเกิดเป็นบทความนี้ขึ้นมาค่ะ :D แล้วพบกันใหม่ในบทความหน้านะคะ สวัสดีค่า~