บทความ IT เจ๋งๆ
วิธีเขียน Bug Report ให้มีประสิทธิภาพ
12-ต.ค.-18
คัมภีร์เทพ IT
เชื่อว่าใครที่ทำงานกับคอมพิวเตอร์ล้วนเจอ Bug กันมาแล้วทั้งสิ้น แต่ในฐานะของคนไอทีจะจัดการกับปัญหานั้นอย่างไร และหาทางที่จะทำงานกับ user ให้ราบรื่นได้อย่างไร ซึ่งแต่ละทีม/บริษัท คงมีวิธีดำเนินการแตกต่างกันออกไป วันนี้จึงนำบทความที่เขียนโดย Kerry Jones เกี่ยวกับ วิธีเขียน Bug Report ให้มีประสิทธิภาพ มาให้ได้อ่านกัน เชื่อว่ามีประโยชน์กับคนไอทีเป็นอย่างมาก
วัตถุประสงค์ของบทความนี้ เขียนขึ้นเพื่อให้ทั้งฝ่ายไอทีและ users มีความเข้าใจและข้อตกลงเพื่อจะได้ทำงานร่วมกันอย่างราบรื่นและมีประสิทธิภาพ สำหรับ Engineer หรือทีมไอทีที่เกี่ยวข้อง สามารถใช้ประโยชน์จากบทความนี้ โดยการไปอธิบายให้ user เข้าใจ รวมทั้งประยุกต์แบบฟอร์ม(ในช่วงท้ายของบทความ)ไปใช้ให้เหมาะกับทีมหรือหน่วยงานของคุณได้ แต่ก่อนอื่นเรามาปูพื้นกันด้วยสมมติฐานเหล่านี้ก่อนที่จะเข้าเรื่อง:
- คุณกำลังทำงานร่วมกับทีมของคุณที่มีมากกว่า 1 คน
- Engineer มีอำนาจหรือมีอิทธิพลในการตัดสินใจว่าจะแก้ไข Bug ใดบ้าง
- Engineer มีหน้าที่รับผิดชอบมากกว่าทำตามคำสั่งของ users เพียงอย่างเดียว (มิฉะนั้น user จะเรียกร้องสิ่งที่คุณต้องการได้ตามอำเภอใจ)
- คำนึงถึงมุมมองของเพื่อนร่วมงาน ไม่ใช่ random user
คำจำกัดความ ของคำว่า “Bug”
สาเหตุของปัญหาที่มักเจอ คือ เรามักใช้คำจำกัดความของคำว่า “bug” ที่แตกต่างกัน เพื่อให้สามารถทำงานร่วมกันได้ และหลีกเลี่ยงความขัดแย้ง สิ่งสำคัญคือต้องตัดสินใจว่า Bug คืออะไร และนี่เป็นคำจำกัดความของ Bug:
- สิ่งที่ทำให้เกิดสิ่งอื่นที่ไม่ได้คาดหวังไว้
- สิ่งที่ทำให้เกิด “bad user experience”
- สิ่งที่สามารถแก้ไขได้ภายในเวลาไม่ถึง 1 ชั่วโมง
แต่ในคำจำกัดความของวิกิพีเดียคือ "ครอบคลุมทุกอย่าง"
" software bug คือ ข้อผิดพลาด ข้อบกพร่อง ความล้มเหลว หรือ ความผิดพลาดในโปรแกรมหรือระบบคอมพิวเตอร์ ที่ทำให้เกิดผลลัพธ์ที่ไม่ถูกต้อง หรือไม่คาดคิด หรือกระทำการด้วยวิธีที่ไม่ได้ตั้งใจจะให้ทำ "
คำจำกัดความ ที่น่าสนใจ ก็คือ
"การกระทำหรือสถานะ ที่ก่อให้เกิดผลที่ไม่ได้ตั้งใจจะให้เกิด" แต่ข้อบกพร่องที่สำคัญของคำจำกัดความนี้ก็คือ เราจะต้องมีความรู้ว่า อะไรคือผลที่ไม่ได้ตั้งใจจะให้เกิด ในกรณีของบทความนี้ จะขอให้พิจารณาตามที่ตั้งสมมติฐานไว้ 3 ข้อด้านบน
การเขียน Bug Report
เพื่อนร่วมงาน (Co): "Website มีปัญหา"
Software Engineer (E): "ส่วนใด?"
Co: "ที่ Site หลัก"
E: " Site หลัก มันก็ยังทำงานปกติ"
Co: "ที่ contact page"
E: "มันก็ยังปกติดีนะ - แล้วมันมีปัญหาตรงไหน?"
คุณคงจะเจอบทสนทนาในลักษณะนี้มาพอสมควร ซึ่งมันทำให้เหล่า Engineer หัวเสีย เนื่องจากความคาดหวังของทั้ง 2 ฝ่าย ไม่เป็นไปตามต้องการ
ในฐานะของ User เองอาจรู้สึกผิดหวัง เพราะต้องหยุดการทำงานที่ทำอยู่ ซึ่งอาจเป็นความผิดของ Engineer สักคน คุณมี deadline / ลูกค้ารออยู่ / ต้องรีบไปทำงานต่อไป จะมีใครสักคนช่วยแก้ไขได้ไหม? อันที่จริงสิ่งที่คุณคิดมันไม่ผิดหรอก มันเป็นความรับผิดชอบของ Engineer ที่จะต้องทำให้สิ่งต่างๆ ทำงานได้อย่างมีประสิทธิภาพ ต้องทดสอบมัน และทำให้มันสามารถทำงานได้ แต่ในความเป็นจริง ทุก system ย่อมมี bug นั่นไม่ได้หมายความว่าคุณซึ่งเป็นเพื่อนร่วมงานจะต้องมานั่งพิมพ์เอกสารรายงานเรื่อง bug เองทั้งหมด แต่ถ้าคุณไม่ช่วยมันก็ยากที่ Engineer จะช่วยแก้ปัญหาให้ได้ การเขียน bug report ที่ดีจะช่วยลดการส่งงานกันไป-มา ถ้าทุกอย่างชัดเจนตรงประเด็นจะช่วยลดเวลาแก้ปัญหาลงเหลือเพียง 1-2 ชั่วโมง แทนที่จะเป็นวันหรือเป็นสัปดาห์
ดังนั้น ในฐานะ Engineer คุณอาจะช่วยออกแบบให้ user ของคุณเขียน bug report ที่ชัดเจนและตรงประเด็น ตามหัวข้อต่อไปนี้
- Title (หัวข้อ)
- Steps to reproduce (วิธีการทำซ้ำ)
- Expected result (ผลที่คาดหวัง)
- Actual result (ผลตามจริง)
- Attachments (ข้อมูลแนบ)
- Impact (ผลกระทบ)
หมายเหตุ: มันจะมีประโยชน์มากหากใน 1 bug report มีเพียง 1 ปัญหา เพราะ Engineer จะได้ติดตามผลและแก้ไขได้อย่างรวดเร็ว หากมีหลายปัญหาอาจทำให้ Engineer ใช้เวลาแก้ไขนานหลายชั่วโมงซึ่งให้คนเดียวทำทั้งหมดอาจไม่เหมาะสมและการแก้ไขปัญหาหนึ่งอาจไปกระทบจนเกิดปัญหาที่ใหญ่ขึ้นได้ หากเราแยกปัญหาออกเป็นเรื่องๆ จะทำให้ Engineer หลายๆ คนเข้ามารับผิดชอบงานที่แต่ละคนถนัดได้
Title
คำอธิบายโดยย่อ/สั้นๆ เกี่ยวกับสิ่งที่เกิดขึ้น ควรให้ข้อบ่งชี้ว่าส่วนใดของ system ที่ได้รับผลกระทบ ควรระบุว่าเกิดอะไรขึ้น
สิ่งที่ไม่ถูกต้อง: “ไม่สามารถอ่านข้อความบน website”
สิ่งที่ถูกต้อง: “ใน Contact page เกิด text overlap หลังจากคลิก submit”
Steps to reproduce
หาก bug นั้น คุณสามารถทำมันได้อีกซ้ำๆ ด้วยความตั้งใจหรือรู้วิธีที่จะทำมัน นี่คือข้อมูลที่สำคัญมากที่จะช่วยให้ Engineer แก้ไข bug ได้ตรงจุด แต่หากไม่สามารถทำซ้ำได้ คุณก็สามารถให้ข้อมูลเท่าที่คุณสามารถได้ว่ามันเกิดขึ้นได้อย่างไร
สิ่งที่ไม่ถูกต้อง:
1. ไปที่ Contact Page
2. Submit ฟอร์ม
3. เกิดText overlapped
สิ่งที่ถูกต้อง:
1. คลิก “Contact” link จาก Home Page บน navigation bar ด้านบน
2. พิมพ์ “Jane” ใน name field, “jane@doe.com” ใน email field, และ “hello” ใน message field
3. คลิกปุ่ม “Submit”
4. เกิด Text overlap ขึ้น
Expected result
ทั้ง Engineer และ User มักเกิดความสับสนเมื่อ report ขาดข้อมูลนี้ไป โดย User คิดว่ามันชัดเจน ขณะที่ Engineer ไม่เข้าใจสิ่งที่ User บ่น เช่น "ฉันคลิก Create แต่ฉันยังคงอยู่ในหน้าเดิม" ตัว User เองอาจรู้สึกว่ามันควรต้องเปลี่ยนแปลงหลังกดปุ่ม อย่าลืมว่ามี Engineer บางคนรู้ว่าเมื่อคลิก Create แล้วจะเปลี่ยนหน้าใหม่ แต่บางคนก็อาจไม่รู้ การระบุความคาดหวังของคุณจะช่วยให้แก้ปัญหาได้เร็วและลดการทำงานซ้ำไปซ้ำมา และหลีกเลี่ยงการใช้ circular logic
สิ่งที่ไม่ถูกต้อง: “ฉันคาดว่า contact page จะไม่มีปัญหา" (circular logic)
สิ่งที่ถูกต้อง: “ฉันคาดว่า contact page หลังจาก submit จะไปสู่ ‘Thank You’ page โดยไม่เกิด text overlap”
Actual result
ในขั้นตอนนี้ บางคนอาจได้เขียนไปใน Title แล้ว หากเขียนอีกซะเป็นการทำซ้ำ แต่คุณอาจเพิ่มเติมรายละเอียดที่มากขึ้นในส่วนนี้
สิ่งที่ไม่ถูกต้อง: “Text overlay”
สิ่งที่ถูกต้อง: “ฉันคลิก submit, เห็น icon ที่กำลัง loading แล้ว, จากนั้นสิ่งที่ดูเหมือนกล่องข้อความปรากฏในแบบฟอร์มที่ขึ้นมา thank you for submitting”
Attachments
มันง่ายมากที่สุดจะทำ screen shot ของ error ที่เจอ และจะดีมากขึ้นหากมีทั้งสถานะทั้งก่อนและหลัง แบบนี้จะช่วยให้ Engineer เห็นภาพและเข้าใจมันได้เร็วขึ้น
Impact
นี่เป็นขั้นตอนหนึ่งที่คนมักจะเพิกเฉย เนื่องจากหลายคนไม่ให้ความสำคัญกับขั้นตอนนี้ คุณควรระบุ priority ด้วยว่าเป็น “Low”, “Medium”, “High”, “Urgent”
"Impact" คือการบอกถึงความเข้าใจของคุณเกี่ยวกับผลกระทบของ bug มันจะช่วยให้ Engineer สันนิษฐานถึงข้อมูลเพิ่มเติมเกี่ยวกับ bug อื่นๆ และปัญหาที่เกิดขึ้นเพื่อจัด priority ได้อย่างเหมาะสม ควรมีการทำ " urgent" checkbox ด้วย ซึ่งช่อง checkbox นี้ควรส่งสัญลักษณ์ ping หรือสถานะพิเศษในข้อความที่ระบุว่า user เชื่อว่าเป็นเรื่องเร่งด่วน วิธีนี้สามารถช่วยให้ Engineer ได้รับการแจ้งเตือนอย่างรวดเร็วหากมีบางสิ่งที่สำคัญเกิดปัญหา และหากเป็นไปได้ให้ระบุ impact ด้วยตัวเลข
สิ่งที่ไม่ถูกต้อง: “มันไม่อนุญาตให้ฉันส่ง contact requests”
สิ่งที่ถูกต้อง: “department ของฉันมีการส่งประมาณ 20 contact requests ต่อวัน ซึ่งตอนนี้มันหยุดไปเนื่องจาก เราไม่แน่ใจว่ามันยังทำได้อยู่หรือไม่”
นี่คือตัวอย่างของ bug report ที่มีประสิทธิภาพ
Title
Contact page text overlaps after clicking submit
Steps to reproduce
1. Clicked “Contact” link from Home Page on the top navigation bar
2. I typed in “Jane” in name field, “jane@doe.com” in the email field, and “hello” in the message field
3. I clicked the “Submit” button
4. Text overlapped
Expected result
I expected the contact page, on submit, to take me to another ‘Thank You’ page without any overlapping text.
Actual result
I clicked submit, a loading icon appeared, then what looked like a box of text appeared over the form that said thank you for submitting.
Attachments
(attach your screenshot)
Impact
My department usually sends 20 contact requests per day which is now stopped because we’re not sure if they are going through.
ที่มา: https://itnext.io/
รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert
|
|
อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ
|
|
บทความที่เกี่ยวข้อง