1 คะแนน โดย kyo3553 7 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

สวัสดีครับ/ค่ะ ผม/ฉันกำลังสร้าง QAMap ซึ่งเป็น CLI แบบโลคัลที่อ่านบริบทการเปลี่ยนแปลงของ PR และออกแบบ QA ที่จำเป็นให้

คอขวดที่ผม/ฉันรู้สึกได้ในทีมผลิตภัณฑ์ไม่ใช่การเขียนโค้ดทดสอบ แต่เป็นกระบวนการที่ต้องกลับมาตัดสินใจใหม่ในทุก PR ว่า “การเปลี่ยนแปลงครั้งนี้ต้องพิสูจน์อะไร” ตอนแรก QAMap วิเคราะห์ diff และโครงสร้างโปรเจกต์เพื่อแนะนำร่าง E2E ด้วย Playwright และ Maestro แต่ในการใช้งานจริง มันยังหยุดอยู่แค่สิ่งที่นักพัฒนารู้อยู่แล้วกับการทดสอบหน้าจอสำเร็จแบบง่าย ๆ

ดังนั้นผม/ฉันจึงเปลี่ยนเป้าหมาย แทนที่จะพยายามเข้าใจทุกโดเมนให้สมบูรณ์ QAMap จะใช้ commit และ diff เป็นหลักฐานเพื่อสรุปเจตนาของการเปลี่ยนแปลงและ flow ของฟีเจอร์ แล้วเสนอ QA ที่มีโอกาสตกหล่นสูงในกลุ่มกรณีปกติ กรณีล้มเหลว ขอบเขต และการเปลี่ยนสถานะ สำหรับการตัดสินที่ยากจะมั่นใจ จะแสดงเหตุผลและระดับความเชื่อมั่นประกอบด้วย

เป้าหมายสุดท้ายคือเป็นเครื่องมือ QA แบบโลคัลที่เมื่อมีการลงทะเบียน PR แล้ว จะค้นหาฟีเจอร์ที่ได้รับผลกระทบ จัดเตรียม E2E ที่จำเป็นพร้อม mock และ fixture รันอย่างปลอดภัย แล้วทิ้งหลักฐานการตรวจสอบไว้ด้วย ปัจจุบันอยู่ที่ v0.4.0 และกำลังอัปเดตโดยตรวจสอบกรณีที่ผิดพลาดใน repository จริงทีละกรณีเพื่อเข้าใกล้เป้าหมายนั้น

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

1 ความคิดเห็น

 
jeongjin0 1 시간 전

แนวทางที่เสนอกรณีขอบเขต/การเปลี่ยนสถานะโดยอิงจาก diff บนเครื่องโลคัลถือว่าดีครับ หากมองเห็นได้ชัดขึ้นว่าแต่ละสถานการณ์ดึงหลักฐานมาจาก diff hunk หรือไฟล์ใด ก็น่าจะช่วยให้คัดกรอง false positive ตอนรีวิวได้สะดวกขึ้น