ในปัจจุบันแนวคิดเรื่อง Software Testing นั้นถูกอธิบายด้วยรูปภาพหลายรูปแบบ
โดยรูปที่สามารถพบเห็นได้บ่อยๆ ประกอบไปด้วย
Pyramid, Ice-cream cone และ Capcake
ซึ่งหลายๆ คนอาจจะไม่รู้ว่าแต่ละรูปมันหมายความว่าอย่างไร
ดังนั้น เรามาดูกันว่ามันหมายถึงอะไรกันแน่
เริ่มด้วยการอธิบายรูปแบบ Ice-cream cone
เป็นรูปแบบการพัฒนาแบบเก่า ( traditional development ) ซึ่งจะพบว่า
ในส่วนของ unit test และ integrate test นั้นจะมีน้อยมากๆ
เนื่องจาก developer ไม่ได้เห็นคุณค่าหรือไม่รู้จัก
หรืออาจจะบอกว่า ไม่มีเวลา และงานมันเพิ่ม
ส่วน UI test จะมีมากขึ้น เนื่องจากมีเครื่องมือสำหรับการทดสอบระบบ
และทำการทดสอบแบบอัตโนมัติ
แต่ทำการทดสอบหลังจากพัฒนาเสร็จแล้ว
ทำให้ไม่ได้ป้องกันหรือช่วยลดจำนวน bug ที่เกิดขึ้นเลย
ส่วน Manual test นั้นจะเป็นส่วนการทดสอบหลัก
ซึ่งมีจำนวนการทดสอบที่มาก และใช้ค่าใช้จ่ายที่สูงมากเช่นกัน
ในปัจจุบันยังนิยมทำการทดสอบ software ในรูปแบบนี้อยู่อย่างมาก ดังรูป
ต่อมาคือ Testing Pyramid
ในปัจจุบันแนวคิดเรื่องการทดสอบเริ่มเป็นที่รู้จักและได้รับความนิยมมากขึ้น
ตั้งแต่ส่วนของ developer ที่พัฒนาตามแนวคิด Test-Driven Development ( TDD )
นำมาประยุกต์ใช้กับ component test, integration test
รวมไปถึง Acceptance test ซึ่งทั้งหมดนั้นทำงานแบบอัตโนมัติ
พัฒนาโดยทีมเดียวกันหรือไม่มีแยกออกไปทำที่ทีมอื่นๆ มากนัก
ส่งผลให้แต่ละส่วนการทำงานมีคุณภาพมากขึ้น และง่ายต่อการดูแลรักษาระบบ
หรือพูดได้ว่า ได้ใส่คุณภาพไปในทุกๆ ส่วนนั้นเอง
ส่วนการทดสอบแบบ manual ก็ยังคงมี แต่ลดจำนวนลงไปเท่านั้นเอง
เน้นทดสอบในส่วนที่สำคัญๆ แทนที่จะทดสอบทั้งหมด
ซึ่งเป็นแนวทางที่ได้รับความนิยมขึ้นมา ดังรูป
Testing Capcake
ที่มา Introduction the software testing Cupcake จากบริษัท Thoughtworks
รูปแบบนี้เกิดมาจากความนิยมในการเขียน test แบบอัตโนมัติในทุกๆ ชั้น
ของระบบงาน ทำให้แต่ละส่วนหรือทีม ทำการสร้าง test ขึ้นมาเยอะ
แต่ว่ามันเยอะจนเกินไป ทำให้เกิดปัญหาขึ้นมา …
เป็นหลุมพลางที่น่ากลัวอย่างหนึ่งเช่นกัน
รูปแบบของทีมที่กำลังตกหลุมพลาง จะมีลักษณะดังต่อไปนี้
- แยกทีมเขียน test ในแต่ละระดับ
- หรือมี 3 ทีมแยกเขียน test กันชัดเจนคือ
- Developer ทำการเขียน unit test, integration test และ component test
- ทีมอื่นๆ เขียน UI test สำหรับทดสอบแบบ black box
- กลุ่ม Manual tester มี scenario สำหรับการทดสอบแบบ manual
- โดยทั่วไปแต่ละทีมจะทำงานแยกกันอย่างชัดเจน ไม่ค่อยทำงานร่วมกันมากนัก
- การทำงานเป็นแบบเรียงต่อกัน เหมือนกับ Waterfall คือ เริ่มที่ develpoer ทำการเขียน code และ test ต่อจากนั้นจึงเริ่มทำการทดสอบแบบ manual ตามมาด้วยทดสอบผ่าน UI
- ทั้งสามทีมไม่มีข้อตกลงร่วมกันในการทดสอบชนิดต่างๆ ทำให้ผลการทดสอบซ้ำซ้อนกันในหลายๆ ส่วน
จากลักษณะข้างต้นทำให้เกิดสิ่งที่เรียกว่า Cupcake ดังรูป
จากปัญหานี้เราสามารถแก้ไขเพื่อปรับให้อยู่ในรูปแบบของ Test Pyramid
ด้วยวิธีต่อไปนี้
- การทำงานร่วมกันของแต่ละทีม ไม่ทำงานแบบต่อกัน หรือ mini-waterfall แต่มาทำงานด้วยกัน เพื่อให้ไปทางเดียวกัน
- ทำการ pair กันระหว่าง developer และ tester
- เริ่มทำการทดสอบในระดับที่ต่ำสุดเท่าที่เป็นไปได้ก่อนเสมอ
- ถ้าสามารถรวมเป็นทีมเดียวกันได้ จะดีมากๆ
- มีเป้าหมายร่วมกัน
โดยรวมๆ แล้วมันคือการทำงานร่วมกันในทุกๆ ส่วนนั่นเอง ดังรูป
จากทั้งสามรูปนั้น สามารถอธิบายแต่ละชั้นของการทดสอบได้ดังนี้
โดยการทดสอบด้านบน เช่น Manual Test, Automated UI Test นั้น
คือส่วนที่ใช้ตรวจสอบว่า product ที่สร้างขึ้นมามันใช่ตามที่ต้องการหรือไม่ ( Build the right thing )
ส่วนส่วนการทดสอบชั้นล่างลงมา เช่น Automated APIs Test, Integration Test
Component Test และ Unit Test นั้น เป็นการทดสอบว่า เราทำการสร้าง product ( Build the thing right )
ด้วยวิธีการที่ถูกต้องหรือไม่ ซึ่งจะช่วยในเรื่องการดูแลรักษาระบบงาน
ที่สำคัญจะต้องพยายามสร้างการทดสอบแบบอัตโนมัติขึ้นมาให้มากที่สุดเท่าที่จะเป็นได้
แต่ไม่ใช่ให้ทำงานแบบอัตโนมัติทุกสิ่งที่ทุกอย่างนะ …
และอย่าไปยึดติดกับการทดสอบผ่าน UI มากนัก
แนะนำให้ลดการทดสอบระดับบนๆ ลงไป แล้วเพิ่มการทดสอบในระดับล่างๆ แทน
สามารถอธิบายได้ดังรูปนี้
มาถึงตรงงนี้ น่าจะพอทำให้เห็นว่า ภาพแต่ละอย่างเขาใช้อธิบายเกี่ยวกับ Software Testing อย่างไร
ซึ่งมีทั้งดีและไม่ดี ดังนั้นลองมองย้อนกลับไปว่าทีมพัฒนาของเรานั้น เป็นรูปภาพไหนกันเอ่ย ???
Reference Websites
