กำไร:
- ความสามารถในการแยกแยะว่าจุดใดที่ปัญญาประดิษฐ์ช่วยประหยัดเวลาจริงในกระบวนการ QA และจุดใดที่การตัดสินใจด้านคุณภาพ เช่น 'พร้อมสำหรับการตีพิมพ์' เป็นหน้าที่ของมนุษย์ ขึ้นอยู่กับระดับความเสี่ยงของงาน
- ความสามารถในการรับรู้ความเสี่ยงของการผ่านที่ผิดพลาด และใช้ระเบียบวินัยในการตรวจสอบที่ทดสอบการทดสอบ AI ทุกครั้งโดยจงใจทำลายรหัส
- ความสามารถในการปกป้องข้อมูลการทดสอบ ข้อมูลส่วนบุคคล และคีย์ และได้รับนิสัยในการทดสอบความปลอดภัยภายในการอนุญาตและเพื่อวัตถุประสงค์ในการป้องกันเท่านั้น
พิจารณาคืนปล่อยตัว มีการทดสอบหลายร้อยครั้ง ทุกคนได้รับไฟเขียว ทีมงานโล่งใจ และซอฟต์แวร์ก็ใช้งานได้จริง เช้าวันรุ่งขึ้น ลูกค้ารายงานว่าหน้าจอการชำระเงินขัดข้อง การทดสอบเป็นสีเขียว แต่เขาไม่เห็นข้อผิดพลาด นี่เป็นฝันร้ายที่ร้ายกาจที่สุดของวิชาชีพประกันคุณภาพ (QA) นั่นคือวินัยที่ทำให้แน่ใจได้อย่างเป็นระบบว่าซอฟต์แวร์มีคุณภาพตามที่ต้องการ นั่นคือการทดสอบที่เรืองแสงเป็นสีเขียวแต่ไม่ได้ยืนยันอะไรเลยจริงๆ เมื่อปัญญาประดิษฐ์ (AI — ซอฟต์แวร์ที่แยกรูปแบบจากข้อมูลในอดีตและสร้างข้อความและโค้ด) เข้าสู่อาชีพนี้ มีทั้งความเร่งมหาศาลและการขยายขนาดของฝันร้ายนี้อย่างแน่นอน คำมั่นสัญญาเบื้องต้นของโมดูลนี้ชัดเจน: AI เป็นตัวช่วยในการทดสอบ ตัวสร้างพิมพ์เขียว และตัวคูณความคิด คุณเป็นผู้ทดสอบที่ลงนามในการตัดสินใจ "ซอฟต์แวร์นี้พร้อมสำหรับการเปิดตัวหรือไม่"
ในหน่วยแรกนี้ เราจะเน้นเรื่องวินัย ไม่ใช่เครื่องมือ คุณจะได้เรียนรู้ว่าจุดไหนที่ AI ช่วยประหยัดเวลาแบบเรียลไทม์ในกระบวนการ QA จุดไหนที่เป็นอันตราย เหตุใดกรีนที่หลอกลวงที่เรียกว่า "ผ่านผิด" จึงเป็นความเสี่ยงที่ใหญ่ที่สุด วิธีตรวจสอบแต่ละเอาต์พุต และข้อมูลใดที่คุณสามารถให้กับเครื่องมือใดได้ หากไม่มีการวางรากฐาน หน่วยต่อๆ ไปจะยังคงอยู่ในอากาศ
AI มีประโยชน์ตรงไหนในกระบวนการทดสอบ?
มาแบ่งงานการทดสอบออกเป็นสองกลุ่มใหญ่ๆ คลัสเตอร์แรก: งานซ้ำๆ ที่ผลิตได้ และฉบับร่าง การร่างกรณีทดสอบจากข้อกำหนด การแสดงรายการเบรกพอยต์ การเขียนโครงร่างโค้ดอัตโนมัติสำหรับหน้าจอ การแปลกรณีข้อผิดพลาดที่ซับซ้อนให้เป็นรายงานข้อผิดพลาดที่เรียบร้อย สรุปไฟล์บันทึกหลายร้อยบรรทัด แยกสคีมาออกจากการตอบสนองของ API ในงานเหล่านี้ AI จะลดนาทีเหลือวินาทีและไม่เหนื่อย
กลุ่มที่สอง: การตัดสินใจที่มีผลลัพธ์คือคุณภาพ ความไว้วางใจ และความรับผิดชอบ การตัดสินใจต่างๆ เช่น "เวอร์ชันนี้สามารถใช้งานได้จริงหรือไม่" "จุดบกพร่องนี้มีความสำคัญหรือสามารถเลื่อนออกไปได้หรือไม่" "ความครอบคลุมของการทดสอบนี้เพียงพอหรือไม่" "สถานการณ์นี้จับความเสี่ยงของผู้ใช้จริงหรือไม่" ฯลฯ จำเป็นต้องมีบริบท ความรู้เกี่ยวกับผลิตภัณฑ์ และความรับผิดชอบ ที่นี่ AI สร้างตัวเลือก แบบร่าง แต่คุณเป็นผู้ตัดสินใจว่า "ผ่าน/ไม่ผ่าน" และ "ไป/ไม่ไป"
มาอธิบายความแตกต่างกันในประโยคเดียว: AI แข็งแกร่งในเรื่อง "สถานการณ์ใดบ้างที่สามารถทดสอบได้ และจะเขียนโค้ดที่ทดสอบได้อย่างไร"; การตัดสินใจเป็นของคุณเมื่อมีคำถามว่า "ซอฟต์แวร์นี้ใช้งานได้จริงหรือไม่และใครเป็นผู้รับรองซอฟต์แวร์นี้"
เคล็ดลับ: ก่อนที่จะส่งมอบงานให้กับ AI ให้ถาม: “จะเกิดอะไรขึ้นหากผลลัพธ์นี้ผิดพลาดและฉันไม่สังเกตเห็น” หากคำตอบคือ "ฉันจะเสียเวลาสักสองสามนาที" มอบหมายงานได้อย่างง่ายดาย หากคำตอบคือ "ซอฟต์แวร์ผิดพลาดใช้งานได้จริง" ให้ AI สร้างแบบร่าง จากนั้นคุณจึงตัดสินใจและตรวจสอบ
ผ่านผิด: ความเสี่ยงอันดับหนึ่งของ AI ใน QA
เมื่อการทดสอบสว่างเป็นสีเขียว อาจหมายถึงสองสิ่ง: ซอฟต์แวร์ทำงานอย่างถูกต้องจริง หรือไม่เห็นจุดบกพร่องเนื่องจากเขียนการทดสอบไม่ถูกต้อง ครั้งที่สองเรียกว่าการส่งผ่านเท็จ การทดสอบบอกว่า "ผ่าน" แต่ไม่ได้ยืนยันอะไรเลยจริงๆ ความเสี่ยงนี้เพิ่มขึ้นอย่างมากในการทดสอบที่สร้างด้วย AI เนื่องจาก AI ประสบความสำเร็จอย่างมากในการเขียนการทดสอบที่ดูราบรื่นแต่ว่างเปล่า
รูปแบบการส่งผ่านหลอกที่พบบ่อยที่สุดสามรูปแบบคือ: (1) การทดสอบโดยไม่มีการยืนยัน — โค้ดทำงาน ไม่มีการยืนยัน และผ่านเสมอ (2) การทดสอบการตรวจสอบตัวเอง - ค่าที่คาดหวังของการทดสอบจะคำนวณจากผลลัพธ์ของรหัสที่กำลังทดสอบ นั่นคือไม่ว่าโค้ดจะผลิตอะไรก็ตาม การทดสอบจะยอมรับว่า "ถูกต้อง" (3) ทดสอบเพื่อยืนยันสิ่งผิด — assert มีอยู่ แต่จะตรวจสอบบางสิ่งเล็กน้อย (เช่น "การตอบสนองไม่เป็นโมฆะ") ไม่ใช่กฎเกณฑ์ทางธุรกิจที่แท้จริง
ข้อควรระวัง: แผงทดสอบสีเขียวไม่ใช่เครื่องพิสูจน์คุณภาพ อย่างดีที่สุดมันบอกว่า "การควบคุมที่เราเขียนยังไม่เสียหายในขณะนี้" อย่าสบายใจที่เห็น "ผ่าน" ในการทดสอบที่ AI สร้างขึ้น คำถามที่แท้จริงคือ การทดสอบนี้จะเปลี่ยนเป็นสีแดงหรือไม่หากฉันจงใจทำลายโค้ด ถ้ามันไม่หมุน แสดงว่าการทดสอบนั้นถือเป็นการตกแต่ง
กฎทองที่ทำซ้ำตลอดโมดูลนี้: ทดสอบทุกการทดสอบ AI โดยจงใจทำลายโค้ด หากการทดสอบยังคงเป็นสีเขียว แสดงว่าการทดสอบนั้นไม่ทำงาน (เราจะทำให้แนวคิดนี้ลึกซึ้งยิ่งขึ้นด้วยการทดสอบการกลายพันธุ์ในหน่วยที่ 10)
วินัยในการตรวจสอบ: สามขั้นตอน
AI พูดด้วยความมั่นใจ นั่นไม่ได้หมายความว่ามันเป็นเรื่องจริง พัฒนาปฏิกิริยาสะท้อนสามขั้นตอนเพื่อนำไปใช้กับทุกผลลัพธ์:
- ผูกมันเข้ากับความต้องการ ทุกกรณีทดสอบและยืนยันว่า AI สร้างขึ้นจะต้องเป็นไปตามข้อกำหนดที่แท้จริงหรือเกณฑ์การยอมรับ (เงื่อนไขที่งานต้องเป็นไปตามจึงจะถือว่า "เสร็จสิ้น") “สถานการณ์นี้ยืนยันกฎข้อใด” ถาม.
- ดูสีแดง. รันการทดสอบที่สร้างขึ้นหนึ่งครั้ง โดยทำลายโค้ด ถ้าไม่เปลี่ยนเป็นสีแดง แสดงว่าการทดสอบไม่ถูกต้อง นี่เป็นขั้นตอนที่ไม่สามารถต่อรองได้ในการทดสอบ AI
- ส่งผ่านตัวกรองบริบท ผลลัพธ์ตรงกับสิ่งที่คุณทราบหรือไม่คือพฤติกรรมของผลิตภัณฑ์ สถาปัตยกรรม และกระแสผู้ใช้จริง ความรู้โดเมนของคุณคือตัวกรองขั้นสุดท้าย
ความเป็นส่วนตัวและความปลอดภัยของข้อมูล: เกิดอะไรขึ้น?
ข้อมูลที่คุณทำงานด้วยในสภาพแวดล้อมการทดสอบมักจะมีความละเอียดอ่อน เช่น บันทึกลูกค้าจริง สำเนาฐานข้อมูลการผลิต คีย์ API ที่อยู่ระบบภายใน คุณลักษณะที่ยังไม่ได้ประกาศ จำแนกประเภทง่ายๆ: ข้อมูลเปิด (จัดทำเป็นเอกสารและเปิดเผยต่อสาธารณะ) สามารถเข้าสู่ยานพาหนะใดก็ได้ ข้อมูลภายใน (ส่วนของซอร์สโค้ด เอกสารภายใน) สำหรับเครื่องมือที่ได้รับการอนุมัติจากหน่วยงานเท่านั้น ข้อมูลที่เป็นความลับ (ข้อมูลลูกค้าจริง ข้อมูลประจำตัว รายละเอียดช่องโหว่ คีย์) จะเข้าสู่เครื่องมือที่ทำสัญญาของสถาบันเท่านั้น ซึ่งข้อมูลไม่ได้ไปที่การฝึกอบรมแบบจำลอง หากปกปิดไว้จะดีกว่า
มีข้อจำกัดเพิ่มเติมในบริบทของการทดสอบความปลอดภัย: ทุกสิ่งที่เรียนรู้ในโมดูลนี้มีไว้เพื่อวัตถุประสงค์ในการป้องกัน — เพื่อทดสอบความปลอดภัยของผลิตภัณฑ์ของคุณเองอย่างน่าเชื่อถือ การใช้ AI เพื่อแทรกซึมระบบของผู้อื่นโดยไม่ได้รับอนุญาต สร้างอาวุธให้กับจุดอ่อนที่แท้จริง หรือทดสอบระบบที่คุณไม่มีอำนาจนั้น ถือเป็นทั้งผิดหลักจริยธรรมและเป็นความผิดทางอาญา จะไม่มีการทดสอบที่ไม่เหมาะสมโดยไม่ได้รับอนุญาต (ขอบเขตและการอนุญาต)
เคล็ดลับ: ใช้ข้อมูลการทดสอบสังเคราะห์ (ผลิตขึ้นเอง) แทนข้อมูลลูกค้าจริง การขอให้ AI “สร้างข้อมูลการทดสอบที่สมจริงแต่สมมติขึ้นมา” ทั้งรักษาความเป็นส่วนตัวและกระจายกรณี Edge ที่หลากหลาย
มินิเคสสามอัน
กรณีที่ 1 — การประหยัดเวลาถูกที่แล้ว ผู้ทดสอบของทีม Ekomerce ใช้เวลา 6 ชั่วโมงในการสร้างสถานการณ์การทดสอบด้วยตนเองจากเอกสารข้อกำหนด 30 หน้าสำหรับแต่ละรุ่น เขามอบเอกสาร (ส่วนที่ไม่มีความลับทางการค้า) ให้กับ YZ และขอร่างสถานการณ์จำลองที่มีโครงสร้าง เวลาลดลงเหลือ 90 นาที เขาทุ่มเทเวลาที่บันทึกไว้ในการตรวจสอบด้วยตัวเองโดยเพิ่มกรณีขอบกฎธุรกิจที่ AI พลาดไป AI กำจัดงานที่ซ้ำซาก ปล่อยให้การตัดสินเป็นหน้าที่ของมนุษย์
กรณีที่ 2 — จับการส่งบอลปลอม นักพัฒนามีการทดสอบ AI เขียน 12 หน่วยสำหรับฟังก์ชันการคำนวณ พวกเขาทั้งหมดเป็นสีเขียว ผู้ทดสอบใช้ขั้นตอน "ดูสีแดง": จงใจเปลี่ยนเครื่องหมายบวกภายในฟังก์ชันเป็นการคูณ การทดสอบเพียง 3 จาก 12 รายการกลับเป็นสีแดง การทดสอบอีก 9 รายการไม่มีการยืนยันที่แท้จริง มันบอกแค่ว่า "ไม่ได้เกิดข้อผิดพลาด" การทดสอบการตกแต่ง 9 รายการถูกลบออก และการทดสอบจริง 5 รายการถูกเขียนแทน
กรณีที่ 3 — การกลับมาจากการละเมิดความเป็นส่วนตัว เด็กฝึกงานคนหนึ่งวางบันทึกข้อผิดพลาดซึ่งประกอบด้วยอีเมลลูกค้าจริงและตัวเลขสี่หลักสุดท้ายของบัตรจากฐานข้อมูลการผลิตลงในเครื่องมือสาธารณะ และกล่าวว่า "อธิบายข้อผิดพลาดนี้" ผู้นำ QA เข้าแทรกแซง: นี่เป็นข้อมูลส่วนบุคคลที่อยู่นอกเหนือการควบคุมและเป็นการละเมิด KVKK (กฎหมายคุ้มครองข้อมูลส่วนบุคคล) งานเดียวกันนี้ทำในยานพาหนะที่สถาบันรับรอง โดยปกปิดพื้นที่ส่วนบุคคลและเหลือเพียงร่องรอยปึกแผ่น
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) การประเมินความเหมาะสมในการทำงาน:
บทบาทของคุณ: ผู้นำอาวุโส QA ฉันจะอธิบายงานทดสอบให้คุณฟัง บอกฉันว่า (1) ว่างานนี้เป็นการร่าง/งานวิเคราะห์ที่สามารถมอบหมายให้กับ AI ได้อย่างปลอดภัย หรือเป็นการตัดสินใจด้านคุณภาพที่มนุษย์ต้องทำ (2) ต้นทุนที่อาจเกิดขึ้นจากผลลัพธ์ที่ไม่ถูกต้อง (3) การตรวจสอบที่ฉันควรทำก่อนมอบหมาย งาน: [แทรกงานที่นี่]
2) การควบคุมหลอกผ่าน:
ตรวจสอบการทดสอบด้านล่าง บอกฉัน:- การทดสอบนี้ยืนยันพฤติกรรมใด (หนึ่งประโยค)- ฉันจะทำลายโค้ดที่กำลังทดสอบเพื่อให้การทดสอบเปลี่ยนเป็นสีแดงได้อย่างไร- มีจุดอ่อนที่อาจทำให้การทดสอบนี้ผ่านเสมอหรือไม่ (การยืนยันที่ขาดหายไป การตรวจสอบความถูกต้องด้วยตนเอง การตรวจสอบเล็กน้อย) การทดสอบ: [วางการทดสอบที่นี่]
3) ทดสอบการควบคุมการปิดบังข้อมูล:
บันทึก/ข้อมูลที่ฉันจะให้คุณอาจมีฟิลด์ส่วนบุคคลหรือข้อมูลที่เป็นความลับ (อีเมล ชื่อ การ์ด กุญแจ ที่อยู่ภายใน) ขั้นแรก แสดงรายการฟิลด์ที่ต้องมาสก์ จะมาสก์แล้วส่งใหม่ครับ อย่าวิเคราะห์อย่างที่มันเป็น
4) การสร้างข้อมูลการทดสอบสังเคราะห์:
สร้างข้อมูลการทดสอบที่สมมติขึ้นมาและเหมือนจริงโดยสมบูรณ์ 20 แถวสำหรับ [โครงสร้างฟิลด์ต่อไปนี้] อย่าใช้ข้อมูลบุคคล/องค์กรที่แท้จริง รวมถึงตัวพิมพ์ขอบด้วย: พื้นที่ว่าง ข้อความยาวเกินไป ค่าจำกัด รูปแบบไม่ถูกต้อง
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
จุดอ่อน: "เขียนการทดสอบเกี่ยวกับโค้ดนี้"
Strong: "คำนวณการทดสอบหน่วยการเขียนนี้สำหรับฟังก์ชันส่วนลด เกณฑ์การยอมรับสำหรับฟังก์ชัน: ส่วนลด 10% มากกว่า 1,000 TL, ส่วนลด 20% มากกว่า 5,000 TL; จำนวนลบควรทำให้เกิดข้อผิดพลาด ระบุด้วยบรรทัดความคิดเห็นว่ากฎใดที่คุณกำลังตรวจสอบสำหรับการทดสอบแต่ละครั้ง ทดสอบค่าขีดจำกัด (999, 1,000, 1001, 5,000, 0, -1) แยกกัน ใช้การยืนยันจริงที่จะเปลี่ยนเป็นสีแดงหาก ฉันทำลายรหัส ว่างเปล่าหรือไม่เขียนยืนยันเล็กน้อย "
พรอมต์อันทรงพลัง; โดยให้เกณฑ์การยอมรับ ค่าขีดจำกัด ความคาดหวังในการตรวจสอบ และคำแนะนำการป้องกันการปลอมแปลงที่ชัดเจน พรอมต์ที่อ่อนแอเชิญชวนให้ AI เขียนการทดสอบการตกแต่ง
ข้อผิดพลาดทั่วไป
- ที่ไว้วางใจสีเขียว การคิดว่าผ่านการทดสอบคือข้อพิสูจน์ คำถามที่แท้จริงคือ: มันจะเปลี่ยนเป็นสีแดงเมื่อคุณทำลายโค้ดหรือไม่?
- การขอทดสอบโดยไม่ได้ให้เหตุผลใดๆ AI สร้างการทดสอบทั่วไปและมักไม่มีประโยชน์โดยไม่รู้ว่าต้องตรวจสอบอะไรบ้าง
- กำลังข้ามการยืนยัน ว่า "AI เขียนไว้ก็คงจริง" ความรับผิดชอบอยู่ที่ผู้ที่ใช้เอาต์พุต
- การวางข้อมูลจริง/ละเอียดอ่อนลงในเครื่องมือ การทำงานกับข้อมูลการผลิต คีย์ หรือข้อมูลส่วนบุคคล
- การทดสอบความปลอดภัยโดยไม่ได้รับอนุญาต พยายามทดสอบที่ไม่เหมาะสมโดยไม่มีขอบเขตและได้รับอนุญาต
- การใช้ AI เพื่อมอบหมายการตัดสินใจ ถามคำถามว่า “เวอร์ชั่นนี้จะออกได้ไหม?” ให้กับ AI และใส่คำตอบลงในลายเซ็น
โดยสรุป
AI เป็นตัวช่วยที่ทรงพลังในกระบวนการ QA ซึ่งช่วยเร่งการทำงานที่ทำซ้ำและผลิตได้ แต่ความรับผิดชอบในการตัดสินใจด้านคุณภาพนั้นขึ้นอยู่กับมนุษย์ ความเสี่ยงอันดับหนึ่งของ AI ในอาชีพนี้คือการผ่านหลอก: การทดสอบสีเขียวที่ดูเรียบร้อยแต่ไม่ได้ยืนยันอะไรเลย ทดสอบการทดสอบ AI ทุกครั้งโดยจงใจทำลายโค้ด ถ้าไม่เปลี่ยนเป็นสีแดง แสดงว่าการทดสอบนั้นถือเป็นการตกแต่ง เชื่อมโยงกับข้อกำหนด ดูสีแดง ส่งต่อผ่านตัวกรองบริบท ปิดบังข้อมูลที่เป็นความลับ ทำการทดสอบความปลอดภัยเพื่อวัตถุประสงค์ที่ได้รับอนุญาตและป้องกันเท่านั้น
งานสมัคร
ทำการทดสอบหน่วยที่สร้างโดย AI (หรือสร้างโดย AI) 5 ครั้งจากโครงการของคุณเอง สำหรับแต่ละ: (1) เขียนลงในประโยคเดียวที่ตรวจสอบพฤติกรรม (2) จงใจทำลายและรันโค้ดภายใต้การทดสอบและจดบันทึกจำนวนที่เปลี่ยนเป็นสีแดง (3) ทำเครื่องหมายอันที่ไม่เปลี่ยนเป็นสีแดงว่าเป็น "การทดสอบการตกแต่ง" และเขียนใหม่ด้วยการยืนยันจริง ใส่ผลลัพธ์ลงในตาราง: ชื่อการทดสอบ / กฎที่ตรวจสอบแล้ว / เสียหายหรือไม่เมื่อใช้งานไม่ได้ / การดำเนินการ
รายการตรวจสอบ
- [ ] ก่อนส่งมอบงาน ผมถามคำถามว่า "ถ้าผิดพลาดจะเสียอะไร"
- [ ] ฉันทดสอบการทดสอบ AI ทุกครั้งโดยทำลายโค้ด ฉันแทนที่อันที่ไม่เปลี่ยนเป็นสีแดงด้วยการทดสอบจริง
- [ ] ฉันเชื่อมโยงกรณีทดสอบกับเกณฑ์ข้อกำหนด/การยอมรับที่แท้จริง
- [ ] ฉันปกปิดข้อมูลที่ละเอียดอ่อน/จริงโดยไม่มอบให้กับเครื่องมือ ฉันใช้ข้อมูลสังเคราะห์ถ้าเป็นไปได้
- [ ] ฉันพิจารณาการทดสอบความปลอดภัยภายในหน่วยงานและเพื่อวัตถุประสงค์ในการป้องกันเท่านั้น
- [ ] ฉันปล่อยให้การตัดสินใจ "ว่าจะปล่อยเวอร์ชันนี้หรือไม่" ให้กับตัวเอง ไม่ใช่อยู่ที่ AI