จุดประสงค์ของการทำการทดสอบคือ
- เราต้องการความมั้นใจในการใช้งาน Software(ใช้ไปแล้วจะไม่มี Bug หรือ Defect เกิดขึ้น)
- เราต้องแน่ใจว่า software ของเรานั้นสามารถรองรับ user ที่เรามีอยู่ทั้งหมดได้
- เราต้องแน่ใจว่า Software ของเราสามารถตอบสนองความต้องการของ Business ได้
- เราต้องแน่ใจว่า software ที่เราได้นั้นมีความปลอดภัย
ซึ่งการทำการทดสอบซอฟต์แวร์(Software Testing) จะแบ่งออกเป็นกลุ่มหลักๆ ดังนี้
Black Box vs White Box
ในการทดสอบซอฟต์แวร์เราจะแบ่งรูปแบบของการทดสอบออกเป็น 3 ประเภทย่อยๆ ตามข้อมูลที่เรามี โดยเราจะแบ่งออกเป็น
Black-box Testing
Black-box testing เป็นการทดสอบตาม Spec เป็นหลักเรียกว่าเป็น Spec-based คือเราจะดูจาก requirements spec ว่ามี feature การทำงานยังไงบ้างแล้วก็ทำการทดสอบตามนั้น ดังนั้นการทดสอบประเภทนี้เราจะไม่ได้สนใจว่า source code เขียนไว้ยังไง เหมือนกล่องดำที่เราไม่สนใจว่าข้างในมีอะไรเราจะสนใจเฉพาะ input และ output ที่ได้จากกล่องดำ(blackbox นั้นเท่านั้น)
| ข้อดี | ข้อเสีย |
|---|---|
| เป็นการทดสอบที่สามารถทำได้รวดเร็ว | ไม่ได้การันตีว่าเราจะ test ครบทุกส่วนของโปรแกรม |
| ไม่ต้องเปิดเผย Source Code | ผลลัพธ์ของการทดสอบจะดีหรือไม่ดีขึ้นอยู่กับความรู้และความเชี่ยวชาญของ tester |
| เป็นมุมมองของ User เป็นหลัก | การทดสอบโดยส่วนใหญ่ tester จะมีความรู้ในระบบน้อย |
White-box Testing
White-box testing หรือ Crystal-box testing เป็นการทดสอบที่เรามีข้อมูลทุกอย่างที่อยากรู้เราจึงเขียน Test-cases โดยอ้างอิงตาม source code
| ข้อดี | ข้อเสีย |
|---|---|
| สามารถค้นหา Error ได้ดีกว่า black-box | ต้องสามารถเข้าถึง Source code ได้ |
| เป็นมุมมองของ Developer เป็นหลัก | ไม่สามารถค้นหาส่วนที่ยังไม่ได้เขียน code ได้ |
| เราสามารถทดสอบ Code ได้ทุกบรรทัด | ต้องใช้ Developer เป็นคนเขียน Test-case ซึ่งจะเป็น resource ที่หาได้ยาก |
ในการทดสอบแบบ whitebox เราจะเน้นที่ path coverage(การทดสอบให้ครอบคลุมทุกบรรทัดของ source code)
Gray-box testing
การทดสอบแบบ Gray-box จะเป็นการทดสอบที่ผสมกันระหว่าง Black-box และ White-box นั่นคือเราจะได้ข้อมูลมากกว่า Black-box เช่น Network diagram, Software Architecture และอื่นๆ แต่จะไม่เห็น source code เหมือนกัน White-box ซึ่งการทดสอบแบบ Gray-box จะเปิดเผยอะไรบ้างขึ่นอยู่กับการตกลงกันของผู้รับจ้างและผู้จ้าง
Functional tests vs Non-Functional tests
การทดสอบ Software นั้นเราจะแบ่งออกเป็น 2 กลุ่มหลักๆคือ
- Functional tests ที่สนใจการทำงานของระบบเป็นหลัก จะเน้นที่การทำงานได้ของระบบ ซึ่งเราจะมองใน 2 มิติ
- Verification การทดสอบว่าระบบนั้นสามารถใช้งานได้จริงหรือไม่
- Validation การทดสอบว่าระบบนั้นได้ตอบโจทย์ของ Business หรือ Requirements ที่เราให้ไปตั้งปแต่ต้นหรือไม่
- Non-functional tests เป็นการทดสอบเพื่อให้แน่ใจว่าระบบนั้นมีคุณภาพที่เพียงพอ เช่น
- Load test ทดสอบว่าเมื่อนำระบบนี้ไปใช้งานจริงจะสามารถรองรับความต้องการของ User ที่เราคาดว่าจะเข้ามาใช้ระบบได้ (เมื่อนำขึ้นไปใช้งานจริงจะไม่ล่ม ไม่ down นั่นเอง)
- Security Testing ทดสอบว่าระบบนั้นมีความปลอดภัยมากเพียงพอ และข้อมูลที่อยู่ในระบบนั้นมีความปลอดภัย ไม่สามารถถูกเจาะได้ง่ายๆ
Test Pyramid
Testing pyramid คือการเปรียบเทียบปริมาณของ Testing ในกลุ่มต่างๆ ซึ่งจะแบ่งออกเป็น 3 กลุ่มหลักๆคือ
- Unit Testing เป็นการทดสอบที่สนใจเฉพาะการทำงานของ Code ที่เราเขียนว่าถูกต้องหรือไม่ โดยที่จะไม่เชื่อมต่อกับส่วนอื่นๆเลย ไม่ว่าจะเป็นการติดต่อกับ Mail server หรือ Database
- Service-level tests หรือ Integration Test เน้นที่การเชื่อมต่อทั้งกับ database และระบบอื่นๆที่เราต้องเข้าไปคุยด้วย แต่ใน Layer นี้ก็อาจยังไม่ได้สนใจการทำงานจริงๆทั้งระบบ(Workflow) ดังนั้นการทดสอบใน layer นี้จะยังไม่ได้เชื่อมต่อกับ Ingrastructure พื้นฐานเช่น การส่ง Mail ผ่าน Mail server จริง หรือเชื่อมต่อกับระบบภายนอก(Third-party)
- UI Tests หรือ End-to-End Tests เป็นการทดสอบโดยจำลองการทำงานจริง ใน layer นี้จะ focus ที่ระบบใช้งานได้จริง ทดสอบกับ workflow การทำงานจริงๆ
Test pyramid สำหรับการพัฒนาซอฟต์แวร์
ซึ่งทั้ง 3 กลุ่มนี้ทั้ง Tester และ Developer จะต้องให้น้ำหนักในการทำงานให้เป็นไปตามรูปนี้คือให้ความสำคัญกับ Unit test มากๆ เพราะคุณใช้วัตถุดิบที่มีคุณภาพมาปรุงอาหาร อาหารนั้นก็จะมีคุณภาพตามไปด้วย ส่วน UI testing หรือ End-to-End testing ก็จะให้ความสำคัญน้อยที่สุดเพราะ UI และ Workflow สามารถเปลี่ยนแปลงได้ตลอดเวลา(sensitive) ดังนั้นเมื่อเกิดการเปลี่ยนแปลงจะต้อง test ซ้ำใหม่เสมอ(regression test) เราเลยจะให้นำ้หนักกับ layer นี้น้อยที่สุด
Microservices Testing
การทดสอบบน Microservices นั้่นจะแตกต่างจากการทดสอบบบน Monolith เพราะใน Microservices จะมี communication ระหว่าง services เยอะมากๆดังนั้นปริมาณของการทดสอบจึงไปอยู่ในส่วนของ Integration Testing เป็นหลัก ดังนั้น shape ของการทดสอบจะเปลี่ยนจาก Pyramid shape กลายเป็น Honeycomb shape ดังรูป
