วิธีสร้างกรณีทดสอบที่มีประสิทธิภาพ (พร้อมตัวอย่าง)

กรณีทดสอบส่วนใหญ่ล้มเหลวก่อนที่จะตรวจพบข้อผิดพลาดแม้แต่ข้อเดียว เนื่องจากถูกเขียนเป็นรายการตรวจสอบที่ไม่ชัดเจน ขาดเงื่อนไขเบื้องต้น การรวมหลายขั้นตอนการดำเนินการไว้ในขั้นตอนเดียว หรือการอธิบายผลลัพธ์ที่คาดหวังอย่างคลุมเครือจนทำให้ผู้ทดสอบสองคนที่อ่านกรณีเดียวกันอาจไม่เห็นพ้องกันว่า “ผ่าน” หมายถึงอะไร ผลที่ตามมาคือ ข้อผิดพลาดหลุดรอดไปได้ การทดสอบไม่สามารถทำซ้ำได้ และ QA กลายเป็นจุดคอขวดแทนที่จะเป็นเครือข่ายความปลอดภัย

การเขียนกรณีทดสอบที่ดีนั้นไม่ใช่เรื่องทักษะการทดสอบเป็นหลัก แต่เป็นเรื่องการออกแบบการตรวจสอบมากกว่า บริการทางการเงินเรียกกระบวนการนี้ว่า “maker-checker process” ส่วนศูนย์บัญชาการนิวเคลียร์เรียกมันว่า “กฎสองคน” หลักการนั้นเหมือนกัน: งานสำคัญไม่ควรพึ่งพาการกระทำเพียงครั้งเดียวที่ไม่ได้รับการตรวจสอบ กรณีทดสอบที่เขียนอย่างดีจะนำความเคร่งครัดแบบเดียวกันนี้มาใช้ในซอฟต์แวร์ มันแยกสิ่งที่คุณคาดหวังออกจากสิ่งที่คุณสังเกตเห็น ทำให้ช่องว่างระหว่างทั้งสองอย่างนั้นไม่สามารถถูกเพิกเฉยได้

เราจะแสดงให้คุณเห็นวิธีเขียนกรณีทดสอบ ความสำคัญของมัน และวิธีปรับปรุงคุณภาพกรณีทดสอบให้ดีขึ้นตามเวลา

กรณีทดสอบคืออะไร?

กรณีทดสอบคือเอกสารที่มีโครงสร้างชัดเจน ซึ่งกำหนดขั้นตอนที่แม่นยำ ข้อมูลนำเข้า เงื่อนไขเบื้องต้น และผลลัพธ์ที่คาดหวัง เพื่อตรวจสอบว่าซอฟต์แวร์เฉพาะชิ้นนั้นทำงานอย่างถูกต้องหรือไม่ กรณีทดสอบไม่ใช่แผนการทดสอบ (ซึ่งกำหนดกลยุทธ์การทดสอบ) หรือสคริปต์การทดสอบ (รหัสอัตโนมัติที่ดำเนินการตามขั้นตอนผ่านโปรแกรม) แต่กรณีทดสอบคือข้อกำหนดพื้นฐานที่ทั้งสองอย่างนั้นถูกสร้างขึ้นจาก

ตัวอย่าง: คุณกำลังทดสอบฟังก์ชันการเข้าสู่ระบบของแอปพลิเคชันเว็บ กรณีทดสอบสำหรับคุณสมบัตินี้จะกำหนดองค์ประกอบดังต่อไปนี้:

การเปรียบเทียบกรณีทดสอบแบบมือกับแบบอัตโนมัติ

AI ปัจจุบันเป็นส่วนหนึ่งของกระบวนการทดสอบส่วนใหญ่แล้ว ตามรายงานState of Testing Report 2026 ของ PractiTest พบว่า 76.8% ของผู้เชี่ยวชาญด้านการทดสอบใช้ AI ในงาน QA โดยการใช้งานที่พบบ่อยที่สุดคือ การสร้างกรณีทดสอบ (69.6%) และการดูแลรักษาสคริปต์ (59.6%) กรณีทดสอบอัตโนมัติเป็นจุดที่การเปลี่ยนแปลงนี้ปรากฏชัดเจนที่สุด ดังนั้นจึงควรเข้าใจว่ากรณีทดสอบอัตโนมัติแตกต่างจากกรณีทดสอบแบบมืออย่างไร

ทำไมกรณีทดสอบที่เขียนอย่างดีจึงสำคัญ

คุณจะตรวจพบข้อผิดพลาดที่กลับมา (regression) ก่อนที่ผู้ใช้จะส่งตั๋ว การเปลี่ยนแปลงโค้ดทุกครั้งล้วนมีความเสี่ยงที่จะทำให้ส่วนที่ทำงานได้ปกติเกิดข้อผิดพลาด กรณีทดสอบที่เขียนอย่างดีจะกลายเป็นจุดตรวจสอบที่ทำงานอัตโนมัติหลังการปรับใช้ทุกครั้ง เมื่อผู้พัฒนาปรับโครงสร้างโค้ดการเข้าสู่ระบบของคุณหลังจากผ่านไปหนึ่งปี และทำให้การจัดการเซสชันเกิดข้อผิดพลาดโดยไม่ได้ตั้งใจ กรณีทดสอบนั้นจะแจ้งเตือนปัญหาดังกล่าวในสภาพแวดล้อม staging

คุณต้องทำให้ผลการผ่าน/ไม่ผ่านเป็นข้อเท็จจริง ไม่ใช่ความเห็นส่วนตัว ผลลัพธ์ที่คาดการณ์ไว้อย่างคลุมเครือ เช่น “ระบบตอบสนองอย่างเหมาะสม” จะบังคับให้ผู้ทดสอบทุกคนต้องตีความว่า “เหมาะสม” หมายถึงอะไร ผู้ทดสอบสองคนรันกรณีทดสอบเดียวกัน คนหนึ่งระบุว่าผ่าน อีกคนรายงานข้อบกพร่อง และตอนนี้ทีมต้องแก้ไขความไม่เห็นพ้องกันแทนที่จะแก้ไขซอฟต์แวร์ เมื่อผลลัพธ์ที่คาดหวังระบุว่า “ระบบแสดงข้อความผิดพลาด: ‘รหัสผ่านไม่ถูกต้อง’ และให้ผู้ใช้อยู่บนหน้าเข้าสู่ระบบ” ก็ไม่มีที่ว่างสำหรับการตีความ ผลลัพธ์นั้นตรงกันหรือไม่ตรงกันเท่านั้น นี่คือหลักการสองคนในทางปฏิบัติ: กรณีทดสอบคือผู้กำหนด ผู้ทดสอบคือผู้ตรวจสอบ และทั้งสองฝ่ายต้องใช้ภาษาเดียวกัน

คุณเปลี่ยนความรู้ที่ไม่ได้บันทึกไว้เป็นสินทรัพย์ที่สามารถนำกลับมาใช้ใหม่ได้ ในทีมส่วนใหญ่ วิศวกร QA ระดับอาวุโสจะถือแผนที่ที่มองไม่เห็นของทุกกรณีขอบเขต ทุกวิธีแก้ไขชั่วคราว และทุกคำแนะนำแบบ “อ้อ อย่าลืมตรวจสอบ X ด้วยนะ” เมื่อบุคคลนั้นลาพักหรือเปลี่ยนทีม แผนที่นั้นก็จะไปกับเขาด้วย กรณีทดสอบที่บันทึกไว้พร้อมเงื่อนไขเบื้องต้นและค่าขอบเขตที่ชัดเจนจะรักษาความรู้ดังกล่าวไว้อย่างเป็นระบบ ผู้ทดสอบใหม่ที่เข้าร่วมทีมสามารถหยิบกรณีทดสอบ TC_LOGIN_005 มาทดสอบกระบวนการล็อกบัญชีหลังการลองเข้า 5 ครั้งได้ตั้งแต่วันแรก โดยไม่ต้องถามใครว่าค่าขีดจำกัดคือเท่าไร หรือตัวจับเวลาถูกรีเซ็ตอย่างไร

คุณสามารถระบุจุดผิดพลาดได้ถึงขั้นตอนที่แม่นยำ ไม่ใช่เพียงพื้นที่ทั่วไป เมื่อกรณีทดสอบรวม “ไปที่หน้าเว็บ, ป้อนข้อมูลการเข้าสู่ระบบ, และคลิกส่ง” เป็นขั้นตอนเดียว และทดสอบล้มเหลว คุณจะรู้เพียงว่า “มีบางอย่างในกระบวนการเข้าสู่ระบบที่ผิดพลาด” ” แต่เมื่อแต่ละการกระทำเป็นขั้นตอนแยกต่างหากที่มีผลลัพธ์ที่คาดหวังเป็นของตัวเอง ความล้มเหลวจะถูกระบุอย่างชัดเจนที่ขั้นตอนที่ 4: “คลิก ‘ส่งลิงก์รีเซ็ต’ → คาดว่าจะได้รับข้อความสำเร็จ แต่กลับได้รับข้อผิดพลาด 500.” ความแม่นยำนี้ช่วยลดเวลาในการแก้ไขข้อผิดพลาดลงอย่างมาก เพราะผู้พัฒนาทราบอย่างแน่ชัดว่าการโต้ตอบใดที่ก่อให้เกิดข้อผิดพลาด ไม่ใช่เพียงแค่รู้ว่าต้องค้นหาในส่วนฟีเจอร์ใดเท่านั้น

คุณจะเห็นได้ว่าส่วนใดได้รับการครอบคลุมและส่วนใดเป็นจุดบอด หากไม่มีกรณีทดสอบที่มีโครงสร้าง การครอบคลุมการทดสอบจะเป็นเพียงการคาดเดา แต่เมื่อมีกรณีทดสอบที่มีโครงสร้าง คุณสามารถเชื่อมโยงทุกกรณีกลับไปยังข้อกำหนดและระบุช่องว่างได้ทันที หากฟีเจอร์การรีเซ็ตรหัสผ่านของคุณมีหกสถานการณ์ (รีเซ็ตสำเร็จ, ลิงก์หมดอายุ, ลิงก์ถูกใช้ซ้ำ, อีเมลที่ยังไม่ลงทะเบียน, รูปแบบไม่ถูกต้อง, คำขอหลายครั้ง) แต่คุณมีกรณีทดสอบเพียงสามกรณี ช่องว่างนั้นจะชัดเจนและสามารถวัดได้ ความชัดเจนนี้คือสิ่งที่เปลี่ยนการทดสอบจาก “เราทดสอบแล้ว” เป็น “นี่คือสิ่งที่เราทดสอบอย่างแม่นยำ นี่คือสิ่งที่เรายังไม่ได้ทดสอบ และนี่คือความเสี่ยงที่เรายอมรับ”

องค์ประกอบของกรณีทดสอบที่ดี

กรณีทดสอบที่มีประโยชน์ไม่เพียงแต่บรรยายสิ่งที่ต้องทดสอบเท่านั้น แต่ยังบันทึกบริบท ขั้นตอนการดำเนินการ และพฤติกรรมของระบบที่คาดการณ์ไว้ เพื่อให้ผู้ทดสอบ ผู้พัฒนา หรือผู้จัดการผลิตภัณฑ์คนอื่นสามารถทำซ้ำการทดสอบและตรวจสอบผลลัพธ์ได้

ส่วนประกอบของกรณีทดสอบ ได้แก่:

สำหรับตัวอย่างฟังก์ชันการเข้าสู่ระบบเว็บไซต์ที่เราได้แบ่งปันไว้ข้างต้น กรณีทดสอบของคุณควรรวมถึง:

ID กรณีทดสอบ: ทุกกรณีทดสอบจำเป็นต้องมีตัวระบุที่ไม่ซ้ำกัน เมื่อทดสอบฟีเจอร์ ทีม QA มักสร้างกรณีทดสอบหลายกรณีเพื่อตรวจสอบเงื่อนไขที่คล้ายกัน ID กรณีทดสอบช่วยให้ติดตาม จัดระเบียบ และอ้างอิงกรณีทดสอบเหล่านั้นได้อย่างง่ายดายระหว่างการแก้ไขข้อผิดพลาดหรือการรายงาน

ตัวอย่าง: TC_LOGIN_001

คำอธิบาย: ส่วนนี้อธิบายว่ากรณีทดสอบกำลังตรวจสอบฟังก์ชันการทำงานใด โดยให้สรุปสั้นๆ เพื่อให้ผู้อ่านสามารถเข้าใจวัตถุประสงค์ของกรณีทดสอบได้ทันที

ตัวอย่าง: ตรวจสอบว่าผู้ใช้ที่ลงทะเบียนแล้วสามารถเข้าสู่ระบบแอปพลิเคชันได้สำเร็จโดยใช้ข้อมูลการเข้าสู่ระบบที่ถูกต้อง

เงื่อนไขเบื้องต้น: เงื่อนไขเบื้องต้นอธิบายสถานะของระบบที่จำเป็นก่อนการดำเนินการกรณีทดสอบ หากไม่มีเงื่อนไขเบื้องต้นนี้ ผู้ทดสอบอาจดำเนินการทดสอบเดียวกันภายใต้เงื่อนไขที่แตกต่างกัน และได้รับผลลัพธ์ที่ไม่สอดคล้องกัน

ตัวอย่าง:

ขั้นตอน: นี่คือขั้นตอนที่ผู้ใช้หรือผู้ทดสอบต้องดำเนินการเพื่อดำเนินการกรณีทดสอบ แต่ละขั้นตอนควรชัดเจนและเป็นลำดับ เพื่อให้สมาชิกในทีมทุกคนสามารถทำซ้ำการทดสอบได้

ผลลัพธ์ที่คาดหวัง: ส่วนนี้กำหนดว่าระบบควรทำงานอย่างไรหากฟีเจอร์ทำงานอย่างถูกต้อง

หากข้อมูลการเข้าสู่ระบบไม่ถูกต้อง ระบบควรแสดงข้อความผิดพลาดที่เหมาะสม

ผลลัพธ์จริง: นี่คือข้อมูลที่บันทึกการสังเกตของผู้ทดสอบหลังจากรันกรณีทดสอบ หากพฤติกรรมที่สังเกตได้แตกต่างจากผลลัพธ์ที่คาดไว้ ปัญหาดังกล่าวจะถูกบันทึกเป็นข้อบกพร่อง

ตัวอย่างการสังเกต:

ตอนนี้มาลองนำทักษะการเขียนกรณีทดสอบของคุณมาใช้กันเถอะ

วิธีเขียนกรณีทดสอบ (ขั้นตอนโดยละเอียด)

การเขียนกรณีทดสอบประกอบด้วย 7 ขั้นตอน: วิเคราะห์ข้อกำหนด, ระบุสถานการณ์, วางแผนโครงสร้าง, เขียนขั้นตอนพร้อมผลลัพธ์ที่คาดหวัง, แนบบริบท, ส่งให้ตรวจสอบ, แล้วดำเนินการและบันทึกผลลัพธ์

ขั้นตอนที่ 1: วิเคราะห์ข้อกำหนด

ก่อนที่จะเขียนกรณีทดสอบ ให้เข้าใจว่าฟีเจอร์ดังกล่าวมีหน้าที่ทำงานอย่างไร นี่คือขั้นตอนที่คุณต้องทบทวนเอกสารที่มีอยู่ — PRD (เอกสารข้อกำหนดผลิตภัณฑ์), เรื่องราวผู้ใช้, ข้อกำหนดฟีเจอร์ และเอกสารออกแบบ — และระบุทุกฟังก์ชันที่จำเป็นต้องตรวจสอบ

ตัวอย่าง: คุณกำลังพัฒนาฟีเจอร์ที่ให้ผู้ใช้สามารถรีเซ็ตรหัสผ่านผ่านอีเมลได้ เพื่อสร้างกรณีทดสอบสำหรับฟีเจอร์นี้ คุณจำเป็นต้องเข้าใจ:

ความชัดเจนนี้จะเป็นพื้นฐานให้คุณกำหนดวัตถุประสงค์ที่ชัดเจนสำหรับกรณีทดสอบของคุณ

วัตถุประสงค์: ตรวจสอบว่าผู้ใช้ที่ลงทะเบียนแล้วสามารถรีเซ็ตรหัสผ่านผ่านอีเมลได้สำเร็จ

ขั้นตอนที่ 2: ระบุสถานการณ์การทดสอบต่าง ๆ

ถัดไป ให้ระบุสถานการณ์การทดสอบที่คุณต้องการตรวจสอบ สถานการณ์การทดสอบคือสถานการณ์ระดับสูง — ซึ่งโดยทั่วไปจะแตกออกเป็นหลายกรณีการทดสอบที่ครอบคลุมข้อมูลนำเข้าและผลลัพธ์ที่แตกต่างกัน

สำหรับฟีเจอร์การรีเซ็ตรหัสผ่าน กรณีทดสอบของคุณอาจมีลักษณะดังนี้:

แต่ละสถานการณ์ที่นี่จะถูกแปลงเป็นกรณีทดสอบหนึ่งหรือมากกว่าหนึ่งกรณี ซึ่งครอบคลุมข้อมูลนำเข้าและเงื่อนไขเฉพาะ การแบ่งคุณสมบัติออกเป็นส่วนๆ ด้วยวิธีนี้ จะช่วยให้คุณมั่นใจได้ว่าการทดสอบครอบคลุมทั้งพฤติกรรมที่คาดไว้และกรณีขอบเขตที่ผู้ใช้จริงจะพบเจออย่างหลีกเลี่ยงไม่ได้

ขั้นตอนที่ 3: วางแผนการทดสอบและกำหนดโครงสร้างกรณีทดสอบ

สำหรับการทดสอบการถดถอย (regression testing) ที่ทำซ้ำๆ คุณจำเป็นต้องมีโครงสร้างที่ช่วยให้คุณสามารถบันทึกกรณีทดสอบและผลลัพธ์ได้อย่างสม่ำเสมอ แม่แบบกรณีทดสอบที่กำหนดไว้อย่างชัดเจนจะสร้างความสม่ำเสมอนี้ และช่วยให้สามารถนำกลับมาใช้ใหม่ได้ โดยไม่ต้องเริ่มต้นจากศูนย์ทุกครั้ง

วางแผนการดำเนินการทดสอบโดยกำหนดให้ชัดเจนในองค์ประกอบต่อไปนี้:

ใครจะเป็นผู้ดำเนินการทดสอบ?

ผู้ดำเนินการทดสอบนี้จำเป็นต้องมีบทบาทหรือคุณสมบัติใด? ขึ้นอยู่กับความซับซ้อนของการทดสอบและระดับการมีส่วนร่วมของมนุษย์ที่จำเป็น ให้กำหนดบทบาทดังต่อไปนี้:

การทดสอบจะดำเนินการอย่างไร?

เงื่อนไขเบื้องต้นคืออะไร?

ระบุทุกเงื่อนไขที่ต้องเป็นจริงก่อนขั้นตอนที่ 1 และทำให้ผู้ทดสอบสามารถตรวจสอบแต่ละเงื่อนไขได้:

ตัวอย่าง:

ข้อมูลทดสอบใดจะถูกใช้?

กำหนดค่าข้อมูลนำเข้าที่จำเป็นอย่างแม่นยำเพื่อดำเนินการทดสอบ — ข้อมูลที่ถูกต้อง ข้อมูลที่ไม่ถูกต้อง และค่าขอบเขต

ตัวอย่าง:

ขั้นตอนที่ 4: เขียนขั้นตอนการทดสอบและผลลัพธ์ที่คาดการณ์

แบ่งกระบวนการดำเนินการออกเป็นขั้นตอนที่เรียงตามลำดับ ใช้คำศัพท์ที่สอดคล้องกัน และมั่นใจว่าแต่ละขั้นตอนมีเพียงการดำเนินการหนึ่งเท่านั้น เมื่อกำหนดขั้นตอน ให้ระบุผลลัพธ์ที่คาดหวังและเกณฑ์ที่ถือว่าผ่านการทดสอบหรือล้มเหลวด้วย

ต่อจากขั้นตอนการรีเซ็ตรหัสผ่านของเรา ขั้นตอนการทดสอบจะมีลักษณะดังนี้:

ตอนนี้กำหนดขั้นตอนและผลลัพธ์ที่คาดไว้สำหรับสถานการณ์ทางเลือก (ที่ได้กล่าวถึงก่อนหน้านี้) เช่น อธิบายว่าเกิดอะไรขึ้นเมื่อผู้ใช้ป้อนที่อยู่อีเมลที่ไม่ถูกต้อง หรือรหัสผ่านไม่ตรงกับเกณฑ์ที่กำหนดไว้ล่วงหน้า

ขั้นตอนที่ 5: แนบไฟล์ที่เกี่ยวข้อง

แนบเอกสารหรือไฟล์แนบที่เกี่ยวข้องเพื่อช่วยให้ผู้ทดสอบสามารถดำเนินการตามกรณีทดสอบได้โดยมีบริบทครบถ้วนและไม่มีความคลุมเครือ ซึ่งอาจรวมถึง:

ขั้นตอนที่ 6: ส่งกรณีทดสอบไปให้ตรวจสอบ

แบ่งปันกรณีทดสอบที่เขียนไว้กับเพื่อนร่วมงานหรือหัวหน้าทีม QA ที่มีประสบการณ์ก่อนดำเนินการทดสอบ ระหว่างการตรวจสอบ ให้ตรวจสอบว่า:

ขั้นตอนที่ 7: ดำเนินการทดสอบและบันทึกผลลัพธ์

ดำเนินการทดสอบและบันทึกผลลัพธ์จริงเทียบกับผลลัพธ์ที่คาดไว้ สำหรับทุกขั้นตอน ให้ระบุว่าผ่านการทดสอบหรือไม่ผ่าน สำหรับทุกขั้นตอนที่ล้มเหลว ให้สร้างรายงานข้อผิดพลาดทันทีและเชื่อมโยงกลับไปยังกรณีทดสอบ นอกจากนี้ หากเกิดพฤติกรรมที่ไม่คาดคิดซึ่งไม่สามารถระบุได้ชัดเจนว่าผ่านหรือไม่ผ่าน ให้บันทึกไว้ในช่องความคิดเห็นเพื่อตรวจสอบเพิ่มเติม

ตัวอย่างการเขียนกรณีทดสอบ

ตัวอย่างทั้งสามนี้แสดงให้เห็นว่าโครงสร้างกรณีทดสอบเดียวกันสามารถปรับใช้กับประเภทการทดสอบซอฟต์แวร์ที่แตกต่างกันได้อย่างไร แต่ละตัวอย่างใช้ส่วนประกอบและรูปแบบขั้นตอนจากส่วนก่อนหน้าในคู่มือนี้ แต่ความซับซ้อน ข้อมูลทดสอบ และรูปแบบความล้มเหลวจะเปลี่ยนแปลงไปตามสิ่งที่คุณกำลังตรวจสอบ

ตัวอย่าง 1: กระบวนการชำระเงินในระบบอีคอมเมิร์ซ (UI, กระบวนการทำงานหลายขั้นตอน)

ทีม QA ของผู้ค้าปลีกออนไลน์กำลังทดสอบประสบการณ์การชำระเงินก่อนการขายในช่วงวันหยุดเทศกาล กระบวนการนี้ครอบคลุมหลายหน้า: ตะกร้าสินค้า → การจัดส่ง → การชำระเงิน → การยืนยัน ความท้าทายหลักที่นี่คือความขึ้นอยู่กับสถานะ: แต่ละขั้นตอนต้องขึ้นอยู่กับการเสร็จสิ้นอย่างถูกต้องของขั้นตอนก่อนหน้า และข้อมูลการทดสอบ (เนื้อหาในตะกร้าสินค้า ที่อยู่จัดส่ง วิธีการชำระเงิน) ต้องคงอยู่ตลอดทุกขั้นตอน

ผู้ทดสอบ: Rahul D.

วันที่ทดสอบ: 09/03/2026

ID กรณีทดสอบ: TC_CHECKOUT_003

คำอธิบาย: ตรวจสอบว่าผู้ใช้ที่เข้าสู่ระบบแล้วสามารถทำการซื้อสินค้าได้โดยใช้บัตรเครดิตที่บันทึกไว้และบริการส่งสินค้าแบบมาตรฐาน

เงื่อนไขเบื้องต้น:

สรุปผล: กระบวนการชำระเงินจัดการการส่งสินค้าจากตะกร้าได้อย่างถูกต้อง แต่การประมวลผลการชำระเงินล้มเหลวเมื่อใช้บัตรเครดิตที่บันทึกไว้ ข้อบกพร่องที่บันทึกไว้: การค้นหาบัตรเครดิตที่เข้ารหัสด้วยโทเค็นจะหมดเวลาเมื่อเกตเวย์การชำระเงินใช้เวลามากกว่า 3 วินาทีในการตอบกลับ

ตัวอย่าง 2: จุดปลายทาง REST API (ไม่มี UI, การตรวจสอบความถูกต้องของข้อมูลเข้า/ออก)

วิศวกรแบ็กเอนด์กำลังทดสอบจุดปลาย API “Create User” ก่อนที่ทีมฟรอนต์เอนด์จะใช้งานมัน ไม่มีอินเทอร์เฟซให้คลิกผ่าน: กรณีทดสอบนี้ตรวจสอบความถูกต้องของข้อมูลในคำขอ (request payloads), รหัสตอบกลับ (response codes) และการเก็บรักษาข้อมูล (data persistence) โดยตรง ความท้าทายที่โดดเด่นคือการทดสอบสัญญา (contract) ระหว่างระบบ ไม่ใช่ประสบการณ์ของผู้ใช้

ผู้ทดสอบ: Sarah S.

วันที่ทดสอบ: 09/05/2026

ID กรณีทดสอบ: TC_API_USER_001

คำอธิบาย: ตรวจสอบว่าคำขอ POST ไปยัง /api/v1/users สร้างผู้ใช้ใหม่และส่งคืนคำตอบที่ถูกต้อง

เงื่อนไขเบื้องต้น:

สรุปผล: Endpoint สร้างผู้ใช้ได้อย่างถูกต้องและตรวจสอบความถูกต้องของสนามข้อมูลที่จำเป็น แต่ไม่สามารถบังคับใช้ความไม่ซ้ำกันของที่อยู่อีเมลในระดับฐานข้อมูลได้ จึงมีการสร้างบันทึกข้อมูลที่ซ้ำกันโดยไม่เกิดข้อผิดพลาด ข้อบกพร่องถูกบันทึกไว้ด้วยระดับความรุนแรง: สูง

ตัวอย่าง 3: การควบคุมการเข้าถึงตามบทบาท (ความปลอดภัย, ขอบเขตสิทธิ์)

ทีมความปลอดภัยกำลังทดสอบว่าแอปพลิเคชันจำกัดการดำเนินการตามบทบาทของผู้ใช้อย่างถูกต้องหรือไม่ ก่อนการตรวจสอบความสอดคล้องกับข้อกำหนด ความท้าทายที่โดดเด่นคือ คุณไม่ได้ทดสอบว่าฟีเจอร์ทำงานได้หรือไม่ แต่กำลังทดสอบว่าฟีเจอร์นั้นถูกปฏิเสธอย่างถูกต้องหรือไม่ ผลลัพธ์ที่คาดหวังสำหรับขั้นตอนส่วนใหญ่คือการถูกบล็อก ไม่ใช่ความสำเร็จ

ผู้ทดสอบ: Marcus L.

วันที่ทดสอบ: 09/08/2026

ID กรณีทดสอบ: TC_RBAC_002

คำอธิบาย: ตรวจสอบว่าผู้ใช้ที่มีบทบาท “Viewer” ไม่สามารถสร้าง แก้ไข หรือลบโครงการได้

เงื่อนไขเบื้องต้น:

สรุปผล: สิทธิ์ในการสร้างและลบถูกจำกัดอย่างถูกต้องสำหรับผู้ใช้ระดับ Viewer แต่สิทธิ์ในการแก้ไขไม่ถูกบังคับใช้ในระดับฟิลด์ ผู้ใช้ระดับ Viewer สามารถแก้ไขชื่อโครงการได้แม้จะมีสิทธิ์เข้าถึงแบบอ่านอย่างเดียว ข้อบกพร่องถูกรายงานด้วยระดับความรุนแรง: Critical (เป็นอุปสรรคต่อการปฏิบัติตามข้อกำหนด)

เครื่องมือใดที่ดีที่สุดสำหรับการจัดการกรณีทดสอบ?

กรณีทดสอบสามารถจัดการได้ผ่านเครื่องมือ QA เฉพาะทาง (TestRail, Zephyr) เครื่องมือ PM ทั่วไป (ClickUp, Jira) หรือสเปรดชีต; การเลือกเครื่องมือที่เหมาะสมขึ้นอยู่กับว่าคุณต้องการฟังก์ชันการรันทดสอบในตัวหรือเพียงการติดตามเท่านั้น

ClickUp

ClickUp for Software Teamsเป็นแพลตฟอร์มการจัดการโครงการที่กรณีทดสอบถูกจัดเป็นงาน (tasks) พร้อมกับสปรินต์ (sprints), ข้อผิดพลาด (bugs) และคำขอ pull request ที่เกี่ยวข้องกับกรณีทดสอบเหล่านั้น มันไม่ใช่เครื่องมือจัดการการทดสอบเฉพาะทาง แต่โครงสร้างงานที่ยืดหยุ่นของมันช่วยให้ทีมสามารถสร้างกระบวนการทำงานของกรณีทดสอบได้โดยใช้สถานะ (statuses), สนาม (fields) และประเภทงาน (task types) ที่กำหนดเอง โดยไม่จำเป็นต้องใช้เครื่องมือแยกต่างหาก

คุณสมบัติหลักของ ClickUp

ข้อจำกัดของ ClickUp

ราคาของ ClickUp

คะแนนและรีวิวของ ClickUp

ผู้ใช้จริงพูดอะไรเกี่ยวกับ ClickUp?

นี่คือความคิดเห็นของผู้รีวิวบนG2:

สิ่งที่ผมชอบที่สุดเกี่ยวกับ ClickUp คือมันรวมทุกอย่างไว้ในที่เดียว งาน กำหนดเวลา บันทึก และการอัปเดต ทั้งหมดอยู่ในระบบเดียวกัน ซึ่งช่วยลดการต้องสลับไปมาระหว่างเครื่องมือต่าง ๆ ผมยังชื่นชมความยืดหยุ่นของมันด้วย เราสามารถปรับแต่งสถานะ สนามข้อมูล และมุมมองให้สอดคล้องกับวิธีการทำงานจริงของทีมเรา ซึ่งช่วยให้การจัดระเบียบเป็นไปอย่างง่ายดาย และให้ภาพที่ชัดเจนว่าใครรับผิดชอบอะไร และโครงการอยู่ในขั้นตอนใด ณ เวลาใดก็ตาม

TestRail

TestRail เป็นแพลตฟอร์มจัดการการทดสอบที่ออกแบบมาโดยเฉพาะสำหรับทีม QA ที่ต้องการการควบคุมอย่างเป็นระบบในกระบวนการทดสอบทั้งหมด มันจัดการวงจรครบถ้วนตั้งแต่การเขียน การรัน และการรายงานผลกรณีทดสอบ โดยมีการบูรณาการกับ DevOps และ CI/CD เพื่อนำผลลัพธ์เข้ามา

คุณสมบัติหลักของ TestRail

ข้อจำกัดของ TestRail

ราคาของ TestRail

คะแนนและรีวิวของ TestRail

ผู้ใช้จริงพูดอย่างไรเกี่ยวกับ TestRail?

นี่คือความคิดเห็นของผู้รีวิวจากG2:

สิ่งที่ผมเห็นว่ามีค่าที่สุดเกี่ยวกับ TestRail คือมันให้ทีม QA ของเราสภาพแวดล้อมที่ปลอดภัยและจัดระเบียบดี เพื่อจัดการแผนการทดสอบ กรณีการทดสอบ และการรันการทดสอบ ผมชื่นชมความง่ายในการจัดโครงสร้างและนำชุดการทดสอบไปใช้ รวมถึงการนำกรณีทดสอบที่สร้างไว้ก่อนหน้านี้มาใช้ซ้ำ การผสานการทำงานกับ Jira และเครื่องมือ CI/CD ได้ทำให้กระบวนการทำงานของเราเป็นหนึ่งเดียวและติดตามได้ง่ายขึ้น ความสามารถในการติดตามความคืบหน้าของการทดสอบและระดับการครอบคลุมแบบเรียลไทม์ได้ช่วยอย่างมากในการวางแผนสปรินต์และการรายงาน ในงานประจำวันของผมในฐานะวิศวกร QA การใช้ TestRail ยังช่วยประหยัดเวลาให้ผมได้อย่างมาก

Zephyr

Zephyr เป็นปลั๊กอินจัดการการทดสอบของ SmartBear สำหรับ Jira ที่ออกแบบมาเพื่อจัดการกรณีทดสอบจากภายในอินเทอร์เฟซของ Jira โดยสนับสนุนการทดสอบทั้งแบบมือและแบบอัตโนมัติ พร้อมด้วยคุณสมบัติการรายงานและการติดตามที่แข็งแกร่ง สำหรับทีมแบบ Agile และทีมระดับองค์กร

คุณสมบัติหลักของ Zephyr

ข้อจำกัดของ Zephyr

ราคา Zephyr

คะแนนและรีวิวของ Zephyr

ผู้ใช้จริงพูดอย่างไรเกี่ยวกับ Zephyr?

นี่คือความคิดเห็นจากผู้รีวิวบนG2:

นี่คือเครื่องมือที่ดีที่สุดสำหรับการนำเข้าเคสทดสอบโดยตรงจากไฟล์ Excel การใช้เครื่องมือนี้ช่วยลดภาระงานของผู้ทดสอบลงเมื่อเทียบกับการนำเข้าเคสทดสอบใน Jira นอกจากนี้ คุณสมบัติที่ดีที่สุดของเครื่องมือนี้ยังรวมถึงการกำหนดให้เคสทดสอบผ่านหรือล้มเหลว และการเพิ่มไฟล์แนบ

Jira

Jira เป็นแพลตฟอร์มการจัดการโครงการและการติดตามปัญหาของ Atlassian ซึ่งถูกใช้อย่างแพร่หลายโดยทีมวิศวกรรมและทีม QA เพื่อจัดการสปรินต์ ข้อผิดพลาด และกระบวนการพัฒนา แม้ว่าจะไม่ใช่เครื่องมือจัดการการทดสอบที่ออกแบบมาโดยเฉพาะ แต่ทีมหลายทีมก็ใช้มันร่วมกับโซลูชันอย่าง Zephyr Scale หรือ Xray เพื่อจัดการกรณีทดสอบภายในระบบ Jira ที่มีอยู่

คุณสมบัติหลักของ Jira

ข้อจำกัดของ Jira

ราคา Jira

คะแนนและรีวิวของ Jira

ผู้ใช้จริงพูดอย่างไรเกี่ยวกับ Jira?

นี่คือความคิดเห็นจากผู้รีวิวบนG2:

Jira เป็นหนึ่งในโปรแกรมดิจิทัลที่ฉันชื่นชอบที่สุด สำหรับการติดตามและแสดงผลประสิทธิภาพของทุกโครงการงานของฉัน ร่วมกับสมาชิกในทีมทำงานทั้งหมด เพราะมันมอบความสามารถในการแสดงผลประสิทธิภาพเสมือนที่ดีที่สุดในระดับเดียวกัน ทำให้การบรรลุเป้าหมายทางอาชีพของฉันทั้งหมดเป็นเรื่องที่ง่ายขึ้น

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยงเมื่อสร้างกรณีทดสอบ

หลีกเลี่ยงข้อผิดพลาดในการเขียนกรณีทดสอบเหล่านี้ ซึ่งอาจทำให้ประสิทธิภาพโดยรวมลดลง

วิธีรักษาความมีประโยชน์ของกรณีทดสอบให้คงอยู่ตลอดเวลา

ชุดทดสอบจะยังคงน่าเชื่อถือได้เมื่อแต่ละกรณีทดสอบเป็นอิสระต่อกัน มุ่งเป้าไปที่ข้อมูลนำเข้าที่มีโอกาสก่อให้เกิดข้อผิดพลาดสูงที่สุด และถูกยกเลิกทันทีที่หยุดให้ผลลัพธ์ที่เชื่อถือได้ หกแนวทางปฏิบัตินี้คือสิ่งที่แยกชุดทดสอบที่สามารถตรวจจับข้อผิดพลาดได้ต่อเนื่องเป็นเวลาหลายปี ออกจากชุดทดสอบที่ถูกเพิกเฉยหลังจากสปรินต์ที่สอง

เขียนการทดสอบแบบอิสระและแบบอะตอมิก

กรณีทดสอบควรกำหนดสถานะของตัวเองและไม่ควรขึ้นอยู่กับกรณีอื่นที่รันก่อน เมื่อ TC_CHECKOUT_003 สมมติว่า TC_CHECKOUT_002 ทิ้งสินค้าไว้ในตะกร้า ความล้มเหลวหนึ่งครั้งจะส่งผลต่อเนื่องเป็นห้าครั้ง และคุณต้องใช้เวลาทั้งเช้าเพื่อหาว่าความล้มเหลวใดเป็นความล้มเหลวที่แท้จริง หากชื่อกรณีทดสอบจำเป็นต้องใช้คำ “และ” ให้แบ่งเป็นสองกรณี

ทดสอบที่ขอบเขต

ข้อผิดพลาดมักเกิดขึ้นที่ขอบเขตของข้อมูลที่ระบบยอมรับ ไม่ใช่ในส่วนกลาง หากช่องใส่รหัสผ่านรับค่าได้ตั้งแต่ 8 ถึง 128 ตัวอักษร ให้ทดสอบค่า 7, 8, 128 และ 129 ไม่ใช่เพียงรหัสผ่าน 12 ตัวอักษรที่ใช้งานสะดวกเท่านั้น การวิเคราะห์ค่าขอบเขต (Boundary Value Analysis) เป็นเทคนิคอย่างเป็นทางการในมาตรฐานการออกแบบการทดสอบISO/IEC/IEEE 29119-4ด้วยเหตุผลนี้เอง: มันช่วยค้นพบข้อผิดพลาดแบบ "off-by-one" ที่การป้อนข้อมูลแบบสุ่มอาจพลาดไป

ใช้การแบ่งส่วนความเท่าเทียม (equivalence partitioning) เพื่อลดกรณีทดสอบที่ซ้ำซ้อน

จัดกลุ่มข้อมูลนำเข้าที่ระบบควรประมวลผลอย่างเหมือนกัน แล้วทดสอบตัวอย่างหนึ่งจากแต่ละกลุ่ม เนื่องจากทุกรูปแบบอีเมลที่ถูกต้องจะทำงานเหมือนกันในแบบฟอร์มเข้าสู่ระบบ ดังนั้นอีเมลที่ถูกต้องหนึ่งอันก็เพียงพอแล้ว การทดสอบ user@example.com, jane@company.com และ bob@domain.org เป็นสามกรณีแยกกัน จะทำให้ภาระการบำรุงรักษาเพิ่มขึ้นเป็นสามเท่า โดยไม่เพิ่มการครอบคลุม

แยกข้อมูลการทดสอบออกจากขั้นตอนการทดสอบ

การเขียนโค้ดแบบฮาร์ดโค้ด “enter test@example.com” ลงในขั้นตอนหนึ่ง หมายความว่าคุณต้องเขียนขั้นตอนนั้นใหม่ทุกครั้งที่สภาพแวดล้อมการทดสอบเปลี่ยนแปลง ให้ขั้นตอนมีความทั่วไป (“enter a registered email”) และเก็บค่าจริงไว้ในสนามข้อมูลการทดสอบหรือไฟล์ ขั้นตอนเดียวกันนี้จึงสามารถรันได้บนสภาพแวดล้อม staging, QA และ pre-production โดยไม่ต้องแก้ไข และการเปลี่ยนชุดข้อมูลใหม่สำหรับการทดสอบแบบลบ (negative test) ก็ทำได้ด้วยการเปลี่ยนแปลงเพียงหนึ่งบรรทัดเท่านั้น

ติดตามการทดสอบที่ไม่เสถียรและอัตราการหลุดของข้อบกพร่อง

การทดสอบแบบ flaky คือการทดสอบที่ล้มเหลวอย่างไม่สม่ำเสมอโดยไม่มีข้อผิดพลาดจริงในผลิตภัณฑ์ และทุกกรณีการทดสอบแบบ flaky จะทำให้ทีมเรียนรู้ที่จะเพิกเฉยต่อผลลัพธ์สีแดง ติดตามความถี่ที่แต่ละกรณีสลับไปมาระหว่างผ่านและล้มเหลวในเวอร์ชันที่เหมือนกัน หากกรณีใดมีอาการ flaky มากกว่าสองสามครั้งต่อเดือน ให้เขียนใหม่หรือลบออก ผสมผสานข้อมูลนี้กับอัตราการหลุดของข้อผิดพลาด (ข้อผิดพลาดที่พบในระบบผลิตที่กรณีการทดสอบควรตรวจพบได้) เพื่อดูว่าพื้นที่ใดมีความครอบคลุมน้อย ไม่ใช่เพียงพื้นที่ที่มีสัญญาณรบกวน

ทำให้การทดสอบที่คุณทำบ่อยที่สุดเป็นอัตโนมัติ

กรณีทดสอบแบบ Regression, Smoke และฟังก์ชันความถี่สูง เป็นกรณีที่เหมาะสมที่สุดสำหรับการอัตโนมัติ เนื่องจากถูกเรียกใช้ในทุกครั้งที่สร้างซอฟต์แวร์และแทบไม่มีการเปลี่ยนแปลง ย้ายกรณีเหล่านี้ไปยังสคริปต์ใน CI/CD pipeline ของคุณ และใช้เครื่องมือที่ได้รับการสนับสนุนจาก AI พร้อมตัวระบุตำแหน่งที่ซ่อมแซมตัวเองได้ ในกรณีที่องค์ประกอบ UI มีการเปลี่ยนแปลงบ่อยครั้ง สิ่งนี้จะช่วยให้ผู้ทดสอบมนุษย์มีเวลาว่างสำหรับงานสำรวจและประเภทการทดสอบซอฟต์แวร์ที่ต้องการการตัดสินใจ เช่น การทดสอบความสะดวกในการใช้งานและการค้นหากรณีขอบเขต

วิธีเขียนและรันกรณีทดสอบใน ClickUp

ส่วนเครื่องมือข้างต้นได้อธิบายว่า ClickUp สามารถใช้ในส่วนใดได้บ้าง ส่วนนี้จะแสดงขั้นตอนการตั้งค่าจริง ซึ่งสอดคล้องกับขั้นตอนที่กล่าวถึงก่อนหน้านี้ในคู่มือ

จัดโครงสร้างไลบรารีกรณีทดสอบของคุณ สร้าง Space สำหรับผลิตภัณฑ์ของคุณ, Folder สำหรับแต่ละพื้นที่ฟีเจอร์ (เช่น การยืนยันตัวตน, การชำระเงิน, การเริ่มต้นใช้งาน), และ List สำหรับแต่ละรอบการทดสอบหรือสปรินต์ แต่ละงานจะกลายเป็นกรณีทดสอบแยกต่างหาก ใช้Custom Fields ของ ClickUpเพื่อบันทึกองค์ประกอบต่างๆ เช่น ID ของกรณีทดสอบ, เงื่อนไขเบื้องต้น, ข้อมูลทดสอบ, ระดับความสำคัญ และสภาพแวดล้อม

เขียนขั้นตอนการทดสอบโดยตรงใน任务 ใช้ส่วนคำอธิบายของ任务เพื่อบันทึกขั้นตอนการดำเนินการตามลำดับและผลลัพธ์ที่คาดการณ์ไว้ รายการตรวจสอบ (checklists) เหมาะสำหรับกระบวนการแบบทีละขั้นตอน ซึ่งผู้ทดสอบต้องทำเครื่องหมายเมื่อดำเนินการแต่ละขั้นตอนเสร็จสิ้น ส่วนคำอธิบายจะเก็บข้อมูลบริบท เช่น เงื่อนไขเบื้องต้นและข้อมูลการทดสอบ

ติดตามการดำเนินการและผลลัพธ์ สร้างสถานะที่กำหนดเอง (Custom Statuses) ที่สะท้อนขั้นตอนการทำงานการทดสอบของคุณ: ยังไม่เริ่ม → กำลังดำเนินการ → ผ่าน → ล้มเหลว → ถูกบล็อก เมื่อการทดสอบล้มเหลว ให้แปลงเป็นงานบั๊ก (bug task) หรือสร้างงานที่เชื่อมโยง (linked task) ที่มอบหมายให้ผู้พัฒนา พร้อมด้วยลำดับความสำคัญ ความพึ่งพา และกำหนดเวลา การผสานการทำงานกับ GitHub และ GitLab ช่วยให้คุณสามารถเชื่อมโยงบั๊กนั้นโดยตรงกับ PR ที่ก่อให้เกิดปัญหาได้ หากสาเหตุหลักเป็นข้อบกพร่องในโค้ด คุณสามารถมอบหมายงานบั๊กนั้นให้กับClickUp Codegen Agent ซึ่งจะอ่านคำอธิบายงาน สเปคที่เชื่อมโยง และความคิดเห็น เขียนข้อเสนอการแก้ไข และเปิด pull request เพื่อตรวจสอบ โดยความคืบหน้าจะถูกส่งกลับไปยังงานนั้น

เคล็ดลับจากผู้เชี่ยวชาญ: หัวหน้าทีม QA สามารถดูภาพรวมของงานใดก็ได้ทันที โดยขอให้ ClickUp Brain สรุปงานบั๊กที่ยังเปิดอยู่ ด้วยวิธีนี้ พวกเขาจะมีข้อมูลบริบททั้งหมดที่จำเป็นสำหรับการทบทวนสปรินต์ โดยไม่ต้องค้นหาข้อมูลจากงานแต่ละงานเพื่อประกอบภาพรวม

ดำเนินการทดสอบด้วยมุมมอง ใช้มุมมองบอร์ด (Board View) ที่จัดกลุ่มตามสถานะ เพื่อดูการกระจายผลผ่าน/ไม่ผ่านได้ทันทีระหว่างการทดสอบ มุมมองตาราง (Table View) ทำงานเหมือนเมทริกซ์การทดสอบแบบดั้งเดิม เมื่อคุณต้องการตรวจสอบผลลัพธ์จากกรณีทดสอบหลายสิบกรณี กรองตามผู้รับผิดชอบเพื่อปรับสมดุลปริมาณงาน หรือตามลำดับความสำคัญเพื่อมุ่งเน้นการทดสอบเบื้องต้น (smoke test) ที่เส้นทางวิกฤตก่อน

เทมเพลตการจัดการการทดสอบของ ClickUpให้คุณมีวิธีจัดการกระบวนการทดสอบทั้งหมดแบบรวมศูนย์ ในหลายพื้นที่ฟีเจอร์ สถานการณ์การทดสอบ และกรณีขอบเขต ในที่เดียว ใช้เทมเพลตนี้เพื่อติดตามความคิดเห็นของผู้ใช้ จัดการตารางการทดสอบ ติดตามความคืบหน้าของการทดสอบ และประเมินผลการผ่าน/ไม่ผ่าน โดยไม่ต้องสลับไปมาระหว่างเครื่องมือต่าง ๆ

ดาวน์โหลดเทมเพลตฟรี

จัดการกระบวนการทดสอบของคุณอย่างมีประสิทธิภาพ

กรณีทดสอบจะถือว่าสมบูรณ์เมื่อมีสองคนสามารถรันมันได้อย่างอิสระและได้ผลลัพธ์ผ่านหรือล้มเหลวที่เหมือนกัน ทุกอย่างในคู่มือนี้ (ดำเนินการหนึ่งขั้นตอนต่อหนึ่งขั้นตอน เงื่อนไขเบื้องต้นที่ชัดเจน ผลลัพธ์ที่คาดหวังโดยไม่มีช่องว่างสำหรับการตีความ) ล้วนมุ่งสู่มาตรฐานเดียวนี้ หากคุณกำลังวางแผนสปรินต์ใน ClickUp อยู่แล้ว การตั้งค่าที่กล่าวถึงข้างต้นจะช่วยให้คุณเขียน รัน และติดตามกรณีทดสอบพร้อมกับข้อบกพร่องที่มันค้นพบได้ โดยไม่ต้องเพิ่มเครื่องมืออื่นเข้ามา

สมัครใช้ ClickUp ฟรี

คำถามที่มักถูกถามเกี่ยวกับกรณีทดสอบ

ข้อกำหนดหนึ่งควรมีกรณีทดสอบกี่กรณี?

ข้อกำหนดหนึ่งข้ออาจต้องการกรณีทดสอบหนึ่งหรือสิบกรณี ขึ้นอยู่กับจำนวนสถานการณ์ กรณีขอบเขต และรูปแบบข้อมูลเข้าที่เกี่ยวข้อง เป้าหมายคือเพื่อครอบคลุมทุกเส้นทางที่เป็นไปได้จริง โดยให้การครอบคลุมที่เพียงพอโดยไม่มีความซ้ำซ้อน

ความแตกต่างระหว่างกรณีทดสอบและสคริปต์ทดสอบคืออะไร?

กรณีทดสอบคือเอกสารที่ระบุสิ่งที่ต้องทดสอบและผลลัพธ์ที่คาดหวัง โดยเขียนขึ้นเพื่อดำเนินการด้วยมือ ส่วนสคริปต์ทดสอบคือเวอร์ชันอัตโนมัติ คือโค้ดที่ดำเนินการขั้นตอนเดียวกันนั้นผ่านโปรแกรม

ขั้นตอนการทดสอบควรมีรายละเอียดมากแค่ไหน?

แบ่งการทดสอบออกเป็นขั้นตอนที่มีตรรกะและเป็นลำดับ ซึ่งสามารถติดตามได้ง่ายโดยไม่ต้องมีบริบทล่วงหน้า อย่ารวมหลายการกระทำเข้าด้วยกันหรือเพิ่มความซับซ้อนที่ไม่จำเป็น

สถานการณ์การทดสอบระบุ สิ่งที่จะทดสอบ ในหนึ่งบรรทัด (“ตรวจสอบการรีเซ็ตรหัสผ่าน”); ส่วนกรณีการทดสอบระบุ วิธีการ พร้อมด้วยเงื่อนไขเบื้องต้น ขั้นตอน ข้อมูลการทดสอบ และผลลัพธ์ที่คาดหวัง สถานการณ์หนึ่งมักสร้างกรณีการทดสอบ 3 ถึง 10 กรณี ที่ครอบคลุมเส้นทางปกติ ข้อมูลป้อนเข้าที่ไม่ถูกต้อง และเงื่อนไขขอบเขต สถานการณ์มาเป็นอันดับแรกและกำหนดการวางแผนความครอบคลุม ส่วนกรณีการทดสอบมาเป็นอันดับสองและกำหนดการดำเนินการ

กรณีทดสอบเชิงบวกใช้ข้อมูลนำเข้าที่ถูกต้องและคาดหวังผลลัพธ์ที่สำเร็จ: อีเมลและรหัสผ่านที่ถูกต้องจะช่วยให้ผู้ใช้เข้าสู่ระบบได้ ส่วนกรณีทดสอบเชิงลบใช้ข้อมูลนำเข้าที่ไม่ถูกต้องหรือไม่คาดคิด และคาดหวังว่าระบบจะล้มเหลวอย่างเรียบร้อย: รหัสผ่านที่ผิดจะแสดงข้อความ “รหัสผ่านไม่ถูกต้อง” โดยไม่สร้างเซสชัน ชุดการทดสอบที่พัฒนาอย่างครบถ้วนจะมีสัดส่วนกรณีทดสอบเชิงบวกต่อเชิงลบประมาณ 1:3 ถึง 1:5 เนื่องจากข้อผิดพลาดส่วนใหญ่ในระบบผลิตมักเกิดขึ้นในเส้นทางข้อผิดพลาด (error paths) ไม่ใช่ในเส้นทางที่ทำงานปกติ (happy paths)

แผนการทดสอบกำหนดขอบเขต วิธีการ ทรัพยากร และกำหนดการสำหรับงานทดสอบทั้งหมด ชุดการทดสอบ (test suite) คือการรวบรวมกรณีการทดสอบที่จัดกลุ่มไว้เพื่อดำเนินการครั้งเดียว เช่น “ชุดการทดสอบการถดถอย (regression suite) สำหรับเวอร์ชัน 2.1” กรณีการทดสอบ (test case) คือหน่วยพื้นฐานภายในทั้งสองส่วน: การตรวจสอบที่บันทึกไว้อย่างชัดเจน พร้อมผลลัพธ์ผ่าน/ไม่ผ่าน แผนกำหนดกลยุทธ์ ชุดการทดสอบกำหนดขอบเขต และกรณีการทดสอบกำหนดผลลัพธ์