Frontend / Backend / End to End Testing นั้นหรือคืออะไร
ยิง API ถือเป็นการ test ประเภทไหน? ถ้า test Frontend ก็ไม่ต้องมี skill ยิง api รึเปล่า? หรือถ้ายิง API ก็เรียกว่าเป็นการ test backend แล้วใช่มั๊ย? แล้วถ้า test ผ่าน UI อย่างเดียวจะเรียกว่า End to End Test ได้รึเปล่า?
คำถามเหล่านี้เป็นสิ่งที่เห็นมากขึ้นในช่วงหลังๆ แล้วก็รู้สึกว่าบางทีทั้งคำถามและคำตอบที่ได้เห็นยึดติดกับนิยามไปหน่อยเลยเป็นแรงจูงใจให้เขียน Blog นี้ขึ้นมา สำหรับ blog นี้ก็เหมือนเดิมไม่มีตำราหรือหนังสือใดๆมาอ้างอิง แต่จะพยายามอธิบายให้เห็นภาพว่าการ test แต่ละประเภทคืออะไร ควร focus อะไรเป็นหลักบ้างในชีวิตจริงแบบไม่อิงทฤษฎีมากนักแล้วกันนะครับ
เริ่มจากนิยามเบื้องต้นก่อนนะ
Frontend testing คือการ test ส่วนที่ interaction กับ user ของระบบ หลักๆก็คือ UI/GUI (สมัยนี้ส่วนใหญ๋ก็คือ GUI หล่ะนะ ไม่ค่อยมี text base application แล้ว) คือการเช็คความถูกต้องของ function ต่างๆบน GUI รวมถึงความถูกต้องต่างๆของการแสดงผล รวมถึงอาจจะมีการเช็ค logic บางส่วนที่ฝังอยู่ที่ Frontend layer ด้วย (ควรจะ lightweight และน้อย เดี๋ยวยกตัวอย่างให้เห็นในช่วงถัดไปนะครับ)
Backend testing คือการ test ส่วนที่เป็น server side logic ต่างๆ และ database test (deadlock, dataloss, race condition ต่างๆ) แต่เอาจริงๆแล้ว ถ้าเป็น application ที่ไม่ได้ scale ที่รองรับข้อมูลเยอะๆเร็วๆที่มี transaction เยอะๆ การ test specific database related backend ก็จะมีความจำเป็นต้องทำน้อยหน่อย เท่าที่เห็นสมัยนี้ส่วนใหญ่ (ในไทย) จะได้ทำในส่วนของการเช็ค business logic ใน backend testing กันซะมากกว่า เราก็จะพูดถึง database specific กันน้อยหน่อยนะครับในบทความนี้ แต่ถ้า application ใครทำอะไรทีเกี่ยวกับ transaction เยอะๆ ด้วย speed สูงๆก็ต้องไปศึกษากับไปทำเรื่อง database testing (ซึ่งเป็นส่วนหนึ่งของการทำ Backend testing) กันเพิ่มด้วยเน้อ
End to End testing (E2E) คือการเช็คว่าทุกๆ compoent หรือ system ย่อยในระบบของเราทำงานร่วมกันได้ดี สิ่งที่ focus คือ customer experience / customer journey ในชีวิตจริงเป็นหลัก (คือไม่ต้องเลือกท่ายากต่างๆ หรือ scenario ที่เป็นไปได้แต่โอกาสเกิดขึ้นจริงน้อยมาอยู่ใน E2E มากนัก) และที่สำคัญคือ เช็คตั้งแต่ต้นจนจบ flow เดี๋ยวไว้ไปดูตัวอย่างเพิ่มเติมกันตอนท้ายนะครับ
ลำดับถัดมาขอใช้รูป (ที่วาดขึ้นมาเอง) นี้เป็นตัวช่วยในการเล่าเรื่องอธิบายในแต่ละส่วนเพิ่มละกันนะครับ ตัวระบบขอตั้งชื่อว่า Doppee ละกันเป็น e-commerce mobile application เอาไว้ใช้ shopping online
Frontend Testing
จากในรูป ขอเริ่มจากตัว Doppee mobile application ที่อยู่ในโทรศัพท์ของ customer ก่อนละกัน ถ้าในมุมของ Frontend คือเช็คว่า การ navigate ของปุ่มและหน้าต่างๆ ทำงานได้ปกติมั๊ย Layout ต่างๆ สีต่างๆ text font ถูกต้องตาม design มั๊ย นอกจากนี้การ display text ด้วยภาษาต่างๆ (ในกรณี support multi language) ไม่ได้ทำให้ layout พัง (ปกติแล้วบางภาษา บางคำถูกแปลออกมาแล้ว text ยาวล้นปุ่ม อะไรแบบนี้) นอกจากนี้ยังต้องมีการ test กับ device (หรือ browser ถ้าเป็น web) ประเภทต่างๆ และ size ต่างๆ เช็ค responsive design กับ size ต่างๆ ของการแสดงผลว่าปกติมั๊ย สวยงามมั๊ย หรือนอกจากความสวยงาม บางที (โดยเฉพาะกับรุ่นของมือถือแปลกๆหน่อย) ปุ่มบางปุ่ม หรือ text box บางอันกับมือถือบางรุ่นอาจจะใช้ไม่ได้ อันนี้คือการ check device/platform compatibility testing ซึ่งเป็นสิ่งที่ Frontend QA ต้อง consider มาทำด้วยนะครับ
ทีนี้ นอกจากการเช็ค GUI และความสวยงามต่างๆแล้ว สิ่งสำคัญที่ Frontend QA ต้องเช็คอีกอย่างคือการแสดงผลของข้อมูล ว่าตัว Frontend มีการนำข้อมูลจาก Backend มาแสดงผลได้ถูกต้องหรือไม่ ตัวอย่างเช่นรูปด้านล่าง
ถ้าเราเห็นหน้าจอ mobile app แสดงราคาขายของน้ำปลาแบบนี้ การ test Frontend จริงๆ ไม่ใช่แค่ดูว่า layout display สวยงามแล้วจบ เราควรตรวจสอบด้วยว่า ข้อมูลต่างๆ ตัวเลข และแม้แต่ชื่อ promotion (“ส่วนลดลูกค้า VIP”) ที่แสดงอยู่นั้นเป็นข้อมูลที่ได้มาจากหลังบ้านอย่างถูกต้อง วิธีเช็คที่แนะนำคือการไปเช็คข้อมูลจากตัวที่ ส่งต่อหรือเชื่อมต่อข้อมูลตรงให้ Product under test (ตัวอย่างนี้ product under test = mobile application) ซึ่งจากรูปนี้คือ ตัวที่ส่งข้อมูลให้ Mobile application คือ Mobile API Server
จากในรูปด้านบน เราก็ไปยิง API เพื่อเช็คว่า customer คนนี้ควรจะเห็นราคาน้ำปลาเป็นเท่าไหร่บ้าง (ราคาตั้งต้น / ราคาพิเศษ /ส่วนลดลูกค้า VIP / ราคาขายสุดท้าย) ข้อมูลที่ได้มาจากการยิง API ตรงกับ ที่เราเห็น Display ที่หน้า mobile application มั๊ย
การยิง API ไม่เท่ากับการ test Backend นะ! มีหลายๆคนหลงคิดแบบนี้ ว่างานของผมมีการใช้ postman ยิง API นะ ดังนั้นงานผม test ทั้ง Frontend และ Backend ซึ่งอันนี้เป็นความคิดที่ผิด (หรือส่วนใหญ่จะผิด)
จากตัวอย่างนี้มีการยิง API โดยใช้ Postman tool เป็นตัวยิง API ละกัน แต่เป็นการใช้ Postman ยิง API เพื่อการ test Frontend นะ คือเราใช้ Postman เป็น tool เพื่อดึง data มาใช้ validate ว่าสิ่งที่ display ที่ Frontend มันถูกต้องมั๊ย โดยที่เรายังไม่ได้สนใจเช็คเลยด้วยซ้ำว่า ตัวเลข 50, 30, 10, 20 ที่ได้ออกมาเนี่ย มันถูกต้องมั๊ย (เดี๋ยวตรงนี้ไปอธิบายใน Backend testing ต่อให้นะครับ)
ตัวอย่างเพิ่มเติม สมมติถ้าพูดถึงกรณีการ Test login function ของ Frontend สิ่งที่เราต้องเช็คคือการ Display ต่างๆ ตัวอย่างเช่น ถ้า login success มันต้องแสดงผลยังไง เช่นตัวตุ๊กตุ่นรูปคนบนมุมขวาต้องเปลี่ยนเป็นสีเขียว แล้วก็ต้องมีชื่อ user มา display ใต้ตัวตุ๊กตุ่นนั้น และ point คะแนนสะสมของ user มาโชว์ด้วย อะไรแบบนี้ ส่วนถ้า login ไม่ success ต้องโชว์ error message ด้วย layout แบบไหน ซึ่งเราก็ต้องยิง api เพื่อสุ่มเช็คว่า Frontend เอา error message/text ที่ได้จาก API (Backend) มาโชว์ถูกต้องนะ คือได้ text อะไรมา ก็เอามาโชว์ใน layout ที่วางไว้ได้ถูกต้อง
ทีนี้สมมติมีการ login fail ได้ 20 scenarios ด้วย 20 error messages ที่แตกต่างกัน การไปเช็คว่า login fail แบบต่างๆ แล้วได้ error message 20 แบบถูกต้องมั๊ยเนี่ย ไป test ใน level Backend ได้นะครับ (ไปยิง API test เอา แทนที่จะ test ทุก scenario บน Frontend UI — การ test logic พวกนี้จาก backend api ง่ายกว่าเยอะ)
เสริมอีกหน่อย บาง application หรือ บาง web มันอาจจะมี business logic บางอย่างแอบฝังอยู่ใน Frontend นะ ยกตัวอย่างง่ายๆเช่น simple validation ของ text box ต่างๆ เช่นถ้าเป็นช่องใส่ email ต้องมีการดักว่าต้องมี @ อยู่ในนั้นไม่อย่างงั้น Frontend logic จะ show error บอกลูกค้าเลยโดยไม่ส่งข้อมูล email นี้ไปเช็คที่ Backend ด้วยซ้ำ โดยการที่เราจะเข้าใจว่า logic ไหนอยู่ที่ Frontend บ้าง เราต้องพยายามคุยกับ team developer แล้วมา test Frontend logic พวกนี้ด้วยนะครับว่าทำงานถูกต้องมั๊ย อีกตัวอย่างคือ บาง web/app เอา business logic บางอย่างมาใส่ (หรือยัด) ลงใน Frontend เช่น อย่างตัวอย่างการขายน้ำปลาด้านบน บาง app อาจจะไม่ส่งราคาขายสุดท้ายมา แต่ไปเขียน logic ในตัว Frontend ว่า เอาราคาพิเศษ (30 บาท) มาลบ ส่วนลด (10 บาท) แล้วแสดงผลราคาขายให้ลูกค้าเห็นหน่อย ซึ่งในกรณีนี้ ถ้าเราไปยิง postman เราก็จะไม่ได้ราคาขาย 20 บาทสุดท้ายออกมานะ ถ้าเรารู้ว่า logic อยู่ที่ Frontend แบบนี้เราก็ต้อง test logic ส่วนนี้ใน level Frontend testing ด้วยนะครับ (ถ้าถามว่าการเอา business logic พวกนี้มาใส่ใน Frontend ควรมั๊ย ส่วนใหญ่ก็ไม่ควรหรอก แต่ในชีวิตจริงมันมีอะไรแบบนี้แน่ๆ)
เสริมสุดท้าย มีอีกสิ่งนึงที่หลายๆคนสับสน ว่าตัวเอง Test โปรดัคหลังบ้าน หรือ Back office product เรียกว่าเป็น Backend testing รึเปล่า จากตัวอย่างนี้ขอยกตัว Order management Back office website มาแล้วกันนะครับ คือเป็น Product website ที่เรียกว่าเป็น Back office ตัวนึงที่ customer support ทีมเป็นคนใช้งาน ไม่ใช่ customer facing product แต่การ Test website ตัวเนี๊ย เรียกว่าเป็น Frontend testing ได้นะครับ แต่ส่วนใหญ่ก็จะแอบทำเป็น End to End หรือ validate backend logic ผ่าน Web นี้กันไปเลยก็มี แต่ก็นั่นแหล่ะ สิ่งที่อยากจะบอกคือ การ test Back office ไม่เท่ากับ การ test Backend นะจ๊ะ
Backend Testing
มาต่อกันที่ฝั่ง Backend กันบ้าง นอกจากการทำ contract testing ที่เช็ค interface การเชื่อมต่อกันระหว่าง API ต่างๆแล้ว การ test Backend ส่วนใหญ่คือเช็ค Business logic ต่างๆ เช่นถ้า Product under test ของเราคือ Search API แล้ว Business logic ตาม requirement คือ จะ Return Product นั้นไปใน search result ได้คือ ต้องมี
- Product detail ต้องมีข้อมูลครบและมี status เป็น Active product
- มีสินค้าใน Stock API ≥ 1 ชิ้น
- ต้องมีราคาขั้นต่ำ ≥ 15 บาท
- Promotion จะมีหรือไม่มีก็ได้ แต่ถ้ามี Promotion ที่ apply กับ product นี้มากกว่า 1 Promotion ตัว Search API จะเลือก Promotion ที่มีส่วนลดมากที่สุด และต้องทำให้ราคาหลังส่วนลด promotion ≥ 15 บาทถึงจะเอา promotion มา apply ได้
การ test Backend สำหรับ requirement นี้คือการใช้ testing technique ออกแบบการตรวจสอบตาม condition ต่างๆของ business logic นี้โดย อาจจะต้องใช้ tool หรือ skill ต่างๆในการ update database (เพื่อ set test data / condition ต่างๆตาม test scenario ของเรา) หรือยิง API เพื่อเช็คหรือ set ค่าที่ API ย่อยต่างๆ เช่น Product detail api, Stock api, etc เพื่อ get data เอามาเทียบกับ result ที่เราได้จาก Search API ที่เป็น Product under test ของเรา
โดยจะเห็นว่าในระบบ Doppee เราสามารถมี Product under test ของ Backend ได้หลายตัว พวก Product detail API ก็สามารถเป็น product under test ตัวนึงได้ เพราะตัวมันเองก็จะมี Business logic ของมันที่เราควรจะไปตรวจสอบ
บางที (หรือส่วนใหญ่ที่เกิดขึ้นในชีวิตจริง) QA จะทำการ test Backend logic ผ่าน Frontend GUI เช่น แทนที่จะไปยิง postman api ที่ Search API ก็ไปทำการ search ผ่านหน้า web / app ที่ลูกค้าใช้เลย
ถามว่าได้มั๊ยก็พอได้แหล่ะ เหมาะมั๊ยก็ต้องตอบว่าไม่ได้เป็นวิธีที่ดี เพราะช้าและ test ยากกว่ายิง api เยอะ เช่นถ้ามี business logic ต้องเช็ค 20 ข้อ ต้องไป login ผ่านหน้า ui, ต้องไปพิมพ์ search criteria ต่างๆผ่าน text box บน ui ต้องรอการแสดงผลแล้วไปกวาดสายตาหาและตรวจสอบความถูกต้องต่างๆบนหน้า ui ซึ่งถ้าจะเอาการ test ส่วนนี้ไปทำ test automation ก็ยิ่งช้าและมีโอกาสเจอ test flakiness เยอะกว่าการทำ test ใน level backend api เยอะ แต่อย่างที่บอกครับ ในชีวิตจริงบางทีเราก็จำเป็นต้องทำ test แบบนี้ จุดสำคัญคือเราต้องรู้ว่าเราจะ test อะไร (Frontend or Backend) ถ้าเรา test Backend logic แล้วเราจะใช้ web/app เป็น tool ในการ test (ยากกว่า ช้ากว่า) แทนการใช้ postman/api ก็ทำได้แต่การ test เราต้องอย่าลืม focus กับ business logic validation แทน layout และการแสดงผลแค่นั้นเอง
สิ่งที่ต้องระวังอีกอย่างคือ ถ้าเราใช้ component ที่ไม่ได้เชื่อมต่อหรือรับข้อมูลตรงมาเป็น Tool ในการเช็ค Product under test ของเรา (เช่นการใช้ mobile app มาเพื่อ เป็น tool ในการ test Search api) เราอาจจะเจอบั๊ก ที่ไม่ได้เป็นของตัว search api เองได้
เช่น ถ้าเรา expect ราคาตั้งต้น 30 บาทจาก Search API (ตาม test scenario / test data ที่เรากำหนดไว้) แต่หน้า App show 40 บาท ทีนี้เราจะไม่รู้หล่ะว่า บั๊กอยู่ที่ Search API หรือ Mobile API หรืออยู่ที่ตัว mobile application คือเรารู้ว่ามี bug ในระบบ (ซักที่) แต่กลายเป็นต้องมานั่งไล่ยิง API เช็คทีละจุดอยู่ดีว่า bug อยู่ที่ตรงไหนกันแน่
ตรงนี้แอบสำคัญนะครับ คือการมี bug ในระบบ ไม่เท่ากับการมี bug ในProduct under test ของเรา ในถ้าระบบใหญ่ๆ ปกติการ develop, การ test และ release จะทำแยก component กัน ดังนั้นถ้าเราแยกได้ว่า bug อยู่ที่ตรงไหน จะทำให้เราไม่ต้อง block การ release ของ component ต่างๆโดยไม่จำเป็น คือ bug อยู่ตรงไหนก็ไป raise bug และแก้ให้ถูก component และ sign off / release component ที่ไม่มีปัญหาขึ้น production ไปก่อนได้ (อาจจะ disable feature ไว้ก่อนได้ เพราะทั้งระบบ feature นี้ยังมีปัญหาอยู่ จนกว่า compoent ที่มี bug จะถูกแก้)
ในส่วนของ Backend testing นอกจาก Functional test ที่เช็คพวก business logic แล้วการทำ Non-functional test ต่างๆ โดยเฉพาะพวก load test / stress test ก็สำคัญนะครับ (ขึ้นอยู่กับระบบ การใช้งานและความจำเป็น) ดังนั้นถ้าใครมาสาย Backend testing ศึกษาและฝึกทำพวก performance test ไว้ด้วยก็ดีครับ
End to End Test (E2E)
มาส่วนสุดท้าย End to End testing สั้นๆนะครับ มันคือการเช็ค End-to-End user journey รวมถึงการ ไหล flow ไป component หลังบ้านต่างๆ รวมถึงการทำงานร่วมกับ 3rd Party ต่างๆด้วย
โดยสิ่งที่สำคัญของ End to End Testing คือเราจะเลือกมาเฉพาะ scenario ที่ represent การใช้งานจริงของลูกค้า หรือ scenario ที่มีโอกาสเจอเยอะๆบน production นะครับ โดย goal ของ E2E test ไม่ใช่การ test ทุก functions/scenarios ที่เป็นไปได้ แต่เน้น test flow ที่สำคัญและเป็น flow ที่เราไม่อยากพลาด
เช่นการเข้ามา search และ ซื้อของ (ด้วย สินค้าประเภทยอดนิยม) ด้วย promotion (ยอดนิยม) ด้วยวิธีการจ่ายเงิน (ยอดนิยม เช่นผ่านบัตรเครดิต) โดยการทำ E2E test ไม่ได้จบแค่ ลูกค้าซื้อของได้สำเร็จ แต่จะเช็คไปถึงระบบหลังบ้านต่างๆด้วยเช่น Order นี้ไปตัดเงินกับ Payment gateway ที่เป็น 3rd Party ได้มั๊ย, Order นี้ไหลเข้าไปสู่ระบบ Logistic เพื่อทำการส่งของให้ลูกค้าได้มั๊ย (รวมถึง flow การ Pick/Pack สินค้าด้วย) รวมถึง Order นี้ไหลเข้าไป show ในระบบ Customer service back office เพื่อให้ Customer service agent สามารถเรียกดูและจัดการ order ในกรณีที่ลูกค้าติดต่อมาขอความช่วยเหลือได้มั๊ย และสุดท้าย ข้อมูลของ Order นี้ไหลเข้าไประบบ Finance ได้มั๊ย สามารถออกใบกำกับภาษี แยก data ทางการเงินและอื่นๆออกมาแล้วไหลเข้าระบบ BI ได้ถูกต้องมั๊ย (อันนี้คือ E2E จริงๆระดับนึงนะ)
การเลือกว่า เราจะ End to End test ไปถึงแค่ไหน ไหลไปแค่ส่งสินค้าให้ลูกค้า หรือไปถึงระบบ BI เราเลือกได้และเลือกเองนะครับ ว่าจะไปไกลถึงแค่ไหนถึงจะ make sense สำหรับระบบของเรา แล้วก็ถ้าทำ E2E มันก็จะไม่มี product under test หล่ะ แต่จะเป็นการมองในมุม System under test แทน บางคนจะมองว่าเป็น System and Integration test ประเภทหนึ่งก็ไม่ผิด แต่หลักสำคัญของ End to End ก็คือ Normal User journey flow / experience (ไม่ใช่เทสมันทุกอย่าง) นั่นเอง
จบแล้วสำหรับ Blog ย๊าวยาว อาจจะอ่านยากนิดนึงนะครับสำหรับบทความนี้ เพราะพยายามไล่ตัวอย่างให้เห็นภาพ รวมถึงแทรกเนื้อหาอื่นๆมาเล็กๆน้อยๆอย่างเช่นพวกการแบ่ง Test level ต่างๆนาๆ หวังว่าจะทำให้พอเห็นภาพได้บ้างนะครับ อย่างที่บอกไว้ตอนแรก บทความอาจจะไม่ได้ถูกต้องตามทฤษฎี 100% แต่เน้นสิ่งที่ QA ส่วนใหญ่จะเจอและได้ใช้งานกันจริงๆซะมากกว่า ผิดพลาดประการใดขออภัยมา ณ ที่นี้ด้วยครับ
Doppio Tech — We Build And Serve Expertise
