Workshop 3 ชั่วโมง ทำคนเดียวได้ทั้งหมด ฝึกหาจุดที่ระบบทำงานผิด และใช้ Gemini ช่วยคิด test case
ชื่อนี้จะปรากฏบนไฟล์ Word ที่ดาวน์โหลดตอนจบ เพื่อใช้เป็นหลักฐานการเข้าอบรม ระบบบันทึกชื่อและความคืบหน้าในเบราว์เซอร์นี้ หากใช้เครื่องร่วมกัน ให้กดเริ่มใหม่เมื่อทำเสร็จ
ยังไม่ได้ลงชื่อ ปุ่มบันทึกผลในแต่ละ workshop จะยังใช้ไม่ได้
บั๊ก คือ ตอนที่ระบบทำงาน ไม่ตรงกับที่ควรเป็น เช่น กดถอนเงิน 500 บาทแต่ได้ 1,000 บาท หรือกรอกเบอร์โทรเป็นตัวอักษรแล้วระบบยังรับ
คนทดสอบไม่ต้องรู้ว่าข้างในโปรแกรมเขียนอย่างไร แค่รู้ว่า ระบบควรทำอะไร แล้วลองใช้ดูว่าทำจริงหรือเปล่า
ทุกครั้งที่ลอง ให้จด 4 อย่างนี้
ถ้า “ต้องได้” กับ “ได้จริง” ไม่ตรงกัน แปลว่าเจอบั๊ก
ข้อมูลที่คนทั่วไปกรอก
ข้อมูลที่ระบบไม่ควรรับ
ค่าที่อยู่ตรงจุดเปลี่ยน บั๊กชอบซ่อนตรงนี้
ทำไมเส้นแบ่งถึงสำคัญ: คนเขียนโปรแกรมมักพลาดระหว่าง “มากกว่า 60” กับ “ตั้งแต่ 60 ขึ้นไป” ต่างกันแค่คนอายุ 60 พอดี ถ้าไม่ลอง 60 จะไม่มีวันเจอ
ถ้าฟอร์มมีหลายช่อง ให้กรอกทุกช่องให้ถูกก่อน แล้ว เปลี่ยนให้ผิดทีละช่อง
ถ้ากรอกผิดสองช่องพร้อมกันแล้วระบบเตือน เราจะไม่รู้ว่าระบบเตือนเพราะช่องไหน
เป้าหมายคือเลือกข้อมูลทดสอบอย่างมีเหตุผล คิดคำตอบที่ถูกต้องจากข้อกำหนด และอธิบายสิ่งที่พบให้คนอื่นทดสอบซ้ำได้ ไม่ใช่ลองตัวเลขให้มากที่สุด
ใช้ข้อกำหนดเป็นหลัก แล้วเปรียบเทียบผลที่ควรได้กับผลจริง โดยไม่ต้องอ่านโค้ดภายใน ทั้ง 4 Workshop ใช้แนวทางนี้ ตัวอย่างเช่น ระบบเกรดรับคะแนนแล้วแสดงเกรด เราจึงทดสอบความสัมพันธ์ระหว่างคะแนนกับเกรด
ก่อนกดทุกครั้ง: ระบุข้อมูลที่จะใส่ → อ่านกติกาที่เกี่ยวข้อง → คิดผลที่ควรได้ → ทดลอง → เปรียบเทียบและบันทึก
ข้อกำหนดไม่ชัดต้องถามให้ชัดก่อน เช่น “เบอร์ถูกต้อง” หมายถึงรูปแบบถูกต้อง หรือเป็นเบอร์ที่มีผู้ใช้งานจริง? แบบฝึกหัดนี้ตรวจเฉพาะรูปแบบ ไม่ตรวจเจ้าของเบอร์ เครือข่าย หรือการรับ OTP
แบ่งข้อมูลตามพฤติกรรมที่คาดว่าระบบควรจัดการเหมือนกัน แล้วเลือกตัวแทนจากแต่ละกลุ่ม ช่วยลดการลองข้อมูลซ้ำลักษณะเดิม ควรมีทั้งกลุ่มที่ยอมรับและกลุ่มที่ต้องปฏิเสธ [1]
| โจทย์ | กลุ่มข้อมูลที่ควรพิจารณา | เลือกตัวแทนอย่างไร |
|---|---|---|
| เกรด | ช่วงคะแนนของแต่ละเกรด / ต่ำกว่า 0 / เกิน 100 / ไม่ใช่จำนวนเต็ม / ว่าง | เลือกคะแนนกลางช่วงของทุกเกรด แล้วเพิ่มตัวแทนจากกลุ่มข้อมูลผิด |
| สมัครอบรม | ข้อมูลถูกทั้งหมด / ชื่อว่าง / อีเมลผิด / เบอร์ผิด | เริ่มจากข้อมูลถูก แล้วเปลี่ยนให้ผิดทีละช่อง |
| ค่าปรับ | คืนตรงเวลา / ยังไม่ถึงเพดาน / ถึงหรือเกินเพดาน / ข้อมูลผิด | พิจารณาว่าแต่ละกลุ่มควรได้ 0 บาท คิดรายวัน จำกัดเพดาน หรือปฏิเสธ |
| ค่าเดินทาง | ในจังหวัด / ต่างจังหวัด และวันอยู่ในช่วง / อยู่นอกช่วง | เลือกตัวแทนให้ครอบคลุมทั้งประเภทและจำนวนวัน |
การเลือกตัวแทนเป็นวิธีออกแบบการทดสอบ ไม่ได้รับประกันว่าค่าอื่นในกลุ่มจะไม่มีบั๊ก
เมื่อข้อมูลมีลำดับและมีจุดเปลี่ยนกติกา ให้ทดสอบค่าที่ขอบและค่าติดกัน เพราะการใช้เงื่อนไขมากกว่า/มากกว่าหรือเท่ากับผิดอาจทำให้พฤติกรรมผิดเฉพาะบริเวณนั้น [1]
| ขอบเขต | ชุดตัวอย่างสำหรับออกแบบ test case | สิ่งที่ต้องตรวจ |
|---|---|---|
| คะแนนเริ่มเกรดใหม่ | ถ้าจุดเปลี่ยนคือคะแนน k ให้ลอง k−1, k, k+1 | อ่านตารางเกรดเพื่อกำหนดผลของแต่ละค่า ไม่เดาจากระบบ |
| ความยาวเบอร์ 10 หลัก | 9, 10 และ 11 หลัก โดยรักษารูปแบบอื่นให้ถูก | ต้องรับเฉพาะความยาวที่โจทย์กำหนด |
| เพดานค่าปรับ | หาวันที่ค่าปรับแตะเพดาน แล้วลองวันก่อนหน้า วันนั้น และวันถัดไป | ผลรวมต้องไม่เกินเพดาน และต้องไม่ปัดลงก่อนถึงเพดาน |
| เดินทาง 1–10 วัน | 0, 1, 2 และ 9, 10, 11 | ค่าผิดนอกช่วงต้องถูกปฏิเสธทั้งสองประเภทการเดินทาง |
ความยาวถูกไม่ได้แปลว่ารูปแบบถูก เช่น ตัวอักษรครบ 10 ตัว ก็ยังต้องถูกปฏิเสธถ้ากติกาต้องการเลขล้วน
ตารางเงื่อนไขช่วยแสดงว่าชุดเงื่อนไขต่างกันควรนำไปสู่ผลอะไร เหมาะกับกติกาที่มีหลายช่องหรือหลายทางเลือก [1]
| ชื่อ | อีเมล | เบอร์ | ผลที่ควรได้ |
|---|---|---|---|
| ถูก | ถูก | ถูก | ลงทะเบียนสำเร็จ |
| ผิด | ถูก | ถูก | แจ้งให้กรอกใหม่ |
| ถูก | ผิด | ถูก | แจ้งให้กรอกใหม่ |
| ถูก | ถูก | ผิด | แจ้งให้กรอกใหม่ |
| ผิดตั้งแต่สองช่องขึ้นไป | แจ้งให้กรอกใหม่เช่นกัน แต่ยังระบุไม่ได้ว่าช่องใดมีบั๊ก | ||
ขั้นฝึก: เริ่มผิดทีละช่องเพื่อแยกสาเหตุ แล้วจึงเพิ่มกรณีหลายช่องผิดพร้อมกันเพื่อตรวจการทำงานร่วมกัน สำหรับค่าเดินทาง ให้จับคู่วันในช่วง/นอกช่วงกับในจังหวัด/ต่างจังหวัด
สิ่งที่ใช้ตัดสินว่าคำตอบควรเป็นอะไรเรียกว่า test oracle ในกิจกรรมนี้ให้ยึดข้อกำหนดและการคำนวณตามกติกาเป็นหลัก คำตอบของ AI และผลของระบบจำลองต้องนำมาตรวจอีกครั้ง
| สถานการณ์ | ผลการทดสอบระบบ | ความหมาย |
|---|---|---|
| ข้อมูลถูก และระบบยอมรับ | ระบบตรงข้อกำหนด | พฤติกรรมถูกต้อง |
| ข้อมูลผิด และระบบปฏิเสธ | ระบบตรงข้อกำหนด | การทดสอบด้วยข้อมูลผิดสำเร็จ ไม่ใช่พบบั๊ก |
| ข้อมูลผิด แต่ระบบยอมรับ | ระบบผิดข้อกำหนด | มีหลักฐานความผิดปกติให้รายงาน |
| ผู้เรียนคาดหวังผิด | พิจารณาระบบจากข้อกำหนดแยกต่างหาก | ทบทวนคำตอบก่อนนับเป็นบั๊กที่จับได้ |
รายงานควรมีหัวข้อชัดเจน สภาพแวดล้อม ขั้นตอนและข้อมูลที่ใช้ ผลที่คาดหวัง ผลจริง และผลกระทบ พร้อมอ้างถึง test case เพื่อให้ผู้รับตรวจซ้ำได้ [2]
แม่แบบ: “เมื่อเปิด [ระบบ/เบราว์เซอร์] แล้วกรอก [ข้อมูล] และกด [ปุ่ม] ตามข้อกำหนดควรได้ [ผล] แต่ได้ [ผลจริง] ทำให้ [ผลกระทบ] อ้างอิง TC…”
ตัวอย่างนอกโจทย์: ระบบส่วนลดกำหนดอายุ 60 ปีขึ้นไปได้ส่วนลด ทดสอบอายุ 60 แล้วไม่ได้ส่วนลด ให้บันทึกอายุ ผลที่ควรได้ ผลจริง และขั้นตอน ไม่เขียนเพียงว่า “ส่วนลดมีบั๊ก”
ความรุนแรง (severity) คือระดับผลกระทบ ส่วนลำดับแก้ไข (priority) คือควรจัดการก่อนหลังเพียงใด ทั้งสองอย่างอาจต่างกันได้
หลังแก้บั๊ก ให้ลองกรณีเดิมเพื่อยืนยันว่าปัญหาหาย (confirmation testing) และตรวจกรณีอื่นที่อาจได้รับผลกระทบ (regression testing) [2] เช่น แก้การตรวจเบอร์แล้วต้องยังสมัครด้วยข้อมูลถูกได้ และยังปฏิเสธชื่อว่างได้
จำนวน test case บอกปริมาณการลอง แต่ไม่บอกว่าครบทุกกติกา ลองเบอร์ถูกซ้ำ 20 ครั้งอาจครอบคลุมน้อยกว่าลอง 5 กรณีที่เลือกจากคนละกลุ่ม ตัวเลขบนเว็บเป็นจำนวนรายการแยกประเภท ไม่ใช่เปอร์เซ็นต์ความครอบคลุมตามมาตรฐาน และการจับบั๊กครบตามที่ฝังไว้ไม่ได้พิสูจน์ว่าซอฟต์แวร์ไม่มีบั๊กอื่น
จำนวนครั้งจนพบบั๊กใช้สะท้อนกระบวนการเรียนรู้ ไม่ควรใช้ตัดสินความสามารถเพียงอย่างเดียว การทดลองที่ผ่านและการตรวจข้อมูลผิดอย่างถูกต้องก็มีคุณค่า
คำอธิบายภาษาไทยและตัวอย่างในหน้านี้เรียบเรียงสำหรับ Workshop นี้ ตัวอย่างไม่ได้เป็นข้อสอบรับรองของ ISTQB
| ใส่อะไร | ลองแบบไหน | ต้องได้อะไร | ได้จริง | ผล |
|---|---|---|---|---|
| 30 | ค่าปกติ | ไม่ได้ส่วนลด | – | |
| 70 | ค่าปกติ | ได้ส่วนลด | – | |
| 59 | ตรงเส้นแบ่ง | ไม่ได้ส่วนลด | – | |
| 60 | ตรงเส้นแบ่ง | ได้ส่วนลด | – | |
| 61 | ตรงเส้นแบ่ง | ได้ส่วนลด | – | |
| -5 | ค่าผิด | แจ้งว่ากรอกผิด | – | |
| หกสิบ | ค่าผิด | แจ้งว่ากรอกผิด | – | |
| (ไม่กรอก) | ค่าผิด | แจ้งว่ากรอกผิด | – |
ระบบตัวอย่างนี้ทำงานถูกต้อง ทุกข้อจึงควรผ่าน ส่วนระบบใน workshop ทั้ง 4 ชุดมีบั๊กซ่อนอยู่ชุดละ 3 ตัว
https://gemini.google.com/gems/
Gem คือผู้ช่วยส่วนตัวใน Gemini ที่เราตั้งกติกาไว้ล่วงหน้า จะได้ไม่ต้องพิมพ์อธิบายซ้ำทุกครั้ง
คุณคือ "ผู้ช่วยทดสอบโปรแกรม" เป็นพี่เลี้ยงในห้องอบรมของมหาวิทยาลัย ผู้ใช้ของคุณคือบุคลากรมหาวิทยาลัยที่ไม่เคยเขียนโปรแกรมมาก่อน กำลังหัดทดสอบโปรแกรมเป็นครั้งแรก เขาจะวาง "ความต้องการของระบบ" มาให้ แล้วขอให้คุณช่วยคิด test case หน้าที่ของคุณ เมื่อผู้ใช้ส่งความต้องการของระบบมา ให้ตอบเป็นตารางเดียว มี 3 คอลัมน์นี้เท่านั้น | ใส่อะไร | ต้องได้อะไร | ลองเพื่ออะไร | กติกาในการสร้างตาราง - ให้ครบทั้ง 3 แบบ ได้แก่ ค่าปกติ, ค่าผิด, ค่าตรงเส้นแบ่ง และเขียนคำเหล่านี้ในคอลัมน์ "ลองเพื่ออะไร" - ค่าตรงเส้นแบ่งสำคัญที่สุด ทุกครั้งที่ความต้องการมีจุดเปลี่ยน เช่น 60 ปีขึ้นไป หรือ ไม่เกิน 100 บาท ให้ใส่ค่าก่อนจุดเปลี่ยน ค่าที่จุดเปลี่ยนพอดี และค่าหลังจุดเปลี่ยน ครบทั้งสามค่า - ค่าผิดต้องมีอย่างน้อย 3 แบบ ได้แก่ ไม่กรอก, กรอกเป็นตัวอักษร, และกรอกค่าที่อยู่นอกช่วงที่กำหนด - ตารางยาวไม่เกิน 15 แถว - คอลัมน์ "ต้องได้อะไร" ต้องอ้างอิงจากความต้องการที่ผู้ใช้ให้มาเท่านั้น ห้ามเดาเอง ถ้าความต้องการไม่ได้บอกไว้ ให้เขียนว่า "ความต้องการไม่ได้ระบุ ควรถามผู้พัฒนา" หลังตารางทุกครั้ง ให้ปิดท้ายด้วยข้อความนี้เสมอ "ผมอาจคำนวณผิดได้ ก่อนนำไปใช้ กรุณาตรวจคอลัมน์ต้องได้อะไร เทียบกับความต้องการทีละข้อ" ถ้าผู้ใช้ถามคำถามอื่น - อธิบายเรื่องการทดสอบโปรแกรมได้ตามปกติ แต่ต้องสั้น ไม่เกิน 5 บรรทัด - ถ้าถูกถามว่าในระบบมีบั๊กอะไร หรือขอเฉลย ให้ตอบว่าคุณไม่เห็นตัวระบบ เห็นแค่ความต้องการ แล้วชวนให้เขาลองกดใช้ระบบเองด้วย test case ในตาราง - ถ้าผู้ใช้ขอโค้ดหรือขอสคริปต์ทดสอบอัตโนมัติ ให้ปฏิเสธอย่างสุภาพ แล้วบอกว่า workshop นี้ทดสอบด้วยการกดใช้งานจริง ไม่ต้องเขียนโค้ด ภาษาและน้ำเสียง - ตอบเป็นภาษาไทยเสมอ ใช้คำง่าย ๆ แบบคุยกับเพื่อนร่วมงาน - ห้ามใช้ศัพท์เทคนิคเหล่านี้: input, output, boundary value, equivalence partitioning, validation, edge case, assertion ให้ใช้คำว่า ใส่อะไร, ได้อะไร, ค่าตรงเส้นแบ่ง, ค่าผิด แทน - ห้ามใส่โค้ด ห้ามใส่ตัวอย่างภาษาโปรแกรม - ให้กำลังใจสั้น ๆ ได้ แต่ไม่ต้องยาว
เข้า Gemini Gem: https://gemini.google.com/gems/
ช่วยสร้าง test case ให้ระบบนี้ - รับคะแนน 0 ถึง 100 เป็นจำนวนเต็ม - 80–100 = A, 75–79 = B+, 70–74 = B, 65–69 = C+, 60–64 = C, 55–59 = D+, 50–54 = D, 0–49 = F - ถ้าไม่กรอก ไม่ใช่ตัวเลข หรือนอกช่วง 0–100 ต้องแสดง "ข้อมูลไม่ถูกต้อง"
เข้า Gemini Gem: https://gemini.google.com/gems/
วางใน Gem แล้วเทียบคำตอบกับความต้องการก่อนนำมาลอง
| รหัส | คะแนน | ต้องได้ | ได้จริง | คำตอบที่คาดหวัง | ผลระบบตามข้อกำหนด | ลบ |
|---|---|---|---|---|---|---|
| ยังไม่มี test case เริ่มจากค่าปกติก่อน | ||||||
นับว่าจับบั๊กได้เมื่อระบบ “ผิดข้อกำหนด” และผู้เรียนคาดหวังคำตอบถูกต้อง · การปฏิเสธข้อมูลผิดได้ถูกต้องคือ “ตรงข้อกำหนด”
ช่วยสร้าง test case ให้ระบบนี้ - ชื่อ-นามสกุล ต้องกรอก - อีเมล ต้องมีรูปแบบถูกต้อง เช่น name@sut.ac.th - เบอร์มือถือ ใช้เลข 0–9 จำนวน 10 หลัก ขึ้นต้นด้วย 06, 08 หรือ 09 ไม่ใส่ขีด เว้นวรรคภายใน หรือ +66 (ละช่องว่างหัวท้ายได้) - กรอกถูกครบทุกช่อง ต้องแสดง "ลงทะเบียนสำเร็จ" ถ้าผิดช่องใดช่องหนึ่ง ต้อง "แจ้งให้กรอกใหม่" ขอให้ทำผิดทีละช่อง ห้ามผิดสองช่องพร้อมกันในข้อเดียว
เข้า Gemini Gem: https://gemini.google.com/gems/
สังเกตว่าถ้าไม่สั่งกำกับ AI มักให้ข้อที่ผิดหลายช่องพร้อมกัน ซึ่งใช้หาบั๊กไม่ได้
เบอร์สั้นหรือยาวเกินไปควรถูกปฏิเสธ ถ้าระบบปฏิเสธถูกต้องจะแสดงว่า “ตรงข้อกำหนด” ไม่ได้แปลว่าเบอร์นั้นถูกต้อง ส่วนการจับบั๊กต้องพบว่าระบบรับข้อมูลที่ควรปฏิเสธ และเลือกผลที่คาดหวังได้ถูกต้องด้วย
ใช้ข้อมูลสมมติในการฝึก ไม่ต้องกรอกเบอร์จริง แบบฝึกหัดตรวจรูปแบบเท่านั้น ไม่ยืนยันว่าเบอร์มีผู้ใช้งานจริง
| รหัส | ชื่อ | อีเมล | เบอร์ | ต้องได้ | ได้จริง | คำตอบที่คาดหวัง | ผลระบบตามข้อกำหนด | ลบ |
|---|---|---|---|---|---|---|---|---|
| ยังไม่มี test case เริ่มจากค่าปกติก่อน | ||||||||
นับว่าจับบั๊กได้เมื่อระบบ “ผิดข้อกำหนด” และผู้เรียนคาดหวังคำตอบถูกต้อง · การปฏิเสธข้อมูลผิดได้ถูกต้องคือ “ตรงข้อกำหนด”
ช่วยสร้าง test case ให้ระบบนี้ - คืนหนังสือช้า ปรับวันละ 5 บาท แต่รวมไม่เกิน 100 บาท - คืนตรงเวลา (ช้า 0 วัน) ไม่เสียค่าปรับ - จำนวนวันต้องเป็นจำนวนเต็ม 0 ขึ้นไป ถ้าไม่ใช่ ต้องแสดง "ข้อมูลไม่ถูกต้อง"
เข้า Gemini Gem: https://gemini.google.com/gems/
วางใน Gem แล้วเก็บตารางที่ได้ไว้ จะใช้ในขั้นที่ 3
นี่คือตัวอย่างคำตอบที่ AI เคยตอบ ข้อไหน “ต้องได้” ตรงกับความต้องการ ข้อไหนผิด
| รหัส | วันที่ช้า | ต้องได้ | ได้จริง | คำตอบที่คาดหวัง | ผลระบบตามข้อกำหนด | ลบ |
|---|---|---|---|---|---|---|
| ยังไม่มี test case เริ่มจากค่าปกติก่อน | ||||||
นับว่าจับบั๊กได้เมื่อระบบ “ผิดข้อกำหนด” และผู้เรียนคาดหวังคำตอบถูกต้อง · การปฏิเสธข้อมูลผิดได้ถูกต้องคือ “ตรงข้อกำหนด”
ช่วยสร้าง test case ให้ระบบเบิกค่าเดินทางนี้ - เบี้ยเลี้ยงวันละ 240 บาท คิดตามจำนวนวันที่ไปราชการ - ถ้าไปต่างจังหวัด บวกค่าที่พักคืนละ 800 บาท โดยจำนวนคืน = จำนวนวัน ลบ 1 - ถ้าไปในจังหวัด ไม่มีค่าที่พัก - จำนวนวันต้องเป็นจำนวนเต็มตั้งแต่ 1 ถึง 10 ถ้าไม่ใช่ ต้องแสดง "ข้อมูลไม่ถูกต้อง" ระบบมี 2 ช่อง คือ จำนวนวัน และ ประเภท (ในจังหวัด หรือ ต่างจังหวัด) ในคอลัมน์ "ใส่อะไร" ให้เขียนทั้งสองช่อง ในคอลัมน์ "ต้องได้อะไร" ให้แสดงวิธีคิดสั้น ๆ ด้วย เช่น 3x240 + 2x800 = 2320 บาท
เข้า Gemini Gem: https://gemini.google.com/gems/
ที่ให้ AI แสดงวิธีคิด เพราะเราจะได้ตรวจได้ว่ามันคิดผิดตรงไหน ไม่ใช่แค่เห็นตัวเลขสุดท้าย
| รหัส | จำนวนวัน | ประเภท | ต้องได้ | ได้จริง | คำตอบที่คาดหวัง | ผลระบบตามข้อกำหนด | ลบ |
|---|---|---|---|---|---|---|---|
| ยังไม่มี test case เริ่มจากค่าปกติก่อน | |||||||
นับว่าจับบั๊กได้เมื่อระบบ “ผิดข้อกำหนด” และผู้เรียนคาดหวังคำตอบถูกต้อง · การปฏิเสธข้อมูลผิดได้ถูกต้องคือ “ตรงข้อกำหนด”