“How to Chang from Manual Testing to Automated Testing in Practice Workshop”

Software Testing Process

        Software Testing Process คือขั้นตอนในการดำเนินการทดสอบซอฟต์แวร์ โดยผู้ที่ทำหน้าที่ทดสอบ คือ Tester, Programmer, System Analyst, Business Analyst  โดยจะแบ่งเป็น 2 ส่วนคือ  Test Development และ Test Execution

        1. Test Development ประกอบด้วย 2 เฟสคือ

              1.1 Test Design: การวิเคราะห์และออกแบบ ทำโดย SA, BA, Programmer

                     – Identify Tested Conditions ซึ่งจะต้องใช้คนทำโดยมาหาจาก Requirement เพื่อหาเงื่อนไขที่ถูกทดสอบ

                     – Specify Test Case จะได้ Test Case ในระดับ Unit Test

                     –  Specify Test Scenarios นำ Test Case มาร้อยเรียงเป็น Test Scenarios (End to End)

               1.2 Develop Test Scenarios: การสร้าง Test Scenarios

                      – Prepare Test Data

                      – Prepare Test Environment

        2. Test Execution ที่เป็น Automate

              2.1 Execute Test Scenarios

              2.2 Report Bugs and Defects

             2.3 Execute Retest

             2.4 Execute Regression Testing

             ยกเว้น Fix Bugs and Defects ที่ไม่ได้เป็น Automate

ภาพที่ 1 Software Testing Process

วัตถุประสงค์ของการทำ Automation Testing

        วัตถุประสงค์ของการทำ Automation Testing คือการ Repeat งานซ้ำๆ เพื่อลดกำลังคน ลดทรัพยากร สร้างความคุ้มค่า เนื่องจากมีการลงทุนสูงมากในการหาเครื่องมือ และการเตรียม Environmental ซึ่งการรัน Automation Testing ที่สามารถใช้งานได้บ่อยจะทำให้รู้ว่าเมื่อมีการปรับเปลี่ยนแล้วระบบยังสามารถทำงานได้ถูกต้อง ช่วยให้ประหยัดเวลาหลังจากขึ้น Production ไปแล้ว และลดจำนวนคนในการทดสอบระบบ ซึ่งต้องมีการกำหนดผลลัพธ์ของการทำ Automation Testing ที่สามารถวัดผลได้

Automated Testing กับกระบวนการพัฒนาระบบ

        ในกระบวนการทดสอบจะให้ความสำคัญกับกระบวนการศึกษา Requirements ที่ต้องทำความเข้าใจปัญหาที่ต้องการแก้คืออะไร จากปัญหาต้องใช้ Features อะไรที่มาช่วยปัญหา และมี Solution อะไรที่ไปตอบโจทย์ ซึ่งเป็นจุดตั้งต้นที่จะไปทำ Automation Test

ประเภทของ Requirement

        Requirement จะประกอบด้วย Functional และ Non-Functional

ภาพที่ 2 ประเภทของ Requirement

Test Mapping

        จากประเภทของ Requirement จะประกบคู่มาเป็น  Functional Tests และ Non-Functional Tests 2 ส่วนรวมกันเรียกว่า Acceptance Tests

ภาพที่ 3 ส่วนประกอบของ Software Testing ที่จากการ Requirement

• Functional Requirement
  • ระบบมี Feature อะไรบ้าง แต่ละ Feature ทำงานอย่างไร
• Non-Function Requirement
  • Security test
  • Performance test เช่น Load test, Stress test

Regression Tests Suite

         คือกระบวนการทดสอบที่ต้องทดสอบในส่วนของ Functional ทำตั้งแต่ระดับ Function หรือ Class หรือระดับ Unit Test ขึ้นไปถึง End-to-End Business Test  และ ทดสอบส่วนของ Non-Functional  

       1. Functional Test Suite

           1.1 Unit Test เป็นพื้นฐานสำคัญที่ทำงานร่วมกับฟังก์ชันที่โปรแกรมเมอร์เขียน ที่ต้องทำ Test Case

           1.2 Integration Test หลาย ๆ ตัวที่ต้องทำงานร่วมกัน และต้องทำ Test Case เช่นระหว่าง API กับ Database หรือ ระหว่าง UI กับ API

          1.3 System Test  เป็นการ Test ทั้งระบบที่ทำอยู่

          1.4  System Integration Test เป็นการ Test ร่วมกับระบบอื่น

          1.5  End-to-End Business Process Test ผ่าน API เป็นการ Test ระบบทั้งหมดผ่าน API

          1.6 End-to-End Business Process Test ผ่าน UI (หรือบางที่เรียกว่า UAT) เป็นการ Test ระบบทั้งหมดผ่าน Interface

*** ซึ่ง Function Test ทั้งหมดต้องทำ  Test scenario

        2. Non-Function Tests

            2.1 Performance Test

                 – Workload Model Load Test

                 – Workload Model Stress Test

                 – Workload Model Endurance Test

           2.2 Security Test

ภาพที่ 4 โครงสร้างของ Automate Testing

        Arrange คือ การ Setup สิ่งต่าง ๆ เช่น Data base ที่จะทดสอบกี่ครั้งข้อมูลจะต้องเหมือนเดิม  

        Act คือ สิ่งที่ลูกค้าทำกับระบบส่วนใหญ่จะผ่าน UI

        Assert คือการตรวจสอบว่าระบบทำได้ถูกต้องตรงกับค่าที่คาดหวังหรือไม่

ตัวอย่าง การออกแบบ Automation Test Case เรื่องการคำนวนอัตราภาษีมูลค่าเพิ่ม

ภาพที่ 5 ตัวอย่างการออกแบบ Automation Test Case

ตัวอย่างโครงสร้างของ Unit Test  Case สำหรับ Test Source Code

ภาพที่ 6 ตัวอย่างโครงสร้างของ Unit Test  Case สำหรับ Test Source Code

Test Scenario หรือสถานการณ์ในการทดสอบ

1. 1. ต้องหาเงื่อนไขที่ต้องการทดสอบ
   2. เมื่อมีหลายเงื่อนไขทำให้ต้องร้อยเรียงกัน
   3. มีผลการทำสอบ หรือ Expected Result ร้อยเรียงมาด้วย ซึ่ง 1 เงื่อนไขอาจจะมีหลาย Expected Result
   4. การเตรียมการทดสอบ นำไปทำ Test Data แบบหนึ่งต่อหนึ่ง หรือ เตรียมแล้วใช้ Test Data ชุดเดียวกันได้
   5. สิ่งที่สามารถเขียน Code เพื่อสร้าง Automation Test คือ
      • การเตรียมการก่อนทดสอบ
      • ข้อมูลที่ใช้ในการทดสอบ
      • ผลการทดสอบที่คาดหวัง
   6. ส่วนเงื่อนไขในการทดสอบโปรแกรมเมอร์จะเขียนอยู่แล้ว

ภาพที่ 7 Test Scenario

1. 1. กลุ่ม Function
      • จะใช้เวลาทดสอบ ทั้ง Functional Test Suite ภายใน 5-10 นาที
   2. กลุ่ม Non-Functional
      • Security test จะเป็นทั้ง Test Case/ Test Scenario จะรวมเวลาทดสอบกับ Function Test Suite  Tool ที่ใช้เช่น OWASP
      • Performance test จะกำหนดเวลาให้เหมือนการทำงานจริงมากที่สุดเช่น Performance จะสูงสุดติดต่อกัน 4 ชั่วโมง ก็ต้องใช้เวลาทดสอบ 4 ชั่วโมง

Continuous Integration (CI) Pipeline

        Continuous Integration Pipeline หรือ CI คือ Flow ของการพัฒนา Coding สำหรับการทำAutomation Test ที่ทำอย่างต่อเนื่องและบ่อย ๆ ซึ่งจะ re-running หรือ Execute ทั้ง Function และ Non-Function Test เพื่อให้มั่นใจว่าการพัฒนาระบบและการทดสอบยังคงถูกต้องเมื่อมีการเปลี่ยนแปลงแก้ไข ตั้งแต่ระดับ Unit Test ไปถึง End-to-End Business Test ผ่าน UI โดยใช้เวลาทั้งหมด ไม่ควรเกิน 10 นาที

ภาพที่ 8 Continuous Integration Pipeline

ตัวอย่างการ นำ Requirement มาทำ Requirement spec

1. 1. ขึงภาพระบบตามความต้องการในมุมมองของลูกค้า
   2. ดู Internal Design ประกอบด้วย API หรือ Function ใดบ้าง เพื่อเตรียมการทดสอบ
   3. ดูการเชื่อมต่อกับระบบอื่น เช่น ระบบในหน่วยงานภายใน ระบบของหน่วยงานภายนอก พิจารณาการทดสอบที่เราควบคุมได้ ควรทำ System integrate test ก่อน

ภาพที่ 9 แสดงการทำ Requirement spec แบบ End-to-End Business Process

การทำ End to End Business Process

         นำมาแยก End-to-End Business Process  เพื่อเห็นขอบเขตของงาน โดยแตกเป็น business scenario

ภาพที่ 10 End-to-End Business Process  เพื่อเห็นขอบเขตของงาน

        ทำข้อมูลเพื่อทำการทดสอบ และผลลัพธ์ที่คาดหวังในแต่ละ process  ดังตัวอย่าง Feature Search มี Use Case ค้นหา “ชื่อของเล่น” เลือก วิธีส่ง “Kerry”…. ต้องมีการเตรียมข้อมูล ดังภาพ

ภาพที่ 11 การทำข้อมูลเพื่อทำการทดสอบ และผลลัพธ์ที่คาดหวังในแต่ละ process

กรณีทำสำเร็จ

           ควรทำให้ครบ ตาม End-to-End Business Process

ภาพที่ 12 ภาพรวมการทำข้อมูลเพื่อทำการทดสอบ และผลลัพธ์ที่คาดหวังในแต่ละ process ทั้ง End-to-End Business Process กรณีทำสำเร็จ

กรณีทำไม่สำเร็จ

        กรณีไม่สำเร็จจะไม่ทำ End-to-End Business Process จะดูว่าเกิดจากอะไรได้บ้างที่ทำไม่สำเร็จ เช่นการจ่ายเงินไม่สำเร็จ เพราะวงเงินไม่พอจะอยู่ในบริเวณ PAYMENT จะต้องเตรียมการอย่างไรให้บัตรเครดิตมีเงินไม่พอ

ภาพที่ 13 สาเหตุของการทดสอบแล้วไม่สำเร็จ

ออกแบบ End to End Business Process ผ่าน UI

       การออกแบบต้องตกลงกันในทีมว่า อะไรบ้างจะเป็น Automate อะไรจะเป็น Manual ควรทำ Automate น้อยที่สุด และควรทำเคสที่เป็น Positive

ภาพที่ 14 แสดงการออกแบบ End to End Business Process ผ่าน UI

ออกแบบ End to End Business Process ผ่าน API

        จะเป็นการออกแบบ Integration Test เช่น Integration Test ระหว่าง Web สำหรับ Search Toy กับ APIs โดยต้อง Return ค่ากรณี Success, Client Errors, Server Errors  โดยผู้ดำเนินการทดสอบคือ Developer, Programmer และ CI Tools  ซึ่ง Tools จะวิ่งทดสอบแบบ Headless คือไม่มีการเปิดหน้าเว็บ ซึ่ง Developer, Programmer จะเป็นผู้ทดสอบก่อน และ CI Tools ใช้ทดสอบเป็นระยะ ๆ

ภาพที่ 15 แสดงการออกแบบ End to End Business Process ผ่าน API

ออกแบบการเชื่อมต่อไปที่ Data Store (Integration Test)

        เป็นการทดสอบ API กับข้อมูลที่เก็บในรูปแบบต่าง ๆ ซึ่ง Developer จะต้องเป็นผู้ทดสอบ

ออกแบบการเชื่อมต่อไปที่ Data Store (Integration Test)

        เป็นการทดสอบ API กับข้อมูลที่เก็บในรูปแบบต่าง ๆ ซึ่ง Developer จะต้องเป็นผู้ทดสอบ

ออกแบบ System Test

        เป็นการเชื่อมต่อระบบไปยังระบบอื่นที่จำลองขึ้นมา (Mock หรือ Stub)

ภาพที่ 16 แสดงการออกแบบ System Test

ออกแบบ System Integration Test

         เป็นการเชื่อมต่อระบบไปยังระบบอื่นที่เป็นระบบจริง Server จริง ทั้งภายในและภายนอกองค์กร

ภาพที่ 17 แสดงการออกแบบ System Integration Test  กับระบบอื่น

ภาพรวมการทดสอบ

       ควรทำให้เห็นภาพเดียวกัน ทำข้อตกลงการดำเนินงานก่อนลงมือทำงานร่วมกัน

ภาพที่ 18 การออกแบบภาพรวมของการทดสอบ

ตัวอย่างการทำ Arrange ในส่วนของ Unit Test

        ขั้นตอนการทำงานของ API คำนวนคะแนน ในตัวอย่างนี้จะสนใจเฉพาะ การคำนวนคะแนน จะไม่สนใจสินค้า หรือการตัด Stock ดังนั้นจึงมีการเตรียม Data ดังภาพ

ภาพที่ 19 ตัวอย่างการทำ Arrange ส่วนของการเตรียมข้อมูลสำหรับ Unit Test

         Data จะไหลมาจาก End to End มาทำ API Test และ Unit Test และใส่ Data เพิ่มเติ่มรายละเอียดในการทดสอบเพื่อความถูกต้องมากขึ้น ใน Unit Test  ดังนั้นตอนทดสอบ End to End ก็จะไม่ต้องทดสอบการคำนวนคะแนนในหลาย ๆ แบบ เพราะทำตอน Unit Test ไปแล้ว

        ถ้ามี Function อื่น ๆ ที่ต้องการทดสอบก็จะมีกรอบ Unit Test อีกเรื่อย ๆ โดยใช้ข้อมูล จาก End to End และใส่ข้อมูลอื่นที่สนใจ ตอนทำ Unit Test

         ตัวอย่าง Code ในการทำ UI  Automation Test ด้วย Tool ชื่อ Robot frame work ซึ่งเป็น Open Source โดยเทียบคำสั่งที่ลูกค้าเข้าใจกับรายละเอียด

ภาพที่ 20 ตัวอย่าง Code ในการทำ UI  Automation Test ด้วย Robot frame work

        ตัวอย่าง Web Site สำหรับทดสอบ API

ภาพที่ 21 ตัวอย่าง Web Site สำหรับทดสอบ API

Non-Functional Test

     1. Performance Test

          1.1 Load Test

                ต้องมีการเป้าหมายของการทดสอบ เช่น Order จาก Business Goal ต้องการให้ มี 400,000 Order ในวันเสาร์ อาทิตย์ ภายใน 6 เดือน เพื่อหาจำนวนการสั่งซื้อมากที่สุด ทำการกระจาย พฤติกรรมการใช้งานเป็นช่วง เวลา เพื่อดูการพฤติกรรมการเข้าใช้งาน ดังตัวอย่าง ในช่วง 10-12.00 น.จะมากสุด 100,000 order/2 hours = 14 order/second หรือค่าเฉลี่ย ที่ระบบจะต้องรองรับ และวัดเรื่อง Response Time เช่น < 1 s หรือแปลงเป็นค่า Percentile  95%, 98%, 99%  ซึ่งต้องไปกำหนดเรื่องทรัพยากรที่ต้องใช้ ทั้ง CPU, Memory เพื่อนำไปแปลงเป็น Automation Test 

        1.2 Scalability Test

              จากค่าเฉลี่ย 4 order/second บางองค์กรจะเตรียมทรัพยากรให้รองรับค่าเฉลี่ยก่อน เพื่อให้ปกติทำงานได้ แล้วค่อย ๆ ขยายให้เป็น 14 order/second แล้วดูว่าระบบรองรับได้หรือไม่

       1.3 Endurance Tests

             ถ้าระบบมีปัญหาด้านการรันนาน ๆ เมื่อ Restart แล้วเร็วและเมื่อใช้งานก็ช้าอีก วิธีการทดสอบความคงทนของระบบให้รันเป็นเวลานานขึ้นกว่าเดิม ดูว่า CPU, Memory ใช้มากขึ้นหรือไม่แล้วนำมาหาวิธีการแก้ไขปัญหา

       1.4 Stress Tests

               เอาตัวเลข Order ในอนาคตมาวางแผนว่าระบบรองรับไปถึงเมื่อไหร่ ไกลแค่ไหน

       1.5  Spike Tests

              เมื่อเกิดเหตุการณ์ Work Load เพิ่มขึ้นมากกว่าปกติช่วงเวลาหนึ่ง และระบบอาจจะไม่ทำงานต่อได้เป็นปกติ หรือทดสอบเพื่อป้องกัน DDoS Attack

             การทดสอบ Performance Test จะทำแบบ End-to-End และ Performance Test ทั้ง Loop เริ่มจาก Load Test และตัวอื่น ๆ

    2. Security Test

          2.1 Static Scan

                 จะไม่มี Environment จริง ดูจาก Source Code และ library และทำการสแกนช่องโหว่ต่าง ๆ ด้วยเครื่องมือของแต่ละภาษา ทำก่อน Dynamic Scan โดยเรียกดูความเสี่ยงจาก Risk Database เช่น Java ใช้ SonarQube, Node  ใช้ Lintและ Npm Audit ร่วมกัน, Docker จะใช้ Docker Scan เพื่อสแกน image ว่าไปใช้ Library ที่มีความเสี่ยงหรือไม่

         2.2 Dynamic Scan

                 จะต้องมี Environment จริง มีการ Start Application จริง และมี Tools เข้า Test App ซึ่งเครื่องมือจะนำข้อมูลจากรายงานที่สรุปเรื่องความปลอดภัยที่รวบรวมไว้ เช่น OWASP จะสรุป 10 ช่องโหว่ ที่เว็บโดนเจาะ และออก Spec ว่าถ้าจะป้องกันไม่ให้เว็บโดนเจาะจะต้องทำอะไรบ้าง OWASP จะพัฒนาซอฟต์แวร์ที่ช่วย Scan ช่องโหว่ที่ความความเสี่ยง ชื่อ ZAProxy ซึ่งสามารถดาวน์โหลดลงมาและ Scan เว็บได้เลย

*** Risk Database จะเก็บว่ามีความเสี่ยงที่ Library ไหนบ้าง และมี Pattern ไหนบ้างที่ต้องตรวจสอบ

*** ต้นทุนการทดสอบ

• Unit Test ต้นทุนจะต่ำมาก และมีเครื่องมือให้ใช้อยู่แล้ว เช่น Unit Test for Java
• End-to-End Test ไม่สามารถใช้ภาษาที่พัฒนาอยู่เขียนได้ ต้องหาเครื่องมือใหม่ ๆ มาช่วย เช่น Robot Framework ซึ่งจะต้องมีต้นทุนในการจัดหา และต้นทุนในการศึกษา จึงไม่ควรทำมาก ให้เลือก Use Case ที่สำคัญที่จำเป็นต้องทำ

รวบรวมและถอดบทเรียนจากการอบรมหลักสูตร  

          How to Change from Manual Testing to Automated Testing in Practice Workshop 

          วันที่ 28- 30 มีนาคม 2565