“การทดสอบฟังก์ชัน (Functional testing) กับ การทดสอบอัตโนมัติ (Automated testing)” เป็นหนึ่งในการเปรียบเทียบที่พบบ่อยที่สุดในการประกันคุณภาพ (QA) และเป็นการเปรียบเทียบที่เกิดจากความเข้าใจผิด สองคำนี้ไม่ได้ตรงข้ามกัน อธิบายถึงสิ่งที่แตกต่างกันโดยสิ้นเชิง และคุณสามารถมีอย่างใดอย่างหนึ่งโดยไม่มีอีกอย่างหนึ่ง หรือมีทั้งสองอย่างพร้อมกันได้ การมองว่าเป็นการเลือกระหว่างการทดสอบฟังก์ชัน หรือ การทดสอบอัตโนมัติ ทำให้ทีมสร้างกลยุทธ์การทดสอบที่ผิดพลาด
คู่มือนี้จะอธิบายความแตกต่างของสองคำนี้, ชี้แจงถึงแกนที่แยกจากกันสองแกนที่คำเหล่านี้สังกัดอยู่, และแสดงให้เห็นว่าแต่ละคำเข้ากันได้อย่างไรในขั้นตอนการทำงานของการทดสอบ API จริง
ข้อผิดพลาดในการจัดหมวดหมู่
ความสับสนเกิดจากการเปรียบเทียบคำตอบสำหรับคำถามที่แตกต่างกันสองข้อ
การทดสอบฟังก์ชันตอบคำถาม: เรากำลังทดสอบอะไร? เป็นการทดสอบว่าซอฟต์แวร์ทำงานตามที่ควรจะเป็นหรือไม่, ตรวจสอบคุณสมบัติ, พฤติกรรม, และผลลัพธ์
การทดสอบอัตโนมัติตอบคำถาม: เรากำลังทำการทดสอบอย่างไร? เป็นการทำการทดสอบด้วยเครื่องมือซอฟต์แวร์ แทนที่จะให้มนุษย์ดำเนินการตามขั้นตอนด้วยตนเอง
สิ่งเหล่านี้เป็นอิสระต่อกัน “สิ่งที่คุณทดสอบ” และ “วิธีที่คุณดำเนินการ” เป็นแกนที่แยกจากกัน การทดสอบฟังก์ชันสามารถดำเนินการได้ด้วยตนเองหรือโดยอัตโนมัติ การทดสอบอัตโนมัติสามารถตรวจสอบพฤติกรรมฟังก์ชันหรือพฤติกรรมที่ไม่ใช่ฟังก์ชัน เช่น ประสิทธิภาพ ดังนั้น การเปรียบเทียบที่แท้จริงไม่ใช่ฟังก์ชันเทียบกับอัตโนมัติ แต่เป็นสองมิติที่แตกต่างกันที่มักถูกกล่าวถึงพร้อมกันโดยบังเอิญ
เมื่อคุณเข้าใจเช่นนั้น คำถามที่ว่า “เราควรทำการทดสอบฟังก์ชันหรือการทดสอบอัตโนมัติ?” ก็จะไม่มีความหมายอีกต่อไป คำถามที่ถูกต้องคือ: เราควรทดสอบอะไร และการทดสอบเหล่านั้นส่วนใดที่เราควรทำให้เป็นอัตโนมัติ?
การทดสอบฟังก์ชันคืออะไร
การทดสอบฟังก์ชันเป็นการตรวจสอบว่าคุณสมบัติแต่ละอย่างของแอปพลิเคชันทำงานตามข้อกำหนด โดยทั่วไปแล้วเป็นการทดสอบแบบ Black-box: ผู้ทดสอบจะตรวจสอบอินพุตและเอาต์พุตโดยไม่ดูโค้ดภายใน ให้ข้อมูลนำเข้าแก่ฟังก์ชัน, สังเกตผลลัพธ์, และเปรียบเทียบกับสิ่งที่ข้อกำหนดระบุว่าควรจะเกิดขึ้น
สำหรับการทดสอบ API, การทดสอบฟังก์ชันหมายถึงการยืนยันว่า Endpoint ส่งคืนข้อมูลที่ถูกต้อง, รหัสสถานะที่ถูกต้อง, และการตอบสนองข้อผิดพลาดที่ถูกต้อง `POST /orders` สร้างคำสั่งซื้อหรือไม่? ปฏิเสธ Payload ที่ไม่ถูกต้องด้วย `400` หรือไม่? การตอบสนองตรงกับ Schema ที่ระบุไว้หรือไม่? สิ่งเหล่านี้คือการตรวจสอบฟังก์ชัน และอยู่บนพื้นฐานของ การยืนยัน API (API assertions) ที่เปรียบเทียบการตอบสนองจริงกับที่คาดหวังไว้
จุดแข็งของการทดสอบฟังก์ชันคือความเกี่ยวข้องโดยตรง: เป็นการตรวจสอบสิ่งที่ผู้ใช้ให้ความสำคัญจริงๆ ว่าฟังก์ชันทำงานได้หรือไม่ ข้อจำกัดของมันคือขอบเขต การทดสอบฟังก์ชันเพียงอย่างเดียวไม่ได้บอกอะไรเกี่ยวกับความเร็ว, ความเสถียรภายใต้ภาระงาน, หรือความปลอดภัย Endpoint อาจทำงานได้อย่างสมบูรณ์แบบในเชิงฟังก์ชัน แต่ก็ยังล่มได้ภายใต้ปริมาณการใช้งาน; ช่องว่างนั้นคือสิ่งที่ การทดสอบประสิทธิภาพ (performance testing) ครอบคลุม การทดสอบฟังก์ชันเป็นสิ่งจำเป็น แต่ก็ไม่ใช่ภาพรวมทั้งหมด
สิ่งที่ตรงกันข้ามกับการทดสอบฟังก์ชันคือ การทดสอบที่ไม่ใช่ฟังก์ชัน (non-functional testing) เช่น ประสิทธิภาพ, ภาระงาน, ความปลอดภัย, ความสามารถในการใช้งาน ซึ่งเป็นคู่ที่ถูกต้องของคำนี้ ไม่ใช่ “การทดสอบอัตโนมัติ”
การทดสอบอัตโนมัติคืออะไร
การทดสอบอัตโนมัติใช้เครื่องมือและสคริปต์เพื่อดำเนินการทดสอบและตรวจสอบผลลัพธ์ แทนที่จะให้คนคลิกตามขั้นตอนด้วยตนเอง คุณกำหนดการทดสอบเพียงครั้งเดียว พร้อมอินพุตและผลลัพธ์ที่คาดหวัง จากนั้นเครื่องมือจะรันตามต้องการ ตามกำหนดเวลา หรือเมื่อมีการเปลี่ยนแปลงโค้ดทุกครั้ง
สิ่งที่ตรงกันข้ามกับการทดสอบอัตโนมัติคือ การทดสอบด้วยตนเอง (manual testing) โดยที่มนุษย์จะดำเนินการแต่ละขั้นตอน นั่นคือคู่ที่ถูกต้องของคำนี้
คุณค่าของระบบอัตโนมัติคือความสม่ำเสมอและขนาด เครื่องจักรจะรันการทดสอบครั้งที่หนึ่งพันได้เหมือนกับครั้งแรก และไม่เคยเหน็ดเหนื่อย มันทำให้การทดสอบ Regression มีราคาถูกพอที่จะรันได้ทุกครั้งที่ Commit โค้ด ค่าใช้จ่ายคือการทดสอบอัตโนมัติจะต้องถูกเขียนและดูแลรักษา และไม่สามารถตัดสินใจได้เอง ตรวจสอบได้เฉพาะสิ่งที่ได้รับคำสั่งให้คาดหวังเท่านั้น ข้อมูลเชิงลึกเพิ่มเติมสามารถดูได้ที่ การทดสอบอัตโนมัติคืออะไร
ที่สำคัญคือ ระบบอัตโนมัติเป็นกลไกในการดำเนินการ ไม่ใช่ประเภทของการทดสอบ คุณทำให้การทดสอบ บางประเภท เป็นอัตโนมัติ ไม่ว่าจะเป็นฟังก์ชัน, ประสิทธิภาพ, ความปลอดภัย คำว่า “การทดสอบอัตโนมัติ” เพียงอย่างเดียวไม่ได้บอกว่ากำลังตรวจสอบอะไรอยู่
การรวมกันของสองแกน
นำสองแกนมารวมกัน คุณจะได้สี่หมวดหมู่ที่เกิดขึ้นจริง ซึ่งทั้งหมดมีอยู่ในการปฏิบัติ
| ฟังก์ชัน (Functional) | ไม่ใช่ฟังก์ชัน (Non-functional) | |
|---|---|---|
| ด้วยตนเอง (Manual) | ผู้ทดสอบคลิกผ่านขั้นตอนการชำระเงินเพื่อยืนยันว่าใช้งานได้ | ผู้ทดสอบตัดสินว่า UI ตอบสนองได้ดีหรือไม่ |
| อัตโนมัติ (Automated) | สคริปต์เรียกใช้ Endpoint และยืนยันว่าการตอบสนองถูกต้อง | การทดสอบ Load Test จำลองผู้ใช้เสมือน 500 คนและวัดค่า Latency |
แต่ละช่องเป็นการทดสอบที่ถูกต้องและพบบ่อย ช่องซ้ายบน, การทดสอบฟังก์ชันด้วยตนเอง, เป็นสิ่งที่คนส่วนใหญ่นึกภาพออกเมื่อได้ยินคำว่า “การทดสอบ” ช่องซ้ายล่าง, การทดสอบฟังก์ชันอัตโนมัติ, คือชุดทดสอบ API สมัยใหม่ส่วนใหญ่: สคริปต์หรือสถานการณ์ที่ตรวจสอบฟังก์ชันโดยอัตโนมัติ คอลัมน์ขวาคืองานที่ไม่ใช่ฟังก์ชัน ซึ่งสามารถทำได้ทั้งสองวิธีเช่นกัน
ดังนั้น การตัดสินใจที่มีความหมายจึงไม่ใช่ “ฟังก์ชันหรืออัตโนมัติ” แต่เป็น:
- จะทดสอบพฤติกรรมใด: ทั้งฟังก์ชันและไม่ใช่ฟังก์ชันจำเป็นต้องได้รับการครอบคลุม
- จะทำการทดสอบใดให้เป็นอัตโนมัติ: การทดสอบที่เสถียร, ทำซ้ำ, และมีคุณค่าสูง; ปล่อยให้การตรวจสอบแบบสำรวจและที่ต้องอาศัยการตัดสินใจเป็นแบบด้วยตนเอง
การทดสอบสามารถอยู่ในช่องใดก็ได้ และกลยุทธ์ที่ดีจะใช้ทั้งสี่ช่อง
สิ่งนี้เชื่อมโยงกับการทดสอบ API อย่างไร
การทดสอบ API เป็นจุดที่สองแกนนี้สอดคล้องกันอย่างชัดเจนที่สุด เพราะ API เหมาะสมอย่างยิ่งกับการทดสอบฟังก์ชันอัตโนมัติ
API มีสัญญาที่ชัดเจน, โครงสร้างคำขอและการตอบสนอง, และไม่มี UI ที่ต้องแสดงผล สิ่งนี้ทำให้พฤติกรรมฟังก์ชันของมันง่ายต่อการตรวจสอบด้วยสคริปต์และง่ายต่อการยืนยันอย่างแม่นยำ ดังนั้น สำหรับ API, การทดสอบฟังก์ชันส่วนใหญ่ควรเป็นอัตโนมัติ มีเหตุผลน้อยมากที่จะต้องส่งคำขอเดิมซ้ำด้วยตนเองและเพ่งมองการตอบสนองเป็นร้อยครั้ง ในเมื่อเครื่องมือสามารถทำได้ทุกครั้งที่มีการคอมมิต
แนวทางการทดสอบ API ที่เป็นรูปธรรมมีดังนี้ การตรวจสอบฟังก์ชัน, รหัสสถานะ, เนื้อหาการตอบสนอง, ความสอดคล้องของ Schema, รูปแบบข้อผิดพลาด, ถูกเขียนเป็น Test Case และจัดกลุ่มเป็น Test Scenario สิ่งเหล่านี้จะรันโดยอัตโนมัติ, ทุกครั้งที่มีการเปลี่ยนแปลง, ผ่าน CI/CD การตรวจสอบที่ไม่ใช่ฟังก์ชัน, เช่น Load และ Performance, ก็จะรันโดยอัตโนมัติเช่นกันตามกำหนดเวลา ความพยายามด้วยตนเองจะเน้นไปที่การทดสอบแบบสำรวจ (Exploratory testing) และการตรวจสอบยืนยันว่า API แก้ปัญหาได้อย่างแท้จริง, ซึ่งเป็นงาน Validation ที่ต้องอาศัยการตัดสินใจ ไม่ใช่สคริปต์
อะไรที่ควรทำเป็นอัตโนมัติ และอะไรที่ควรทำด้วยตนเอง
เมื่อเห็นสองแกนอย่างชัดเจน ก็นำไปสู่คำถามที่สำคัญจริงๆ: ในบรรดาการทดสอบฟังก์ชันทั้งหมดที่คุณสามารถทำได้ การทดสอบใดที่ควรค่าแก่การทำเป็นอัตโนมัติ? การทำทุกอย่างให้เป็นอัตโนมัติเป็นการสิ้นเปลือง และการทำสิ่งที่ผิดให้เป็นอัตโนมัติจะสร้างชุดทดสอบที่ช้าและเปราะบาง มีกฎบางประการที่ช่วยได้
ทำสิ่งซ้ำๆ และเสถียรให้เป็นอัตโนมัติ การตรวจสอบฟังก์ชันที่คุณจะรันทุกครั้งที่ Commit เป็นเวลาสองปีข้างหน้า เป็นผู้สมัครที่สมบูรณ์แบบสำหรับการทำเป็นอัตโนมัติ ค่าใช้จ่ายในการเขียนจะถูกคืนกลับมาหลายร้อยเท่า การทดสอบ Regression ซึ่งเป็นการตรวจสอบที่ยืนยันว่าคุณสมบัติเก่าๆ ยังคงทำงานได้ เป็นกรณีที่ชัดเจนที่สุด
ทำเส้นทางที่มีมูลค่าสูงให้เป็นอัตโนมัติก่อน ขั้นตอนการเข้าสู่ระบบ, การชำระเงิน, Endpoint API หลัก, อะไรก็ตามที่ความล้มเหลวเป็นเหตุการณ์ร้ายแรง ควรได้รับการทำเป็นอัตโนมัติตั้งแต่เนิ่นๆ นี่คือการทดสอบที่คุณไม่สามารถข้ามได้ภายใต้แรงกดดันจากกำหนดเวลา และระบบอัตโนมัติจะช่วยลดการล่อลวงนั้น
อย่าทำสิ่งที่หายากหรือไม่เสถียรให้เป็นอัตโนมัติ การตรวจสอบที่คุณจะรันเพียงสองครั้งไม่คุ้มค่าที่จะเขียนสคริปต์ ฟังก์ชันที่ยังคงเปลี่ยนแปลงทุกวันจะทำให้การทดสอบเสียทุกวัน; รอจนกว่าจะนิ่ง การทำเป้าหมายที่กำลังเคลื่อนไหวให้เป็นอัตโนมัติก่อนเวลาอันควรแค่สร้างภาระในการดูแลรักษา
คงการทดสอบแบบสำรวจไว้ด้วยตนเอง การทดสอบอัตโนมัติจะพบเฉพาะสิ่งที่คุณสั่งให้ค้นหาเท่านั้น มนุษย์ที่สำรวจซอฟต์แวร์ด้วยวิธีที่ไม่ใช่สคริปต์จะพบข้อบกพร่องที่ไม่มีใครคาดคิด งานนี้เป็นการทดสอบฟังก์ชันเช่นกัน และควรทำด้วยตนเองโดยตั้งใจ
คงการตรวจสอบที่ต้องอาศัยการตัดสินใจไว้ด้วยตนเอง ไม่ว่าข้อความแสดงข้อผิดพลาดจะเป็นประโยชน์จริงหรือไม่, ไม่ว่าขั้นตอนการทำงานจะมีความสอดคล้องกันหรือไม่, ไม่ว่า API จะแก้ปัญหาของผู้ใช้ได้จริงหรือไม่, สิ่งเหล่านี้ต้องการบุคคลเข้ามาเกี่ยวข้อง ไม่มีการยืนยันใดที่สามารถจับสิ่งเหล่านี้ได้
ผลลัพธ์คือการแบ่งแยกอย่างจงใจ: ชุดทดสอบฟังก์ชันอัตโนมัติขนาดใหญ่ที่ครอบคลุมเส้นทางที่เสถียร, สำคัญ, ทำซ้ำได้, และความพยายามด้วยตนเองที่น้อยกว่า แต่ต่อเนื่อง ซึ่งเน้นการสำรวจและการตัดสินใจ ทีมที่ทำการอัตโนมัติอย่างรอบคอบจะได้รับผลตอบรับที่รวดเร็วโดยไม่มีชุดทดสอบที่เปราะบาง; ทีมที่ทำทุกอย่างเป็นอัตโนมัติสุดท้ายก็ต้องดูแลรักษาการทดสอบแทนที่จะปล่อยผลิตภัณฑ์
การสร้างการทดสอบ API ฟังก์ชันอัตโนมัติใน Apidog
Apidog ถูกสร้างขึ้นสำหรับการทดสอบ API ฟังก์ชันอัตโนมัติโดยไม่ต้องเขียนสคริปต์ คุณกำหนด Endpoint, เพิ่มการยืนยันด้วยภาพสำหรับสถานะ, ฟิลด์ Body, Schema, และเวลาตอบสนอง, จากนั้นจัดกลุ่มคำขอเป็น Test Scenario Scenario เหล่านั้นจะรันตามต้องการหรือใน Pipeline ของ CI, ทำการตรวจสอบฟังก์ชันโดยอัตโนมัติและรายงานอย่างแม่นยำว่าการยืนยันใดล้มเหลว
เนื่องจาก Workspace เดียวกันยังสามารถรัน Load test ได้ด้วย คุณจึงครอบคลุมทั้งสองแกน ทั้งฟังก์ชันและไม่ใช่ฟังก์ชัน ซึ่งเป็นแบบอัตโนมัติ ในที่เดียว Scenario ฟังก์ชันที่คุณสร้างขึ้นเพื่อความถูกต้อง จะกลายเป็นการทดสอบ Load test ที่คุณรันเพื่อประสิทธิภาพ ดาวน์โหลด Apidog เพื่อสร้างชุดทดสอบ API ฟังก์ชันอัตโนมัติสำหรับ API ที่คุณมีอยู่แล้ว
คำถามที่พบบ่อย
การทดสอบอัตโนมัติเป็นประเภทหนึ่งของการทดสอบฟังก์ชันหรือไม่? ไม่ใช่ การทดสอบอัตโนมัติเป็นวิธีการดำเนินการทดสอบ การทดสอบฟังก์ชันเป็นหมวดหมู่ของสิ่งที่คุณทดสอบ การทดสอบอัตโนมัติสามารถเป็นฟังก์ชันหรือไม่ใช่ฟังก์ชันก็ได้; การทดสอบฟังก์ชันสามารถทำด้วยตนเองหรืออัตโนมัติก็ได้
การทดสอบฟังก์ชันสามารถทำเป็นอัตโนมัติได้หรือไม่? ได้ และสำหรับ API ส่วนใหญ่ควรทำ การทดสอบฟังก์ชันอัตโนมัติ, สคริปต์หรือ Scenario ที่ตรวจสอบฟังก์ชันทุกครั้งที่มีการเปลี่ยนแปลง, เป็นหัวใจสำคัญของชุดทดสอบ API สมัยใหม่
สิ่งที่ตรงกันข้ามกับการทดสอบฟังก์ชันอย่างแท้จริงคืออะไร? การทดสอบที่ไม่ใช่ฟังก์ชัน: ประสิทธิภาพ, ภาระงาน, ความปลอดภัย, และความสามารถในการใช้งาน สิ่งเหล่านี้ตรวจสอบคุณภาพอื่นๆ นอกเหนือจากการที่ฟังก์ชันสร้างผลลัพธ์ที่ถูกต้องหรือไม่
การทดสอบฟังก์ชันทุกอย่างควรเป็นอัตโนมัติหรือไม่? ไม่ใช่ ทำให้การตรวจสอบที่เสถียร, ทำซ้ำได้, มีคุณค่าสูงเป็นอัตโนมัติ คงการทดสอบแบบสำรวจและการตรวจสอบยืนยันที่ต้องอาศัยการตัดสินใจไว้ด้วยตนเอง เพราะระบบอัตโนมัติไม่สามารถตัดสินใจได้ว่าสิ่งใดดีอย่างแท้จริง ทำได้เพียงตรวจสอบว่าตรงตามความคาดหวังหรือไม่
ทีมควรเริ่มต้นจากที่ใด? ด้วยการทดสอบ API ฟังก์ชันอัตโนมัติ การทดสอบเหล่านี้รวดเร็ว, เสถียร, และครอบคลุมตรรกะหลัก เพิ่มการทดสอบที่ไม่ใช่ฟังก์ชันอัตโนมัติและการทดสอบแบบสำรวจด้วยตนเองจากจุดนั้น
การทดสอบอัตโนมัติจะเข้ามาแทนที่ผู้ทดสอบด้วยตนเองหรือไม่? ไม่ใช่ มันเข้ามาแทนที่ส่วนที่ซ้ำซากของงานของพวกเขา, เช่นการรันการตรวจสอบเดิมซ้ำๆ, เพื่อให้ผู้ทดสอบสามารถมุ่งเน้นไปที่การทดสอบแบบสำรวจ, กรณีขอบ (edge cases), และการตัดสินว่าซอฟต์แวร์นั้นดีอย่างแท้จริงหรือไม่ งานเหล่านั้นต้องการคน และมีคุณค่าสูงกว่าการคลิกผ่านรายการตรวจสอบ Regression ด้วยตนเอง
การทดสอบเดียวกันสามารถเป็นได้ทั้งแบบฟังก์ชันและอัตโนมัติได้หรือไม่? ได้ และการทดสอบ API ส่วนใหญ่ก็เป็นเช่นนั้น: การทดสอบฟังก์ชันอัตโนมัติ สคริปต์ที่เรียกใช้ Endpoint และยืนยันว่าการตอบสนองถูกต้องเป็นการตรวจสอบฟังก์ชันและรันโดยอัตโนมัติ สองป้ายกำกับนี้อธิบายถึงแง่มุมที่แตกต่างกันของการทดสอบเดียวกัน ไม่ใช่ความขัดแย้งกัน