Test Data Management: จัดการข้อมูลทดสอบอย่างมืออาชีพ

ไม่ว่าเราจะพัฒนาแอปพลิเคชันหรือเว็บไซต์ด้วยภาษาอะไร จุดร่วมที่จำเป็นต้องทำเหมือนกันทั้งหมดก็คือการทดสอบซอฟต์แวร์ และปัญหาที่หลาย ๆ ทีมมักจะเจอเหมือนกันก็คือ ปัญหาการจัดการข้อมูลทดสอบ เช่น

• ใช้ข้อมูลจริงไม่ได้จากปัญหาของ privacy
• ใช้ข้อมูลทดสอบแล้วไม่ครอบคลุมถึง use case จริง
• ข้อมูลทดสอบไม่สอดคล้องกับฟีเจอร์ที่กำลังพัฒนา

ปัญหาเหล่านี้จะหมดไปหากนักพัฒนามีวิธีการจัดการกับข้อมูลที่ดีเพียงพอ

😎 Test Data Management คืออะไร?#

Test Data Management คือ การสร้าง จัดเก็บ และใช้ข้อมูลทดสอบอย่างเป็นระบบ เพื่อให้การทดสอบซอฟต์แวร์สมจริงและมีประสิทธิภาพมากที่สุด ลดความเสี่ยงจากการใช้ข้อมูลที่ไม่เหมาะสม และทำให้ทีม QA หรือแม้กระทั่งทีม Dev สามารถทดสอบได้โดยง่าย รวมถึงยังใช้งานร่วมกับ CI/CD ได้อีกด้วย

🤔 ปัญหาจากการใช้งานข้อมูลจริงในการทดสอบ#

ในการทดสอบการทำงานของซอฟต์แวร์ด้วยข้อมูลจริงนั้นมีความสำคัญเป็นอย่างมาก เนื่องจากจะทำให้เราสามารถรับรู้ได้ถึง use case จริงที่อาจเกิดขึ้นในระบบ ทำให้การทดสอบเกิดประสิทธิภาพใกล้เคียงกับการใช้งานจริง

แต่ก็มีจุดที่ควรระวังนั่นคือ ความปลอดภัยของข้อมูล นั่นเอง หากมีการใช้ข้อมูลจริงในการทดสอบและไม่ได้ถูกจัดการอย่างมีประสิทธิภาพ ก็อาจจะเสี่ยงที่ข้อมูลนั้นจะรั่วไหล จนอาจเกิดปัญหาได้

🚀 เทคนิคการจัดการ Test Data อย่างมีประสิทธิภาพ#

แม้การทดสอบซอฟต์แวร์ในบางครั้งเราอาจจะไม่สามารถนำข้อมูลจริงมาทดสอบได้ทั้งหมด แต่ด้วยเครื่องมือและเทคนิคต่าง ๆ ที่มีอยู่ก็สามารถสร้างสภาพแวดล้อมให้ใกล้เคียงกับข้อมูลจริงแทนได้ (และบางครั้งอาจจะจำลองข้อมูลแปลก ๆ ในการทดสอบได้มากกว่าเสียด้วย) โดยเทคนิคที่แนะนำมีดังนี้

🛠️ การสร้างข้อมูลจำลอง#

สำหรับข้อมูลที่มีความ sensitive หรือข้อมูลที่มีโครงสร้างชัดเจน บางครั้งเราไม่จำเป็นต้องอาศัยข้อมูลจริงในการทดสอบ แต่สามารถจำลองขึ้นมาแทนได้ เช่น การใช้ factory ใน Laravel เป็นต้น

User::factory()->count(100)->create([
    'email_verified_at' => now(),
]);

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

หากต้องการข้อมูลที่สามารถแยก use case ของระบบได้จริงจะต้องจัดการ factories ให้มีประสิทธิภาพและครอบคลุมมากพอ ซึ่งอาจต้องเป็นการทำงานร่วมกันระหว่าง QA และ Dev

📝 การ Masking หรือ Anonymization ข้อมูลจริง#

เทคนิคนี้จะเป็นการนำข้อมูลจริงมาทดสอบ แต่จะเพิ่มการปกปิดข้อมูลบางอย่างที่เป็นข้อมูล sensitive ของระบบเพื่อให้เกิดความปลอดภัย โดยที่ข้อมูลนั้นต้องไม่กระทบต่อ use case ของการทดสอบระบบ เช่น

UPDATE users SET email = CONCAT('user_', id, '@example.com'), phone = '000-000-0000';

จากตัวอย่างด้านบนจะเป็นการ Masking อีเมลและหมายเลขโทรศัพท์ของผู้ใช้งานทั้งหมดในระบบ ก่อนจะนำข้อมูลอื่น ๆ ไปทดสอบต่อ

🔐 แยก environment สำหรับทดสอบให้ชัดเจน#

โดยปกติแล้วในการพัฒนาซอฟต์แวร์หรือเว็บไซต์ มักจะมีหลาย environment ขึ้นอยู่กับแต่ละทีม แต่โดยส่วนมากแล้วก็จะแบ่งออกเป็น environment สำหรับ Dev ทดสอบ , staging สำหรับผู้ใช้งานทดสอบ และ production เป็นอย่างน้อย นั่นทำให้เราต้องจัดการกับข้อมูลที่จะใช้ทดสอบในแต่ละขั้นตอนให้ดี เช่น

stages:
  - prepare
  - develop
  - staging
  - deploy

workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "develop"'
    - if: '$CI_COMMIT_BRANCH == "staging"'
    - when: never

prepare:
  stage: prepare
  rules:
    - if: '$CI_COMMIT_BRANCH == "develop"'
    - if: '$CI_COMMIT_BRANCH == "staging"'
  script:
    - cp .env.example .env
    - composer install --no-interaction --prefer-dist
    - php artisan key:generate

develop:
  stage: develop
  rules:
    - if: '$CI_COMMIT_BRANCH == "develop"'
  variables:
    APP_ENV: "local"
    TEST_DATA_STRATEGY: "factory"
  script:
    - php artisan migrate:fresh --seed
    - php artisan test --testsuite=Feature

staging:
  stage: staging
  rules:
    - if: '$CI_COMMIT_BRANCH == "staging"'
  variables:
    APP_ENV: "staging"
    TEST_DATA_STRATEGY: "dump"
  before_script:
    - chmod +x scripts/db/pull_prod_dump.sh scripts/db/restore_staging.sh
  script:
    # ดึง production dump + append mask.sql
    - bash scripts/db/pull_prod_dump.sh
    # restore เข้า staging + post-restore adjustments
    - bash scripts/db/restore_staging.sh
    # migrate schema เพิ่มเติม (ถ้ามี) ให้บังคับใช้ใน staging
    - php artisan migrate --force

deploy:
  stage: deploy
  needs: ["staging"]
  rules:
    - if: '$CI_COMMIT_BRANCH == "staging"'
  script:
    - echo "Deploying to staging..."

จากตัวอย่างข้างต้น จะเห็นว่าเราได้แบ่ง environment ออกเป็น develop และ staging โดยที่

ใน develop เราจะใช้ข้อมูลสำหรับทดสอบจาก factory (Laravel) เพื่อให้เกิดความรวดเร็วก่อน

และเมื่อทดสอบผ่าน เราจะทำการทดสอบที่ staging ต่อด้วยข้อมูลที่ dump มาจาก production และทำการ masking ข้อมูลสำคัญออกไป เพื่อให้การทดสอบครอบคลุมมากยิ่งขึ้น

เพียงเท่านี้ก็จะสามารถจัดการกับข้อมูลทดสอบได้อย่างมีประสิทธิภาพมากขึ้นแล้ว

✨ บทสรุป#

การทดสอบซอฟต์แวร์ด้วยเทคนิคของ Test Data Management ไม่ใช่เรื่องของเครื่องมือหรือ framework โดยตรง แต่เป็นแนวคิดที่จำเป็นสำหรับทีม QA และทีม Dev ที่จะต้อง วางแผนและทำงานร่วมกัน เพื่อให้การทดสอบในแต่ละขั้นตอนเป็นไปอย่างมีประสิทธิภาพและครอบคลุม use case ที่อาจเกิดขึ้นและมีโอกาสที่จะทำให้ซอฟต์แวร์เกิดปัญหาขึ้นมาได้

หากการทดสอบเป็นไปได้ด้วยดี นอกจากจะทำให้คุณภาพของซอฟต์แวร์ดีขึ้นแล้วยังทำให้คุณภาพของทีมสามารถทำงานได้อย่างมั่นใจมากขึ้นอีกด้วย 🤗