qa-non-functional-testing
qa-non-functional-testing

ส่วนตัวผมคิดว่า การเป็น QA ที่เก่ง เริ่มจากพื้นฐานของคิดเป็นหลัก เพราะ QA เป็นอาชีพที่คิดวิเคราะห์ว่าเราจะตรวจสอบระบบยังไงเป็นหลัก แล้วค่อยเสริมด้วยเทคโนโลยีเข้ามาเสริมให้ทันโลก ดังนั้นบทความนี้มาเสริมแนวคิดของ QA อันสุดท้ายเลย ซึ่งก็คือวิธีคิด test cases แบบ Non-functional นั้นเอง

หลังจากเรียนรู้ไรสนุกๆมาเยอะแยะอย่างเช่นบทความ มาเขียน test cases ที่ดีกันดีกว่า? ต้องใช้เทคนิคอะไรบ้าง? กับบทความ เริ่มต้นกับ API Testing ยังไงดี? 🙂 เราก็รู้แล้วล่ะน่ะ ว่าการจะเขียน test cases ที่ดีเราต้องคิดยังไง? เราจะออกแบบการเขียนเทสสําหรับ API ยังไง หรือ แบ่งแยก Layer Test ยังไง ทีนี้เราลืมอะไรปล่าว??? …. บทความพวกนี้ส่วนใหญ่พูดถึงแต่เรื่อง Functional Test! เราลืมคิดถึงเรื่องของ Non-Functional Test!

บทความนี้จะอธิบายวิธีการคิด Non-Functional Test Cases ว่าเราควรคํานึงถึงอะไรบ้าง 🙂

ลองสมมุติ scenario ง่ายๆ เช่นถ้าเรามี ปุ่มนึงในหน้าเว็ป มีไว้เพื่อกด submit ข้อความไปที่ Database ทีนี้ถ้าเราคิดแค่ Functional Test Case เราก็คิดแค่ว่า เรากดปุ่มแล้วข้อมูลจะลง Database รึเปล่า แค่นั้นเอง แต่ถ้าจะคิดถึง Non-Functional Test Case ด้วย เราก็ต้องคิดถึงเรื่องอื่นๆบ้างแล้วล่ะ เช่น

  • ถ้าเราเปิดเว็ป 3 หน้าพร้อมกันแล้วกดปุ่มรัวๆๆๆๆๆเลย Database จะรับไหวมั้ย? จะพังเมื่อไร? (concurrent – load test)
  • หรือ ถ้าเรากดปุ่มแล้วปิดอินทราเน็ตล่ะ ข้อมูลจะเป็นยังไง? (failover)
  • หรือ ถ้าเราปิด Database แล้วกดปุ่มล่ะ จะเป็นยังไง? (failover)

ประเด็นที่จะพูดคือ ถ้าเราคิด test cases เฉพาะว่าการกดปุ่มได้หรือไม่ได้ แค่นั้นมันไม่พอ! เราต้องคิดถึงสิ่งที่ไม่ใช่ Function ด้วย แต่เป็นสิ่งที่อาจเกิดขึ้นได้เมื่อเราใช้งาน function นั้นๆ ซึ่งการจะเข้าใจในจุดนั้นได้ แปลว่าเราต้องเข้าใจ ระบบ และ โครงสร้าง ก่อนแหละ ถึงจะนึกออก เพราะอยู่ดีๆถ้าเราไม่รู้จักอินทราเน็ต เราคงไม่ไปคิดถึงมันเวลาคิด test case หรอกใช่มั้ย? เช่นไปปิดอินทราเนตเพื่อทำ failover เป็นต้น เพราะฉะนั้นการ “เข้าใจ” ระบบที่เรากําลังจะทดสอบนี้ เป็นเรื่องใหญ่เลยล่ะ 🙂

ตัวอย่างของ Non-Functional Test Cases

คงไม่สามารถยกมาทุกประเภทได้น่ะ เอาตัวสําคัญๆที่เราใช้กันบ่อยๆๆดีกว่า จะได้ถึงเวลาจริงเอาไปใช้ได้ถูก

  1. Performance Testing
    (ตัวหลักเลย เวลาใครคิดไรไม่ออกว่า Non-functional มีอะไรบ้างก็จะบอกทํา Performance Testing หรือยัง? แต่ทําไรส่วนใหญ่ตอบไม่ได้หรอก)

    • Load Test = ดู Response Time เป็นหลักว่า เมื่อมีจํานวน Userค่อยๆเข้ามาใช้จํานวนมากๆจะตอบสนองยังไง
    • Stress Test = ดู Behavior ของ server เมื่อเกิด User เข้ามาใช้งานต่อต่อกันเป็นเวลานาน สมมุติน่ะ จุดที่ทําให้มันเริ่มทํางานช้าลงคือ A เราก็จะลองใช้ A นั้นแหละเป็นตัวที่ทดสอบโหลด แล้วสังเกตุอาการเครื่องดู
    • Spike Test = ดู Behavior ของ server เหมือนกัน เพื่อดูว่าเมื่ออยู่ดีๆเกิด User เข้ามาใช้พร้อมกัน1แสนคน ระบบจะเกิดอะไรขึ้น
    • Capacity Test = ดู Behavior ของ server เหมือนกัน ดูว่า server เรารับได้ที่ปริมาณเท่าไร
    • ลองอ่านบทความ Performance Testing 101 เชิงลึกได้น่ะ
  2. Failover Testing
    • การทดสอบเมื่อ Microservices อื่นของเราพัง แล้วระบบเราเองจะจัดการยังไง
    • เช่น เรามีระบบ A ที่พึ่งพาระบบ B สมมุติถ้าระบบ B Fail ล่ม พัง หรืออะไรก็แล้วแต่ที่มันไม่สามารถส่งค่ากลับมาให้เราได้ ระบบ A ของเราจะตอบสนองยังไง? ถ้าระบบที่ดีก็จะไม่ส่ง 500 Internal error ให้ลูกค้า แต่คงแสดงผลในรูปแบบอื่นแทนนั้นเอง
  3. Security Testing
    • เคยคิดถึงเรื่องของความปลอดภัยกับระบบมั้ย? เราจะรู้ได้ไงว่าระบบปลอดภัย? ปัญหาเรื่องความปลอดภัยมีเยอะมาก เช่น SQL Injection, Cross-site Scripting (XSS), etc การจะรู้ได้ว่า Application เราปลอดภัยมั้ย  เราสามารถใช้ tools ง่ายๆของ OWASP ได้เลย เพื่อให้เราวิเคราะห์และป้องกันพวกนี้,etc.
    • โดยปกติใช้ OWASP scan แล้วก็มาอุดช่องโหว่พวกนั้นแหละ OWASP มันจะมีชุดเบื้องต้นว่าจะเกิดอะไรบ้าง แล้วเราก็มาเช็คอีกที
  4. Slow Testing
    • หลักการณ์คล้ายๆ Failover น่ะ คือถ้าตัว dependencies ของเรามีปัญหา ระบบเราจะจัดการยังไง? ถ้าในที่นี้ของเราน่ะ คือถ้าระบบตอบสนองช้าาาาาาาาาามาก ระบบเราจะจัดการยังไง?
    • เช่น ระบบ A พึ่งระบบ B ในการเอาข้อมูลลูกค้า โดยมี timeout ของระบบที่ 5วินาที การเทสก็จะเทสโดยการตั้ง timeout 6 วินาที ดูว่าระบบ A จะทําอย่างไรเมื่อเกิด timeout
  5. Volume Testing (Flood Testing)
    • ในระหว่าง development เนี้ยข้อมูลมันจะค่อนข้างน้อยแน่ๆ แต่พอที่เราเอาขึ้นไปใช้งานจริงบน production enviroment เนี้ย ถ้าลูกค้าใช้น้อยก็แล้วไป (ซึ่งเราควรจะหวังว่าให้ใช้เยอะๆเนอะ :)) แต่ถ้าใช้เยอะมากๆ ข้อมูลมันจะมีจํานวนมหาศาลใน database แล้วระบบเราจะยังทํางานได้ถูกต้องมั้ย? หรือ response ช้าลง
    • เช่น ระบบ A ของเราเนี้ยมีการใช้ select * from snack_table ซึ่งเวลา development phase มันใช้เวลาทํางานนิดเดียว เพราะข้อมูลใน database มี 10 rows แต่พอขึ้น Production มันดันมี 100,000 rows ทําให้ระบบเรา query จนตายไปเลย เป็นต้น
  6. Compatibility Testing
    • การเทสแบบนี้มักเกิดขึ้นกับ API Testing เป็นหลัก เพราะเราจะใช้ในการทดสอบว่าเมื่อเราออก API version ใหม่แล้ว มันจะรองรับ request แบบใหม่หรือไม่
    • เช่น Facebook.com ออก social api v.1.00 ออกมา มีการให้ส่ง json 3 ตัว แต่พอ social api v. 2.00 ออกมา ดันให้ส่ง 2 ตัวพอ ถ้าเราออกแบบระบบดีพอ มันก็จะสามารถรับได้ทั้ง json 3 ตัวและ 2 ตัว ซึ่งเราก็ต้องเทสส่วนนี้ด้วยนั้นเอง
  7. Hardware Issues
    • ดูเหมือนไร้สาระน่ะ แต่เกิดขึ้นประจําจริงๆเวลาที่เรานํา Application ของเราขึ้น Production แล้วเกิดเรื่องของ Disk เต็ม!!!
    • ดูโง่นิดๆๆ แต่เกิดขึ้นค่อนข้างบ่อย อย่าลืมคิดเรื่องนี้ด้วยล่ะ

Best Example Scenario

vending-machine-example-non-functional-test-cases
vending-machine-example-non-functional-test-cases

ตัวอย่างนี้น่าสนใจมาก 🙂 เคส “ตู้กดน้ำอัจฉริยะ” …เรามาเขียน Test Cases สําหรับทดสอบตู้กดนํ้ากันเถอะ โดยเรากําหนดให้ว่า

  1. สามารถสั่งงาน Remotly ได้ แต่…….ต้องเดินมาหยิบเองน่ะ
  2. หยอดเหรียญได้ 1,5,10 บาท
  3. มีการบันทึกว่ามันขายไรไปบ้าง
  4. ถ้าของหมดจะส่งแจ้งเตือนบริษัทให้มาเพิ่มของ ผ่านอินทราเนต

นี้คือความสามารถของตู้กดนํ้านี้! ทีนี้สมมุติถ้าเราจะทดสอบเจ้าตู้นี้มาดูกันว่ามีอะไรบ้าง?

ถ้าเป็น Functional testing ก็คงไม่ยากอะไร แค่เอาข้อ 1-4 มาเขียน test case ว่ามันต้องทํางานได้ตามที่เขียนไว้ แค่นี้ง่ายๆก็จะเป็น Functional testing แล้ว โดยใช้เทคนิคแค่นี้เอง

ขอไม่พูดซำ้น้า 🙂 แต่ถ้าเป็น Non-functional ล่ะ เราต้องคิดอะไรบ้าง???

  1. Performance Testing
    • Load Test = เราจะรู้ได้ไงว่า ถ้าลูกค้าสั่งนํ้าผ่านเนตกันหลายๆคน แล้วเครื่องกดนํ้าจะใช้เวลานานเท่าไร ถึงจะออกนํ้ามาได้ 1 กระป๋อง
    • Stress Test = สมมุติ ถ้ารู้ว่าตู้กดนํ้าจะทํางานยังไงถ้ามีคนมาสั่งนํ้า 200 คนพร้อมกันเป็นเวลาซัก 1 ชั่วโมง? มันจะทํางานตอบสนองได้ถูกต้องมั้ย? มีกี่ request ที่มันตกไป?
    • Spike Test = สมมุติ มีคนหิวนํ้าพร้อมกัน 200 คนล่ะ แล้วสั่งนํ้าพร้อมกันในเวลาเดียวกัน เช่น สั่งพร้ิมกันต้อง 12:00 AM เลย เครื่องจะตอบสนองทุก request มั้ย? หรือ บาง request จะตกไป?
    • Capacity Test = แล้วถ้าเราอยากรู้จํานวนลูกค้ากี่คนที่สามารถสั่งนํ้าได้พร้อมกัน?
  2. Failover Testing
    • แล้วถ้าระบบของบริษัทล่มล่ะ? ในขณะที่ตู้กดนํ้าหมดทุกสิ่งอย่างแล้วส่งข้อมูลไปหาบริษัทแม่เพื่อขอให้มาเติมของ เจ้าตู้กดนํ้าของเราจะทำยังไง? มันจะมีการ retry มั้ย? หริอ retry 3 ครั้งแล้วไม่ติด แล้วอีก 30 นาทีค่อยลอง retry ใหม่ เพื่อให้สั่งของได้? หรือพอต่อไม่ติดแล้วก็จบเลย?
  3. Security Testing 
    • มันต่ออินทราเนตได้แปลว่าก็มีคนแฮคได้? ต้องลองเช็คเรื่องของ request ที่ออกจากเครื่องไป API ของบริษัท
    • หรือแม้แต่มีช่องให้เสียบ USB หลังตู้ได้หรือเปล่า,ทุบกระจกได้มั้ย, แงะฝาตู้เอานํ้าได้รึเปล่า ก็เป็นการคํานึงถึงการทดสอบด้าน security อย่างนึง
  4. Slow Testing
    • ถ้า server บริษัทไม่ตอบกลับมาล่ะ? เวลาที่ตู้นํ้าส่ง request ไป มันจะมี retry? ตอบลูกค้ายังไง? ถ้าลูกค้ายื่นอยู่หน้าตู้กดนำ้
  5. Volume Testing (Flood Testing)
    • มันบันทึกยอดขายลงในเครื่องใช่มั้ย? เวลาเทสคงมีข้อมูลไม่มาหรอก อย่างมาก็หลักร้อยเท่านั้น แต่สมมุติถ้าเปิดใช้งานตู้จริงแล้วคนสั่งนํ้าหลัก 100,000 เลยล่ะ! ระบบ Logging มันจะทํางานยังไง? Log บวมจน append log ได้มั้ย? disk เต็ม? mem ค้าง?
  6. Compatibility Testing
    • ถ้าบริษัทเปลี่ยน API Interface เวลาเติม ตู้นํ้าทั่วประเทศจะรอดมั้ย? หรือต้องรออัพเกรด version ถึงจะส่งข้อมูลไปที่ API ได้ถูก?
    • ก็ต้องเทสทั้ง API version ใหม่และเก่า ว่ามัน compatibility กันมั้ยนั้นแหละ
  7. Hardware Issues
    • เนื่องจากมี Request มาหนักมากกกกก ทําให้ Write log เยอะมากก จนทําให้ Disk Full และเกิด IO Error ขึ้นมาทําระบบตายไปเลย หรือ จะแก้ไขยังไง เพื่อป้องกันไม่ให้เกิดเรื่อง Hardware Issues ขึ้น

จริงๆของพวกนี้ก็ common sense อะแหละ คือถ้าเรามี concept ของหัวข้อต่างๆ เวลาคิดว่าจะเกิดอะไรขึ้น มันก็จะนึกออกง่าย แล้วก็ไล่ตามขั้นตอนมันไปนั้นเอง

สรุปกันนนน

อย่างที่อธิบายไปเลย หลักการเขียน Test Cases มีแค่นี้เอง 🙂

  1. มาเขียน test cases ที่ดีกันดีกว่า? ต้องใช้เทคนิคอะไรบ้าง?
  2. เริ่มต้นกับ API Testing ยังไงดี?
  3. แล้วก็บทความนี้นี่แหละ สําหรับ Non-funcation test cases

เท่านี้ก็จะเข้าใจถึงการคิด test cases ทั้งหมดล่ะ ตัวอย่างให้นึกถึงตู้กดนํ้าไว้ เพราะมันง่ายสุดล่ะ …. จริงๆไม่ค่อยเห็นใครสอนเท่าไรเลยน่ะเรื่องพวกนี้ ขนาดเป็นพื้นฐานของทุกอย่างถ้าจะเป็น QA ไม่ว่าจะ QA automation หรือไม่ก็ตาม (จริงๆก็มีสอนตามพวก test technique น่ะ แต่อ่านเข้าใจยาก)

เดี๋ยวบทความหน้ามาเรียน โจทย์สําหรับการเขียนโปรแกรมกัน จําไว้เถอะว่าพวกนี้สําคัญมากๆๆๆๆเลยการเขียนโปรแกรมเนี่ย ไม่ว่าจะอาชีพ QA หรือ Developer 🙂

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.