วงจรงานบั๊กซอฟต์แวร์
ซอฟต์แวร์ติดตามบั๊กตั้งแต่รายงานจนถึงการแก้ไขที่ตรวจยืนยันแล้ว
เก็บสภาพแวดล้อม ขั้นตอน ผลลัพธ์ที่คาดหวัง ผลลัพธ์จริง การวินิจฉัยรุ่นทดสอบบิลด์และผลตรวจยืนยันไว้กับปัญหาเดียวกันตั้งแต่รายงานแรกจนถึงการปิดที่มั่นใจได้
ลงชื่อเข้าใช้เพื่อตรวจมุมมองที่มีข้อมูลนี้ จากนั้นติดตั้ง App พร้อมข้อมูลตัวอย่างเพื่อทดสอบเรคคอร์ด การตัดสินใจ และแดชบอร์ดที่เชื่อมกัน
หลักฐานที่เรคคอร์ดบั๊กต้องมี
บั๊กเครื่องมือติดตามควรตอบคำถามสี่ข้อได้โดยไม่ต้องไล่หาในแชตและสเปรดชีต: ปัญหาทำซ้ำได้ไหม ใครรับผิดชอบการแก้บิลด์ไหนมีการเปลี่ยนแปลง และ QA ตรวจยืนยันบิลด์นั้นแล้วหรือยัง Jodoo เชื่อมคำตอบเหล่านี้ พร้อมให้ทีมปรับฟิลด์และการกำหนดเส้นทางเมื่อผลิตภัณฑ์เปลี่ยน
- ฟิลด์การทำซ้ำมาก่อนระดับความรุนแรงและลำดับความสำคัญ
- งานแก้ไขที่ลิงก์กับรุ่นเป้าหมายที่ระบุชื่อ
- ประวัติผ่าน ไม่ผ่าน ถูกบล็อก และเปิดซ้ำ แยกตามบิลด์
เส้นทางปิดงานที่อธิบายได้
ปิดงานหลังจากรุ่นทดสอบบิลด์ผ่านเท่านั้น
สถานะที่เขียนว่า "เสร็จแล้ว" ยังไม่เพียงพอ หากทดสอบผิดบิลด์หรือขั้นตอนทำซ้ำเปลี่ยนไป
รายงานอาการ
เก็บเส้นทางที่ทำซ้ำได้สั้นที่สุด สภาพแวดล้อม และหลักฐาน
ยืนยันและจัดประเภท
แยกระดับความรุนแรง ลำดับความสำคัญ สถานะซ้ำ และผู้รับผิดชอบ
วินิจฉัยและแก้ไข
บันทึกแนวทางและรหัสอ้างอิงเทียบกับรุ่นเป้าหมาย
ส่งต่อรุ่นทดสอบ
บอก QA ให้ชัดเจนว่าบิลด์ไหนพร้อมและมีอะไรเปลี่ยน
ตรวจยืนยันหรือเปิดซ้ำ
ระบุผ่าน ไม่ผ่าน หรือถูกบล็อก พร้อมหลักฐานที่ผูกกับบิลด์ที่ทดสอบ
ข้อมูลตั้งต้นดีขึ้น คัดกรองเร็วขึ้น
ขอข้อเท็จจริงที่นักพัฒนาทำซ้ำได้
ฟอร์มควรนำผู้รายงานให้ส่งข้อมูล โดยไม่ขอให้เขาตัดสินใจทางวิศวกรรม
- 01
พื้นที่ที่ได้รับผลกระทบ
องค์ประกอบ พื้นที่ผลิตภัณฑ์ และการปล่อยรุ่นหรือบิลด์
- 02
บริบทรันไทม์
สภาพแวดล้อม อุปกรณ์ เบราว์เซอร์ และการตั้งค่าที่เกี่ยวข้อง
- 03
เส้นทางที่ทำซ้ำได้
ลำดับที่สั้นที่สุดและระบุว่าปัญหาเกิดเป็นครั้งคราวหรือไม่
- 04
ความต่างที่สังเกตเห็น
แยกผลลัพธ์ที่คาดหวังและผลลัพธ์จริงออกจากกัน
- 05
หลักฐาน
ภาพหน้าจอ วิดีโอบันทึกหน้าจอ บันทึกระบบ หรือรหัสตัวอย่าง
- 06
ผลกระทบทางธุรกิจ
ใครถูกบล็อก และมีวิธีแก้ชั่วคราวหรือไม่
ทำไมต้องมีชั้นปฏิบัติการที่ปรับแต่งได้
ปรับกระบวนการได้โดยไม่ต้องสร้าง App ใหม่
ทีมธุรกิจเปลี่ยนฟิลด์ มุมมอง การกำหนดเส้นทาง และแดชบอร์ดได้เมื่อแนวทางการปล่อยรุ่นเติบโตขึ้น
เมื่อ Jodoo เหมาะกับงาน
คุณต้องการกระบวนการร่วมกันระหว่างผู้เกี่ยวข้องเชิงเทคนิคและธุรกิจ พร้อมการรับเรื่องแบบกำหนดเอง การตัดสินใจโดยคน และการมองเห็นระดับจัดการ
เพิ่มพื้นที่ผลิตภัณฑ์ ฟิลด์ผลกระทบต่อลูกค้า หรือการทบทวนการปล่อยรุ่นได้โดยไม่ต้องรอโครงการซอฟต์แวร์แบบกำหนดเอง
เมื่อเครื่องมือแบบ ที่ผูกกับเครื่องมือนักพัฒนา เหมาะกว่า
ความต้องการหลักคือการเชื่อมคลังโค้ด pull request, commit และ CI เข้ากับชุดเครื่องมือวิศวกรรมโดยตรง
Jodoo ประสานกระบวนการที่กว้างกว่าได้ โดยไม่อ้างว่าแทนที่ฟีเจอร์ที่อยู่กับ การควบคุมซอร์สโค้ด โดยตรง
คำถามและขอบเขต
คำถามเรื่องการติดตามบั๊กจากทีมผลิตภัณฑ์และ QA
คำตอบเชิงปฏิบัติสำหรับออกแบบเรคคอร์ดและหลีกเลี่ยงการปิดงานผิดพลาด
ทุกบั๊กซอฟต์แวร์ควรมีฟิลด์อะไรบ้าง
อย่างน้อยต้องมีองค์ประกอบและบิลด์ที่ได้รับผลกระทบ สภาพแวดล้อม ขั้นตอนทำซ้ำ ผลลัพธ์ที่คาดหวัง ผลลัพธ์จริง หลักฐาน ระดับความรุนแรง ลำดับความสำคัญ ผู้รับผิดชอบ และสถานะวงจรงาน แยกระดับความรุนแรงกับลำดับความสำคัญออกจากกัน
ควรเก็บการแก้ไขไว้บนเรคคอร์ดบั๊กหรือไม่
สำหรับทีมเล็กมาก เรคคอร์ดเดียวอาจพอ เมื่อปริมาณเพิ่มขึ้น การแยกงานแก้ไขช่วยให้บั๊กหนึ่งรายการมีรุ่นทดสอบได้มากกว่าหนึ่ง และแยกการส่งต่อด้านพัฒนาออกจากรายงานต้นทาง
อะไรควรเป็นตัวกระตุ้นให้เปิดซ้ำ
การตรวจยืนยันที่ไม่ผ่านปัญหาถดถอยหรือการเกิดซ้ำในบิลด์ถัดไปควรเปิดประเด็นซ้ำ พร้อมเก็บประวัติการแก้ไขและการทดสอบก่อนหน้าไว้
Jodoo เชื่อมกับเครื่องมือนักพัฒนาได้ไหม
Jodoo รองรับการเชื่อมต่อและเก็บข้อมูลอ้างอิงของคลังโค้ด commit, pull request และ CI ได้ App ตัวอย่างเน้นเวิร์กโฟลว์การทำงาน ไม่ได้อ้างว่ามีระบบควบคุมซอร์สโค้ดอัตโนมัติในตัว
ดูเส้นทางบั๊กแบบครบถ้วน
เริ่มจากรายงานที่ทำซ้ำได้ ไม่ใช่บอร์ดว่าง
App ตัวอย่างมีเรคคอร์ดร้ายแรง ซ้ำ เลื่อน พร้อมให้ QA ไม่ผ่าน ถูกบล็อก เปิดซ้ำ และตรวจยืนยันแล้ว





