การให้ผู้ใช้เขียนรายงานบั๊กที่ดีและมีประโยชน์

ไม่มีใครรู้วิธีที่ดีในการทำให้ผู้ใช้สามารถเขียนรายงานบั๊กแบบกึ่งดี (อ่าน: มีประโยชน์ ) ได้หรือไม่?

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

มันไม่ทำงานเมื่อฉันคลิกปุ่มสีน้ำเงิน! Ahhh ฉันเพิ่งเสียงานไปหนึ่งสัปดาห์ ... ทำให้มันใช้ได้

ไม่มีประโยชน์มากอย่างที่มันเป็น

ฉันเริ่มที่จะแก้ไขเกี่ยวกับรายการ แต่คิดว่าจะตรวจสอบกับพวกคุณว่ามีวิธีการที่คล้ายกันอยู่แล้ว

วิธีที่มีประสิทธิภาพที่สุดในการให้ผู้ใช้เขียนรายงานบั๊กที่เหมาะสมและมีประโยชน์คือ

1. เพื่อให้พวกเขาดูรายงานออนไลน์ ...
   ^{[ระบบ] ขอบคุณสำหรับการรายงานคุณสามารถค้นหาสถานะคำขอของคุณได้ที่นี่: ...}
2. ... พร้อมกับการประเมินผลและความคิดเห็นจากวิศวกรที่ได้รับมอบหมาย ...
   ^{[วิศวกร] คำขอถูกปฏิเสธเนื่องจากรายละเอียดต่อไปนี้หายไป: ...}
3. ... พร้อมตัวเลือกในการแก้ไข / ปรับปรุงรายงาน
   ^{[ผู้ใช้] มีการเพิ่มรายละเอียดที่ร้องขอโปรดประเมินอีกครั้ง: ...}

ฉันจะไปไกลเท่าที่จะอ้างว่ามันเป็นวิธีที่มีประสิทธิภาพเท่านั้น

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

รายงานข้อผิดพลาดออนไลน์ที่ผู้ใช้สามารถแก้ไขได้เป็นวิธีที่มีประสิทธิภาพมากที่สุดเพื่อผู้ใช้สอนปรับปรุง

• ^{ตัวเลือกอื่น ๆ ด้านบนคือ 1) เพื่อจัดการเซสชันการเรียนรู้แบบตัวต่อตัวกับผู้ใช้ (ใช่แน่นอนโดยเฉพาะเมื่อมีคนนับพันกระจายอยู่ทั่วโลก) หรือ 2) อธิบายสิ่งต่าง ๆ ทางโทรศัพท์ ("ดูสิถ้าคุณเห็นอึที่คุณเขียนที่บรรทัดที่ 225 ... ") มีอะไรอีกบ้าง? โอ้ 3) ทางอีเมลแน่นอน "ในอีเมลที่คุณส่งให้เราเมื่อสองเดือนก่อนคุณพูดถึง ... ไม่ใช่อีเมลนั้นคุณส่งอีเมลถึงเราห้าฉบับในวันนี้พวกเขาสามคนอยู่ในหัวข้อRe: คลิกปุ่มสีฟ้าดูที่ อันที่สอง, อันที่มีภาพหน้าจอ 10Mb ติดอยู่ ... อะไรคุณหาไม่เจอเหรอ? "}

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

ตัวอย่างเช่นเพียงรับอีเมลของผู้ใช้และให้ช่องข้อความธรรมดาพร้อมข้อความต่อไปนี้เพื่อให้สมบูรณ์:

"I did _____ , and expected ______ to happen, but ______ happened instead."

หลังจากคุณได้รับอีเมลแล้วให้ตอบกลับอัตโนมัติเพื่อรับตัวเลือกสองตัวเพื่อยืนยันว่าพวกเขาส่งข้อผิดพลาดคุณได้รับแล้วและการติดตามข้อผิดพลาดก็โอเค

คุณอาจลองพิจารณาแนวคิดจาก Mozilla และ Sun ในหัวข้อนี้:

• แนวทางการเขียนข้อผิดพลาด - บทความ Mozilla MDN
• วิธีเขียนข้อผิดพลาดที่เหมาะสม - บทความ Mozilla QMO
• วิธีการเขียนรายงานบั๊กที่มีประโยชน์ - บทความ Sun SDN

โดยเฉพาะอย่างยิ่ง (จาก Mozilla "หน้าวิธีการเขียนข้อผิดพลาดที่เหมาะสม"):

โครงร่างทั่วไปของรายงานบั๊ก

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

ดี :“ การยกเลิกการคัดลอกไฟล์ขัดข้อง File Manager”

ไม่ดี :“ ซอฟต์แวร์ขัดข้อง”

ไม่ดี :“ เบราว์เซอร์ควรทำงานกับเว็บไซต์ของฉัน”

ส่วนประกอบ : มีส่วนย่อยของซอฟต์แวร์อยู่หรือไม่ฟิลด์นี้เป็นข้อกำหนดในการส่งรายงานข้อบกพร่องใด ๆ คลิกคำว่า“ ส่วนประกอบ” เพื่อดูคำอธิบายของแต่ละองค์ประกอบ หากดูเหมือนว่าไม่เหมาะสมให้ไฮไลต์ส่วนประกอบ "ทั่วไป"

ระบบปฏิบัติการ : คุณพบระบบปฏิบัติการใด (OS) (เช่น Linux, Windows XP, Mac OS X) ตัวอย่าง:“ ถ้าคุณรู้ว่ามีข้อผิดพลาดเกิดขึ้นกับระบบปฏิบัติการมากกว่าหนึ่งประเภทให้เลือก“ ทั้งหมด” หากระบบปฏิบัติการของคุณไม่อยู่ในรายการให้เลือกอื่น ๆ ”

คำอธิบาย : รายละเอียดของรายงานปัญหาของคุณรวมถึง:

- ภาพรวม : นี่คือการสรุปรายละเอียดที่ใหญ่ขึ้นของการสรุป ตัวอย่างเช่น:“ การเลือกการลากหน้าใด ๆ ขัดข้อง Mac build ในฟังก์ชัน NSGetFactory”

- Build Id : หากต้องการดูสิ่งนี้ให้ไปที่หน้า“ เกี่ยวกับ:” ผ่านแถบตำแหน่งหรือหากคุณมีส่วนขยายของเครื่องมือทดสอบกลางคืนของ MozQA ให้ไปที่เครื่องมือ | เครื่องมือผู้ทดสอบรายคืนและเลือกตัวเลือกที่มีเอาต์พุตของบิลด์ Id ควรมีลักษณะดังนี้:“ Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3″

- งานสร้างและแพลตฟอร์มเพิ่มเติม : ข้อผิดพลาดเกิดขึ้นกับแพลตฟอร์มอื่น ๆ (หรือเบราว์เซอร์ถ้ามี) ควรมีลักษณะดังนี้:“ ไม่เกิดขึ้นกับ Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2″

ขั้นตอนในการสร้างซ้ำ : ขั้นตอนที่ย่อเล็กสุดและง่ายต่อการติดตามซึ่งจะทริกเกอร์บั๊ก หากจำเป็นต้องตรวจสอบให้แน่ใจว่าได้รวมขั้นตอนการตั้งค่าพิเศษตัวอย่างที่ดีของสิ่งนี้จะมีลักษณะดังต่อไปนี้: 1) ดูหน้าเว็บใด ๆ (ฉันใช้หน้าตัวอย่างเริ่มต้น http://www.google.com/ ) 2) ลากเลือกหน้า โดยเฉพาะในขณะที่กดปุ่มเมาส์ค้างไว้ให้ลากตัวชี้เมาส์ลงจากจุดใด ๆ ในพื้นที่เนื้อหาของเบราว์เซอร์ไปที่ด้านล่างของพื้นที่เนื้อหาของเบราว์เซอร์

ผลลัพธ์ที่แท้จริง : สิ่งที่แอปพลิเคชันทำหลังจากทำตามขั้นตอนด้านบนตัวอย่างเช่น: แอปพลิเคชันขัดข้อง

ผลลัพธ์ที่ควรได้รับ: สิ่งที่แอปพลิเคชันควรทำคือข้อผิดพลาดที่ไม่ปรากฏตัวอย่างเช่น: หน้าต่างควรเลื่อนลงด้านล่าง ควรเลือกเนื้อหาที่เลื่อน หรืออย่างน้อยแอปพลิเคชันไม่ควรผิดพลาด

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

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

ตัวอย่างเช่น "การกระทำสุดท้ายของคุณก่อนเกิดข้อผิดพลาดนี้คืออะไร", "คุณลอง ... ก่อนหน้าข้อผิดพลาดนี้หรือไม่"

ผู้ใช้จะไม่เขียนรายงานข้อผิดพลาดเช่น: "ไดรเวอร์วิดีโอของฉันไม่อัปเดตไลบรารีกราฟิกของคุณอาจเข้ากันไม่ได้กับไดรเวอร์กราฟิกเก่า"

สมมติว่าฐานผู้ใช้เป็นผู้ใช้ที่มีปัญหากับซอฟต์แวร์ที่คุณเขียน ....

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

ie มันไม่ใช่งานของพวกเขา .....

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