สรุปบทที่ 1 เรื่อง The Testing Pyramid จากหนังสือ The Way of the Web Tester

ในบทที่ 1 ของหนังสือ The Way of the Web Tester นั้นจะพูดถึง Testing Pyramid ว่ามีส่วนประกอบของอะไรบ้างในพีระมิด แต่ละส่วนประกอบมีการทำงานยังไง แต่ละส่วนใครเป็นคนเกี่ยวข้อง และผลเป็นอย่างไร

Testing Pyramid

ส่วนบนสุดของพีระมิดคือ UI Tests หรือที่เรียกอีกอย่างนึงว่า User Interface Tests ส่วนนี้เป็นส่วนในการ test แบบ end-to-end หรือพูดกันง่ายๆ คือการ test แบบ user ใช้งานจริงๆ

ส่วนต่อมาเป็นส่วนกลางของพีระมิดคือ Integration Tests ในส่วนนี้จะแสดงภาพรวมของระบบ และมี Service เพื่อใช้ในการเชื่อมต่อ Function

ส่วนล่างสุดคือ Unit Tests เป็นส่วนที่เล็กที่สุด มีความเร็วและแรงในการ test ในส่วนนี้จะเป็นการทดสอบของ developers


UI Tests

เป็นการรวมทุก Layers ของระบบ โดยการ Test ของส่วนนี้จะมีการ Test ที่ช้าและมีความอ่อนแอ เพราะการ Test ในส่วนของ UI ต้องใช้เวลานานเพราะมีขนาดที่ใหญ่ และหากพบ Bug จะทำการตรวจสอบได้ยาก ในส่วนนี้จึงเป็นส่วนที่อยู่บนสุดของพีระมิดเพราะมันคือการตรวจสอบที่เหมือนกับการใช้งานจริงทุกส่วนของระบบ

Integration Tests

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

Unit Tests

ในส่วนของ Unit จะมีความแม่นยำ ความเร็วในการ test สูงมาก ในส่วนนี้ Developers จะเป็นคนทำซะส่วนใหญ่ เนื่องจากในส่วน Unit tests อาจจะเกิด bug ที่ซ่อนในตอนที่เราเข้าสู่ Integration ได้จึงเป็นข้อเสียในส่วนนี้


Rules of Thumb

ในส่วนนี้จะเป็นการบอกว่าการ test เราควรทำจากข้างล่างขึ้นไปข้างบน ไม่มีโปรเจคไหนที่ทำ UI ได้โดยปราศจาก Unit และ Integration ในส่วนล่างสุดจะมีความเร็วและมีราคาที่ถูก ต่างจากด้านบนจะมีความช้าและมีราคาที่สูง

ข้อคิดในหัวข้อนี้บอกว่า “เมื่อไหร่ที่มี test เข้ามาใหม่เราควรมองที่ Unit Test ก่อน” “อย่าพยายามที่จะใช้ Automate Test อยู่ตลอดเวลา ใช้ตามความเหมาะสม”


ข้อแตกต่างระหว่าง Unit Tests และ UI Tests


การทำงานของ Developers และ QA

ต้อง Test ทุกอย่าง ?

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

มุมมองของแต่ละฝ่าย

มุมมองของแต่ละฝ่ายจะแตกต่างกัน มุมมอง dev ก็จะบอกว่ายิ่งไวสิยิ่งดี เราทำทุกอย่างเสร็จแล้วนะของ Unit แต่มุมมอง QA จะบอกว่าต้อง test ทุกอย่างนะถึงจะถูก Unit คืออะไร เราสามารถ Automate Test ได้ทุกอย่างของ UI ซึ่งดูจากภาพต่างฝ่ายต่างมองในมุมมองของตัวเอง เราจึงต้องมาหาข้อตกลงระหว่างกัน ซึ่ง QA ก็ต้องมองในมุมมอง dev ด้วย dev ก็ต้องมองในมุมมอง QA ด้วย แล้วจะส่งผลไปในทางที่ดีของ product ของเรานั่นเอง


เพิ่มเติมสักเล็กน้อย

มีส่วนหนึ่งในหนังสือเรื่องนี้ที่สำคัญได้บอกว่า “อย่าลืมที่จะลองการ Test แบบ Exploratory Test” ทั้งหมดเราอาจจะมีการเขียนสคลิปต์ทั้ง Test แบบ Manual และ Automate แต่อย่าลืมที่จะลอง test หรือใช้งานไปเรื่อยๆ มั่วๆ แบบไม่มีสคริปต์ แบบไม่มีแบบแผนไว้ ลองทำแบบมั่วๆ บางทีการทำอะไรนอกกรอบอาจจะทำให้เจอ bug ที่เราคาดไม่ถึงก็ได้

Reference : https://pragprog.com/book/jrtest/the-way-of-the-web-tester