กำไร:
- ความสามารถในการแปลงการสังเกตที่กระจัดกระจายให้เป็นรายงานที่มีชื่อที่ชัดเจน ขั้นตอนการสร้างซ้ำตามที่กำหนด ผลลัพธ์ที่คาดหวัง/ตามจริง และหลักฐานโดยได้รับการสนับสนุนจากปัญญาประดิษฐ์
- ความสามารถในการกำหนดกฎ 'ใช้เฉพาะข้อมูลที่ฉันให้เท่านั้นอย่าสร้างมันขึ้นมา' กับปัญญาประดิษฐ์และรับประกันความสามารถในการทำซ้ำด้วยการควบคุมของตัวเอง
- สามารถแยกแยะระหว่างความรุนแรง (ผลกระทบทางเทคนิค) และลำดับความสำคัญ (ความเร่งด่วนทางธุรกิจ) และให้ป้ายกำกับสุดท้ายพร้อมบริบททางธุรกิจ
จุดบกพร่องที่ผู้ทดสอบพบจะมีประโยชน์ก็ต่อเมื่อได้รับการแก้ไขแล้วเท่านั้น การแก้ไขจะขึ้นอยู่กับคุณภาพของรายงานข้อบกพร่องเป็นส่วนใหญ่ ซึ่งเป็นบันทึกที่บันทึกข้อบกพร่องในลักษณะที่นักพัฒนาสามารถเข้าใจ ทำซ้ำ และแก้ไขได้ รายงานข้อผิดพลาดที่เขียนไม่ดี ("การเข้าสู่ระบบใช้งานไม่ได้") จะทำให้นักพัฒนาหยุดชะงักเป็นเวลาหลายชั่วโมง ทำให้เกิดการติดต่อกันกลับไปกลับมา และมักจะปิดเป็น "ไม่สามารถทำซ้ำได้" รายงานที่ดีประกอบด้วยขั้นตอนที่ชัดเจน ผลลัพธ์ที่คาดหวังและที่เกิดขึ้นจริง ข้อมูลบริบท และหลักฐาน ปัญญาประดิษฐ์ (AI) เก่งมากในการเปลี่ยนการสังเกตที่กระจัดกระจายของคุณให้เป็นรายงานที่มีโครงสร้างแบบมืออาชีพ แต่ข้อแม้หลักก็มีผลเช่นกัน: AI ไม่สามารถสร้างขั้นตอนที่คุณไม่เห็นได้ สามารถกรอกข้อมูลที่ขาดหายไปได้ “ดูสมเหตุสมผล” แต่คาดเดาไม่ถูกต้อง งานของคุณคือตรวจสอบให้แน่ใจว่าทุกบรรทัดของรายงานอิงจากสิ่งที่คุณสังเกตเห็นจริง
กายวิภาคของรายงานข้อผิดพลาดที่ดี
รายงานที่มีประสิทธิภาพประกอบด้วยองค์ประกอบเหล่านี้:
- ชื่อเรื่อง: สั้น เฉพาะเจาะจง ค้นหาได้ ไม่ใช่ "มีข้อผิดพลาด"; "ไม่สามารถคลิกปุ่ม 'ชำระเงิน' ที่มีสินค้าในรถเข็นมากกว่า 10 รายการ (Chrome)"
- ขั้นตอนในการทำซ้ำ: มีการกำหนดหมายเลข ติดตามได้ตั้งแต่ต้น กำหนดได้ นักพัฒนาควรจะสามารถเห็นข้อผิดพลาดได้หลังจากทำตามขั้นตอนเหล่านี้
- ผลลัพธ์ที่คาดหวัง: สิ่งที่ควรเกิดขึ้นตามเกณฑ์การยอมรับ
- ผลลัพธ์ที่แท้จริง: เกิดอะไรขึ้น (ข้อความแสดงข้อผิดพลาด หน้าจอ พฤติกรรม)
- สภาพแวดล้อม: เบราว์เซอร์/อุปกรณ์ เวอร์ชัน สภาพแวดล้อม (ทดสอบ/ใช้งานจริง) บทบาทของผู้ใช้ ข้อมูล
- หลักฐาน: ภาพหน้าจอ วิดีโอ บันทึก การติดตามข้อผิดพลาด (การติดตามสแต็ก)
- ความร้ายแรงและลำดับความสำคัญ: มีรายละเอียดด้านล่าง
เคล็ดลับ: ก่อนที่จะส่งรายงาน ให้ถามว่า "ถ้าฉันให้ขั้นตอนเหล่านี้กับคนอื่น พวกเขาจะมองเห็นข้อผิดพลาดได้หรือไม่หากไม่ได้รับความช่วยเหลือ" ถาม. หากคำตอบคือ "ไม่" แสดงว่ารายงานไม่สมบูรณ์ AI สามารถทำให้รายงานสวยงามได้ แต่มีเพียงคุณเท่านั้นที่สามารถรับประกันความสามารถในการทำซ้ำได้
ความรุนแรงและลำดับความสำคัญ: สองแนวคิดที่สับสน
ระดับความรุนแรงเป็นผลทางเทคนิคของข้อผิดพลาด: ระบบขัดข้อง ข้อมูลสูญหาย หรือพิมพ์ผิดหรือไม่ ลำดับความสำคัญคือต้องแก้ไขอย่างเร่งด่วนเพียงใด เป็นเรื่องเกี่ยวกับผลกระทบทางธุรกิจ ทั้งสองไม่ได้ไปในทิศทางเดียวกันเสมอไป การสะกดชื่อบริษัทในหน้าแรกผิดนั้นมีความรุนแรงต่ำ แต่มีลำดับความสำคัญสูง (ชื่อเสียง) ในกรณีที่พบไม่บ่อย การล่มสลายอาจมีความรุนแรงสูงแต่มีลำดับความสำคัญต่ำ AI ช่วยให้คุณสร้างความแตกต่างนี้เมื่อคุณให้การสังเกต แต่ป้ายกำกับสุดท้ายจะได้รับจากคุณที่ทราบบริบททางธุรกิจ
ความรุนแรง
ตัวอย่าง
ลำดับความสำคัญ
ตัวอย่าง
สำคัญ (ตัวบล็อก)
ไม่สามารถชำระเงินให้เสร็จสิ้นได้
ด่วน (P1)
การสูญเสียรายได้จากการถ่ายทอดสด
สูง (เมเจอร์)
รายงานให้ผลรวมไม่ถูกต้อง
สูง (P2)
สิ่งจำเป็นสำหรับการเปิดตัวที่กำลังจะมาถึง
ปานกลาง (รอง)
ข้อผิดพลาดตัวพิมพ์เล็กที่หายาก
ปานกลาง (P3)
ในการวิ่งตามแผน
ต่ำ (เล็กน้อย)
การจัดตำแหน่งปุ่มปิดอยู่
ต่ำ (P4)
เมื่อมีโอกาส
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
อ่อนแอ: "รายงานข้อผิดพลาดนี้: การชำระเงินไม่ทำงาน"
แข็งแกร่ง: "แปลข้อสังเกตของฉันด้านล่างเป็นรูปแบบรายงานข้อบกพร่องมาตรฐาน: ชื่อ ขั้นตอนการทำซ้ำ (หมายเลข) ผลลัพธ์ที่คาดหวัง ผลลัพธ์จริง สภาพแวดล้อม ระดับความรุนแรง และคำแนะนำลำดับความสำคัญ (ถูกต้อง) ใช้เฉพาะข้อมูลที่ฉันให้ไว้ สร้างฟิลด์ที่ขาดหายไป ทำเครื่องหมาย 'ข้อมูลที่ขาดหายไป: ...' ข้อสังเกต: Chrome 120 สภาพแวดล้อมการทดสอบ 12 รายการในรถเข็น ไม่มีอะไรเกิดขึ้นเมื่อฉันกด 'ชำระเงิน' ข้อผิดพลาด 'ไม่ได้กำหนดไม่ใช่ฟังก์ชัน' ในคอนโซล ไม่มี ปัญหากับสินค้า 11 รายการ"
พรอมต์อันทรงพลัง; กำหนดรูปแบบ กฎ "ความเหมาะสม" และการทำเครื่องหมายข้อมูลที่ขาดหายไป วิธีนี้จะทำให้รายงานมีความถูกต้องและตรงไปตรงมา
การตรวจจับข้อผิดพลาดซ้ำซ้อน
ในทีมขนาดใหญ่ ข้อผิดพลาดเดียวกันนี้จะถูกรายงานซ้ำแล้วซ้ำอีก AI สามารถเปรียบเทียบรายงานใหม่ของคุณกับข้อบกพร่องที่เปิดอยู่และทำเครื่องหมายรายการที่อาจซ้ำซ้อนได้ ซึ่งจะช่วยให้ระบบติดตามข้อบกพร่องของคุณ (Jira, Azure DevOps, GitHub Issues) สะอาดตา แต่ระวัง: ข้อผิดพลาดสองประการที่ปรากฏบนพื้นผิวที่คล้ายกันอาจมีสาเหตุที่แท้จริงที่แตกต่างกัน เปรียบเทียบขั้นตอนการผลิตซ้ำและสภาพแวดล้อมของทั้งสองรายงาน ก่อนที่จะปิดคำแนะนำ "ซ้ำ" ของ AI "ซ้ำ" ที่ปิดโดยไม่ตั้งใจจริง ๆ แล้วไม่มีข้อผิดพลาดแยกต่างหาก
จากการติดตามจุดบกพร่องไปจนถึงสาเหตุที่แท้จริง: พลังของ AI ในการอ่านบันทึก
ส่วนทางเทคนิคส่วนใหญ่ของรายงานข้อบกพร่องมักจะเป็นการติดตามข้อบกพร่อง (การติดตามสแต็ก — รายละเอียดว่าบรรทัดของโค้ดใดที่เรียกใช้สายโซ่ที่เรียกใช้ข้อบกพร่อง) บันทึกที่ยาวและซับซ้อนอาจทำให้แม้แต่นักพัฒนายางเบื่อได้ AI อ่านบันทึกบรรทัดหลายร้อยบรรทัดและสรุปบรรทัดที่สำคัญที่สุด สมมติฐานสาเหตุที่เป็นไปได้ และจุดโค้ดที่ทำให้เกิดข้อผิดพลาดในไม่กี่วินาที ซึ่งจะทำให้รายงานสั้นลงและทำให้นักพัฒนามีจุดเริ่มต้นโดยตรง
โปรดจำไว้ว่าขีดจำกัดสองประการ ประการแรก สาเหตุที่แท้จริงที่ได้รับจาก AI เป็นเพียงสมมติฐาน ไม่ใช่หลักฐาน นักพัฒนาซอฟต์แวร์ไม่ควรพยายามแก้ไขปัญหานี้โดยไม่ตรวจสอบ ประการที่สอง บันทึกมักจะมีข้อมูลส่วนบุคคล (อีเมล ID ผู้ใช้ โทเค็นเซสชัน) ปิดบังพื้นที่เหล่านี้ก่อนที่จะวางท่อนไม้ไว้บนยานพาหนะ แนวปฏิบัติที่ดีคือให้ AI พูดว่า "แสดงรายการฟิลด์ที่ต้องมาสก์ในบันทึกนี้" ก่อน จากนั้นจึงวิเคราะห์บันทึกที่ล้างแล้ว
เคล็ดลับ: แทนที่จะวางบันทึกทั้งหมดลงในรายงาน ให้รวมบรรทัดที่สำคัญที่สุด 3-5 บรรทัดที่ AI สรุปและลิงก์ไปยังบันทึกฉบับเต็ม วิธีนี้จะทำให้สามารถอ่านรายงานได้ และนักพัฒนาที่ต้องการรายละเอียดจะสามารถเข้าถึงบันทึกฉบับเต็มได้
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) จากการสังเกตสู่การรายงาน:
บทบาทของคุณ: QA อาวุโส แปลข้อสังเกตดิบต่อไปนี้เป็นรายงานข้อบกพร่องมาตรฐาน: ชื่อ / ขั้นตอนการทำสำเนา (หมายเลข) / ที่คาดไว้ / ตามจริง / สิ่งแวดล้อม / บันทึกหลักฐาน / ความรุนแรง + ลำดับความสำคัญ (จัดชิดขอบ) กฎ: ใช้เฉพาะข้อมูลที่ฉันให้ไว้เท่านั้น ทำเครื่องหมายฟิลด์ที่ขาดหายไปว่า "ข้อมูลที่ขาดหายไป:..." ข้อสังเกต: [บันทึกดิบ]
2) การควบคุมความสามารถในการทำซ้ำ:
อ่านรายงานข้อบกพร่องนี้จากมุมมองของนักพัฒนาที่ไม่เคยเห็นข้อบกพร่องมาก่อน ทำตามขั้นตอนและทำเครื่องหมายตำแหน่งที่ไม่ทำให้เกิดจุดบกพร่อง: ขั้นตอนที่คลุมเครือ ไม่มีข้อกำหนดเบื้องต้น ไม่มีข้อมูลการทดสอบ เงื่อนไขที่ข้าม บอกฉันว่าฉันควรเพิ่มข้อมูลใดสำหรับแต่ละช่องว่าง รายงาน: [วางรายงาน]
3) ที่ปรึกษาด้านความรุนแรง/ลำดับความสำคัญ:
ฉันอธิบายข้อผิดพลาดต่อไปนี้: [ข้อผิดพลาด + บริบททางธุรกิจ] ให้คำแนะนำและเหตุผลแยกกันสำหรับความรุนแรง (ผลกระทบทางเทคนิค) และลำดับความสำคัญ (ความเร่งด่วนทางธุรกิจ) อธิบายว่าเหตุใดทั้งสองจึงอาจแตกต่างกัน ฉันจะตัดสินใจครั้งสุดท้าย
4) สรุปการติดตามบันทึก/ข้อผิดพลาด:
ตรวจสอบการติดตาม/บันทึกข้อผิดพลาดด้านล่าง ให้บทสรุปของ (1) สมมติฐานสาเหตุที่แท้จริง (2) จุดรหัสที่เป็นไปได้ที่เกิดข้อผิดพลาด (3) บรรทัดที่สำคัญที่สุด 3 บรรทัดที่จะเพิ่มลงในรายงาน ปิดบังหากมีข้อมูลส่วนบุคคล บันทึก: [วางบันทึก]
มินิเคสสามอัน
กรณีที่ 1 — การหลุดพ้นจาก “ฉันไม่สามารถผลิตได้” ในทีมหนึ่ง ข้อบกพร่อง 30% ถูกปิดเนื่องจาก "ไม่สามารถแพร่พันธุ์ได้" เพิ่มเทมเพลต "การตรวจสอบการทำซ้ำ" ในกระบวนการรายงานแล้ว ก่อนที่จะส่งรายงานแต่ละฉบับ AI จะแจ้งขั้นตอนและข้อกำหนดเบื้องต้นที่ขาดหายไป สามเดือนต่อมา อัตรา "ไม่สามารถผลิตได้" ลดลงจาก 30% เป็น 8% ความแตกต่างก็คือขั้นตอนนั้นแม่นยำตั้งแต่ต้น
กรณีที่ 2 — อันตรายจากขั้นตอนปลอม ผู้ทดสอบให้ AI เขียนรายงานโดยมีการสังเกตที่ไม่สมบูรณ์ AI เพิ่มขั้นตอนที่ไม่เคยเกิดขึ้น เช่น "ผู้ใช้เปิดการแจ้งเตือนจากหน้าการตั้งค่า" เมื่อนักพัฒนาทำตามขั้นตอนนั้น เขาไม่พบข้อผิดพลาดและเสียเวลา ทีมงานบังคับใช้กฎ "ใช้เฉพาะข้อมูลที่ฉันให้เท่านั้น อย่าสร้างมันขึ้นมา" ขั้นตอนที่จัดทำขึ้นจะหมดไป
กรณีที่ 3 — ความแตกต่างระดับความรุนแรง/ลำดับความสำคัญ มีการพิมพ์ผิดในสโลแกนของบริษัทในหน้าแรก ผู้ทดสอบจะถือว่าสิ่งนี้เป็น "ต่ำ"; ที่ปรึกษา AI เตือนว่าความรุนแรงทางเทคนิคนั้นต่ำ แต่ลำดับความสำคัญทางธุรกิจนั้นสูง (องค์ประกอบชื่อเสียงที่ผู้เยี่ยมชมทุกคนได้รับ) จุดบกพร่องได้รับการแก้ไขในวันเดียวกันกับแท็ก "ลำดับความสำคัญสูง"
ข้อผิดพลาดทั่วไป
- ชื่อคลุมเครือ พาดหัวข่าวที่ค้นหาไม่ได้และไม่เลือกปฏิบัติ เช่น "ไม่ทำงาน"
- ขาดหาย/ข้ามขั้นตอน ไม่เขียนสิ่งที่ชัดเจนในบริบทของคุณ ความล้มเหลวของนักพัฒนาในการผลิต
- ปล่อยให้ AI เข้ามาสร้างมันขึ้นมา กรอกข้อมูลที่ขาดหายไปด้วย "การประมาณการที่สมเหตุสมผล" ขั้นตอนที่ผิด
- ไม่เขียนผลลัพธ์ที่คาดหวัง บอกว่าผิดแต่ไม่ได้ระบุว่าอะไรถูก
- ความรุนแรงและลำดับความสำคัญที่สับสน เข้าใจผิดว่าทั้งสองเป็นป้ายเดียวกัน ตัดสินผลกระทบทางธุรกิจอย่างไม่ถูกต้อง
- ข้อมูลที่ละเอียดอ่อนในหลักฐาน แบ่งปันข้อมูลส่วนบุคคลที่แท้จริงในภาพหน้าจอ/บันทึกโดยไม่ปิดบัง
โดยสรุป
คุณค่าของรายงานข้อบกพร่องคือนักพัฒนาซอฟต์แวร์สามารถทำซ้ำและแก้ไขข้อบกพร่องได้โดยไม่ต้องให้คุณช่วย AI เก่งมากในการเปลี่ยนการสังเกตที่กระจัดกระจายให้เป็นรายงานที่มีโครงสร้างแบบมืออาชีพ โดยจะจัดระเบียบชื่อเรื่อง ขั้นตอน ผลลัพธ์ที่คาดหวัง/ที่เกิดขึ้นจริง สภาพแวดล้อม และหลักฐาน และให้คำปรึกษาเกี่ยวกับความแตกต่างระหว่างความรุนแรงและลำดับความสำคัญ แต่ AI สามารถชดเชยข้อมูลที่ขาดหายไปได้ บังคับใช้กฎ "ใช้เฉพาะข้อมูลที่ฉันให้ ทำเครื่องหมายว่าหายไป" และรับประกันความสามารถในการทำซ้ำด้วยตัวคุณเอง ปิดบังข้อมูลส่วนบุคคลไว้เป็นหลักฐาน
งานสมัคร
แก้ไขจุดบกพร่องที่คุณพบเมื่อเร็วๆ นี้ และเปลี่ยนการสังเกตดิบของคุณให้เป็นรายงานโดยใช้รูปแบบ "การสังเกตเพื่อรายงาน" (ด้วยกฎ "เหมาะสม") จากนั้นดำเนินการ “ตรวจสอบความสามารถในการทำซ้ำ” และกรอกข้อมูลลงในช่องว่างที่ทำเครื่องหมายไว้ มอบรายงานให้เพื่อนร่วมงานและดูว่าเขาสามารถสร้างข้อผิดพลาดได้หรือไม่โดยไม่ได้รับความช่วยเหลือจากคุณ สุดท้าย ให้กำหนดป้ายกำกับกับ "ที่ปรึกษาด้านความรุนแรง/ลำดับความสำคัญ" และสรุปตามดุลยพินิจของคุณเอง จดบันทึกข้อมูลใดๆ ที่ AI พยายามสร้างขึ้นในกระบวนการนี้
รายการตรวจสอบ
- [ ] ชื่อเรื่องของฉันเฉพาะเจาะจงและสามารถค้นหาได้
- [ ] ขั้นตอนการสืบพันธุ์เริ่มจากศูนย์ กำหนดได้ และครบถ้วน
- [ ] ฉันเขียนผลลัพธ์ที่คาดหวังและผลลัพธ์จริงแยกกัน
- [ ] ข้อมูลการตั้งค่าและหลักฐานเสร็จสมบูรณ์ ฉันปกปิดข้อมูลส่วนบุคคล
- [ ] ฉันกำหนดกฎ "ชดเชย ทำเครื่องหมายส่วนที่หายไป" บน AI และเติมเต็มช่องว่างด้วยตัวเอง
- [ ] ฉันประเมินความรุนแรงและลำดับความสำคัญแยกจากกัน และตัดสินใจขั้นสุดท้าย