Non-Functional Test นั้นหรือ คืออะไร (Non-Functional Test 101)
หลายๆคนคงเคยได้ยิน หรือผ่านหูผ่านตามากับคำว่า Non-Functional Test มาบ้าง แต่ยังสงสัยอยู่ว่ามันคืออะไร มันใช่ Performance Test รึเปล่า แล้ว Performance Test คืออะไร ลองมาอ่านบทความนี้กันครับจะได้เข้าใจมันกันมากขึ้น
เกริ่นนิดนึง ถ้าจะแบ่งกันตามหลักการแล้ว คำว่า Functional/Non-Functional test เนี่ยมันเป็นส่วนหนึ่งของ System Test นะ
จากรูปด้านบนจะเห็นว่า keyword ของ Functional Test คือคำว่า “What?” คือการ test เพื่อทดสอบในมุมที่ว่า ระบบทำอะไรได้บ้าง พูดง่ายๆคือในแง่ของ function/feature นั่นแหล่ะ ทีนี้มาถึงพระเอกของเราในบทความนี้กันบ้าง keyword ของ Non-Functional Test นั้นคือคำว่า “How well?” ที่แปลว่า ดีแค่ไหน พูดง่ายๆคือ function/feature ที่เรา test แล้วว่ามันทำงานได้เนี่ย มันทำงานได้ดีแค่ไหน
ตัวอย่างเช่น Feature A คือ ถ้ากดปุ่ม login แล้วตาม requirement (“What”) คือต้องมี popup window ขึ้นมาให้กรอก username กับ password — ทีนี้ QA ก็ test functional test ว่ากดปุ่มแล้วมันมี pop up window ขึ้นมาจริงๆ คือ functional test ผ่าน ทีนี้ปรากฎว่าพอมามองในมุม non-functional test ปุ๊บ ก็เจอว่า pop up windows นั้นขึ้นมาจริง แต่ปรากฎว่าใช้เวลา 10 วินาที กว่าจะโผล่ขึ้นมา แล้วก็ไป pop up อยู่มุมล่างซ้ายของหน้าจอ ดังนั้นในมุมของ How well? (ที่ว่าทำงานได้ ทำงานได้ดีแค่ไหน) นั้นก็จะไม่ผ่าน เพราะว่า ทำงานได้ช้า (response time — fail) และ ไม่สะดวกในแง่การใช้งานของ customer (usability — fail)
ทีนี้เรามาเจาะลึก Non-Functional Test กันบ้าง (ไม่ได้จะอธิบายละเอียดทุกอันนะ แต่เอาให้พอเห็นภาพ เห็น concept ว่ามันคืออะไร) หลักๆแบ่งเป็น 3 ประเภทย่อย
- Usability Test : ถ้าตามนิยาม (เรียกว่า หนึ่งในนิยามละกันนะ) มันคือ The suitability of the software for its USERS measuring effectiveness, efficiency and satisfaction แปลได้ว่า ความเหมาะสมของ software กับ คนใช้ของ software นั้นๆ เน้นคำว่าคนใช้ของ software นั้นๆนะ แบ่งเป็น 3 measurement ย่อย (ซึ่งอาจจะกำกวมบ้างและไป overlap กับ area อื่นบ้าง แต่ให้ถือเป็น guideline ที่เราจะนึกถึงไว้ก่อนละกัน) คือ
Effectiveness : Achievement of goals with accuracy & completeness ทำงานได้ครบและถูกต้องนั่นเอง (อันนี้แอบคล้ายๆกับ functional test เล็กๆ แต่อย่าลืมว่าให้คิดถึงผู้ใช้เป็นหลัก เช่น ถ้าระบบทำงานได้ แต่คนใช้เป็นคนพิการทางสายตา ก็ต้องดูว่าระบบเราทำให้ผู้ใช้สามารถใช้งานได้จนจบแบบ effective แค่ไหน-
Efficiency: Capability for users to use appropriate resource ตัวอย่างง่ายๆ เช่น ถ้าเราทำ software เครื่องคิดเลขแบบ simple ขึ้นมาอันนึง แต่ปรากฎว่า resource ขั้นต่ำของ software นี้คือ CPU i7, RAM 16 GB อะไรแบบนี้มันก็ไม่ make sense ในแง่ของ Usability (efficiency)
Satisfaction: Capability of product to satisfy users in a specified “context of use” สั้นๆคือ ทำให้ลูกค้าพึงใจได้มั๊ยภายใต้บริบทการใช้งานของลูกค้า คือต้องเข้าใจว่า software ตัวเดียวกันถูกใช้งานโดยลูกค้าต่างๆกันในบริบทต่างกันได้ เช่นลูกค้าที่ใช้งานผ่าน desktop version อาจจะโอเคกับการไปหน้าถัดไปโดยกดปุ่ม next ในขณะที่ลูกค้าที่ใช้งานผ่านมือถือ อาจจะอยากให้ scroll down ไปเรื่อยๆง่ายกว่า
นอกจากในตำราที่คำนึงถึงการใช้งานของลูกค้าเป็นหลักแล้ว ในส่วนของโลกปัจจุบันจากประสบการณ์ที่ทำมา บางที usability ต้องคำนึงถึงโอกาสทางเงินหรือกำไรที่จะเกิดขึ้นเพื่อบริษัทด้วย เช่น ถ้าทำ function อะไรซักอย่างให้ require จำนวน click เยอะก็จะไม่ค่อยดีเพราะลูกค้ามีโอกาสเปลี่ยนใจและ abandon web เราสูง ต้องลด process ลด data ที่ขอให้เหลือเท่าที่จำเป็นเพื่อให้เกิดจำนวน click เกิดการ type ข้อมูลของลูกค้าให้น้อยที่สุดก่อน complete order flow อะไรแบบนี้
วิธีทำ usability test นั้นมีหลากหลายแต่วิธีนึงที่ simple สุดคือการ สุ่มกลุ่มตัวอย่าง user ของระบบให้มาลองใช้งานจริง แล้วเรา observe ว่าลูกค้าจริง (ที่ไม่ได้รู้จักระบบ รู้วิธีใช้ระบบดีเท่า development team) มาเจอระบบแล้วเค้าจะใช้งานมันยังไงนั่นเอง แล้วก็ analyze หาวิธีที่จะปรับปรุงระบบให้ลูกค้าใช้งานระบบได้ง่ายขึ้นจากการ observe นั้นๆ
2. Reliability Testing มาถึงหัวข้อที่สอง ขอสั้นๆละกัน ตามนิยามคือ Reliability = The probability that software will not cause the failure of the system for a specified time under specified conditions คือการ test เพื่อหาความน่าเชื่อถือของ software นั่นเอง โดย keyword มีสองอันคือ Specified time (execute test นานเท่าไหร่) กับ Specified conditions (ระบุ condition ต่างๆเช่นปริมาณ user, load, test environment ต่างๆ) ยกตัวอย่าง goal ของ reliability test เช่น
<0.0001% transaction loss — run test with more than 1 million transaction over 3 days period of time
<1 minute downtime per week — run test under normal load for 4 weeks
Search feature return response <200 ms for 99% of search — run test with all keyword type for more than 1 millions search attempts
Concept ที่สำคัญของ Reliability Test คือ ไม่ได้เน้นเทสเพื่อหาบั๊ก แต่เทสเพื่อหาความน่าเชื่อถือ ดังนั้นลักษณะการเทส หรือ data ที่ใช้ test ควรจะเสมือนการใช้งานจริงมากที่สุด ดังนั้นเราไม่ expect ว่าจะมุ่งเน้นหา bug ให้ได้เยอะๆ แต่ถ้าเจอ bug อะไรก็ตามจากการทำ reliability test ให้คิดไว้เลยว่านั่นคือ bug ที่ต้อง fix
3. Performance Test มาถึงหัวข้อใหญ่อีกอันนึงซึ่งหลายๆคนน่าจะคุ้นเคยกับมันมาบ้าง แต่อาจจะไม่รู้ว่า Performance Test เป็น Test ประเภทนึงภายใต้ Non-Functional Test เดี๋ยวเรามาดูกันว่ามันมีประเภทหลักๆอะไรบ้าง แต่บอกไว้ก่อนนะ อาจจะครบ หรือไม่ครบกับตำราต่างๆ อันนี้ไล่จากที่เห็นที่ใช้กันจริงๆเป็นหลักไม่เชิงเอามาจากหนังสือเน้อ
3.1 Load Testing: แบ่งได้เป็นสองประเภท คือ Load Volume (คือกำหนดปริมาณ load ไม่ว่าจะเป็นจำนวน transaction, จำนวน hit/request, size ของ data ที่ทำ load, etc) กับ Load Concurrent user (คือกำหนดปริมาณของ user ที่เข้าไปใช้ระบบพร้อมๆกันในช่วงเวลาที่รันเทส)
เอาจริงๆแล้วถึงแม้ว่าจะแบ่งเป็นประเภทสองประเภท แต่โดยส่วนใหญ่ก็ run test ไปพร้อมๆกันได้ เช่น ให้มี user เข้าไปใช้งาน 1,000 คน และให้ user 1,000 คนนั้น generate search request 500 request/second และ ให้ generate order request 100 request / second อะไรแบบนี้ ก็จะเป็นสิ่งที่ทำให้ load test ของเรา realistic มากขึ้นกว่าการที่สนใจแค่ load volume ที่มาจาก user คนเดียว หรือ ทำ test load concurrent user ที่มีหลายคนเข้ามาในระบบแต่ไม่ทำ transaction อะไรเลย
Measurement: หลักๆ concept key measurement ของ Performance Test หลายๆตัวคล้ายๆกันหมด คือ วัด load ระดับต่างๆ กับ 1. การใช้ hardware resource 2. ประสิทธิภาพของระบบ (ในแง่ของ user experience) เช่น Transaction Timing (ระยะเวลาที่ใช้ของแต่ละ transaction ภายใต้ load ระดับต่างๆ), Response time (ระยะเวลาที่ใช้ในการ response ของระบบเช่น ได้รับ search result ภายใต้ load ระดับต่างๆ), Error rate (% ของ transaction หรือ operation ที่เกิด error ภายใต้ load ต่างๆ — โดยปกติควรเป็น 0 หรือใกล้เคียง 0 มากที่สุด)
วิธีการ test อธิบายแบบ basic คือ test กับ load ต่างๆ เช่น 100, 200, 500, 800 transaction / sec แล้วบันทึก Hardware resource usage (cpu, memory, network, etc) ไว้ และบันทึก พวก response time, error rate ต่างๆไว้ของ load แต่ละระดับทำออกมาเป็น report นั่นเอง
3.2 Stress Testing: จริงๆใช้ concept เบื้องต้นเดียวกับ Load Test คือทำ load volume หรือ concurrent user ก็ได้ แต่มีจุดเพิ่มเติมคือ เราจะพยายามเพิ่มโหลดไปจนถึงจุด Stress หรือเรียกง่ายๆว่าจุดพัง ของระบบนั่นเอง โดยเรามีสิ่งที่อยากรู้ 2 อย่างเวลาทำ Stress Test คือ 1. Which point it break (คือการหาว่าจุดที่พังอยู่ตรงไหน load เป็นเท่าไหร่) กับ 2. What happen when it hit break point (คือการหาว่า เวลาถึงจุดพังแล้วระบบเราเป็นยังไง เช่น data loss, หรือ ระบบช้าลง หรือระบบล่มไปเลย อะไรแบบนี้)
จากรูปข้างบนจะเห็นว่า load test คือการ push load แบบที่ยังไม่ถึง limit ของ system แล้ววัดค่าต่างๆตามที่เขียนไว้ด้านบน ส่วน stress test คือการ push load ให้เกิน limit ของ system เพื่อหาว่า จุดไหนที่เป็น limit และ พอเกิน limit แล้ว system เป็นยังไง (พังแบบไหน) โดยปกติการหาว่าพังที่จุดไหนก็ใช้ key measurement ที่เราใช้กับ load test เป็น indicator ได้เช่น เริ่มมี error rate สูงขึ้น หรือ response time สูงขึ้นแบบกระโดด อะไรแบบนี้ครับ
3.3 Endurance Testing ซึ่งมีอีกสองชื่อที่คนมักจะเรียกกันคือ Longevity Testingกับ Soak Testing สามตัวนี้หลักๆคือตัวเดียวกัน concept แบบเข้าใจง่ายๆคือ test ด้วย load แบบชุ่มๆ (load 70% — 80%) แล้วทิ้งไว้เป็นระยะเวลานานๆ แบบเป็นวันๆ หรือเป็นอาทิตย์ๆ จุดประสงค์คือ ดูว่าระบบสามารถรันทิ้งไว้ด้วย load สูงๆ เป็นระยะเวลานานๆได้มั๊ย (แอบคล้ายๆ reliability test นิดๆในจุดนี้) สิ่งสำคัญที่ต้องดูคือ มื่อ run ทิ้งไว้นานๆแบบนี้ key measurement ต่างๆมีอะไรเพิ่มขึ้นมั๊ย เช่น memory usage ค่อยๆ growth มั๊ย หรือ response time ค่อยๆไต่ขึ้นมั๊ย ที่ต้องดูเพราะว่า ถ้ามันค่อยๆไต่ขึ้นไปแปลว่า เวลาระบบไปใช้งานจริงมันจะถึงจุดพังซักวันเช่น out of memory หรือระบบช้าลงเรื่อยๆจนถึงจุดรับไม่ได้
3.4 Robustness Testing คือการเทสว่าระบบเราอึดถึกทนแค่ไหนกับการใช้งานผิดๆ ในส่วนนี้ก็แอบคล้ายกับ negative test ของ functionality ระดับนึง (ถึงบอกว่าบางอย่างมันมีส่วน overlap กันอยู่บ้าง) แต่เอาเป็นว่าให้เข้าใจว่าเวลามีคนพูดถึง robustness testing มันคืออะไรแบบนี้ละกันนะ
ประมาณนี้สำหรับ Non-Functional Testing ส่วนเรื่องที่ขอทดไว้ก่อน หมดแรงเขียนคือ เรื่องพวก Performance Test ต่างๆจะ Run ยังไง ต้อง Run ตอนไหนในการ develop software การ Design Performance Test strategy ต้องคิดถึงอะไรบ้าง ใช้ tool ยังไง ขอทดไว้เป็น Non-Functional Testing 102 ละกันนะ
คำเตือน เนื้อหาเหล่านี้มาจากความเห็นและประสบการณ์ส่วนตัว มิได้มีหนังสือหรือบทความทางวิชาการใดๆมาอ้างอิง โปรดพิจารณาและปรับเชื่อตามความเหมาะสมนะจ๊ะ
Doppio Tech — We Build And Serve Expertise
