BugDay 2014 เป็นงานเกี่ยวกับโลกของการ Testing จัดโดยทีมงาน WebLoveBug
โดยในปีนี้จัดงานที่ Software Park Thailand
มาดูกันว่าในปีนี้มีอะไรที่น่าสนใจบ้าง
ครั้งนี้มาสายแต่ก็ยังได้รับความรู้ดีๆ ดังต่อไปนี้

ใน Session แรกที่ได้ฟังคือ เรื่อง มือใหม่ Selenium IDE โดย แทนใจ

โดยผมมาถึงตอนเข้ากำลังถามตอบเรื่องต่างๆ
ส่วนรายละเอียดนั้น ผมมาไม่ทันครับ

ใน Session ต่อมาคือ Zero downtime โดยสองหนุ่มจากบริษัท Pronto

จำเป็นต้องมีส่วนต่างๆ 5 ส่วนดังนี้

  1. Environment ที่เหมือนกัน ซึ่งสามารถทำได้ด้วย Virtual Machine(VM) เช่น Vagrant, Docker เป็นต้น
  2. Test-Driven Development (TDD)
  3. Acceptance Test-Driven Development (ATDD) เช่น Cucumber
    1. Tester เขียน scenario
    2. Programmer เขียน step definition เพื่อทำให้ scenario สามารถทำงานได้ ซึ่งเขียนด้วยภาษา Ruby โดยใช้ library เพิ่มเติม เช่น Capybara
  4. Continuous Integration Server ซึ่งใช้เครื่องมือที่ชื่อว่า Jenkins โดยมีความสามารถหนึ่งชื่อว่า Build pipeline สำหรับสร้างขั้นตอนการทำงานต่างๆ เช่น
    1. Build คือการ compile และ package code
    2. ทำการทดสอบพวก Unit test
    3. ทำการติดตั้งไปยังเครื่อง development server
    4. ทำการทดสอบพวก Acceptance test
    5. ทำการทดสอบอื่นๆ อีกมากมาย
    6. ทำการ deploy ไปยัง staging server
    7. Staging มีการทำ Database migration เพื่อทำการแก้ไข schema และ ข้อมูลใน Database
  5. Automated Deployment มีเครื่องมือดีๆ สำหรับการ deploy ระบบงานขึ้น production server

สิ่งที่ทีมพัฒนาต้องทำบ่อยๆ

  • Check-in code บ่อยๆ
  • อย่า check-in code ที่ไม่ผ่าน
  • อย่า check-in code ที่ไม่มี test

ในช่วงบ่าย ….

เริ่มด้วยเรื่อง Automated Load Testing จากบริษัท DST

จะพูดในเรื่องของขั้นตอนการทำ Load testing ระบบ
โดยจะต้องทำตั้งแต่เริ่มต้นระบบ ไม่ใช่มาทำตอนสุดท้าย
เพราะว่า ต้องทำการพิสูจน์สิ่งที่ออกแบบมาว่า มัน work ไหม

ต่อจากนั้นก็คือ Automation and Resiliency จากบริษัท Agoda

สร้างระบบที่ล่มไม่ได้ ตายไม่เป็น

นั่นคือการไม่ให้มีส่วนที่เป็น Single of Failure (SOF)

มีระบบงานต่างๆ มากมาย ดังนั้น อยู่ไม่ได้ถ้าไม่มีระบบที่มัน Automated
มี engineering มากกว่า 100 คน
มี QA สิบกว่าคน

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

คำถาม
สร้างระบบแบบนี้ขึ้นมาทำไม ?

คำตอบ
ในแต่ละนาที แต่ละวินาที นั่นหมายถึงรายได้ที่ขาดหายไป ซึ่งเยอะซะด้วย

การ Automated ระบบต้องมีทั้งการ rollout  และ rollback
ต้องสามารถทำงานได้เร็ว และไม่ส่งผลกระทบต่อผู้ใช้งานใดๆ ทั้งสิ้น

ระบบที่ขาดไปไม่ได้เลยก็คือ ระบบ Monitoring ประกอบไปด้วย

  • Monitoring ของ server เช่น CPU, Memory usage เป็นต้น
  • Monitoring ของ product
  • Monitoring ของ ของผู้ใช้งาน เช่น เวลาของ response time
  • Monitoring ของ business เช่น รายได้ที่เข้ามา จำนวนการ booking เป็นต้น

และเมื่อเกิดปัญหาใดๆ ขึ้นมาจากระบบ รวมทั้งจากระบบ Automated test
จะทำการ alert/notify ไปยังคนที่เกี่ยวข้องทั้งหมด
เพื่อทำให้รู็ถึงปัญหา และ ทำการแก้ไขต่อไป

สิ่งที่น่าสนใจก็คือ
เมื่อใดก็ตามที่เกิดปัญหา ที่ส่งผลกระทบต่อลูกค้า หรือ ผู้ใช้งาน
จะจัด session Lesson learn เพื่อทำการพูดคุยถึงปัญหา
และหาทางแก้ไขปัญหา ปละปรับปรุงให้ดีขึ้น
นั่นคือ Continuous Improvement นั่นเอง

ต่อมาผมก็ขึ้นพูด และ แบ่งปันเรื่องทำ ดี ดี นิดหน่อยครับ

สุดท้ายเป็นช่วง เสวนาพาเพลิน และ ปิดงาน

1. Testing ในไทยเป็นอย่างไร ?
Tester/QA ต้องเร็ว fast feedback
สามารถช่วยทำให้ business มันวิ่งไปข้างหน้าได้
ไม่ใช่ส่วนที่มาบอกแต่ข่าวร้าย
ไม่ใช่ส่วนที่หา bug ให้ได้มากที่สุด
แต่สิ่งที่เปลี่ยนไปก็คือ ทำอย่างไรให้ drive business value ให้มากที่สุด

2.  ถ้า Developer เขียนทั้ง TDD และ ATDD แล้ว Tester/QA จะทำอะไรล่ะ
QA/Tester จะตกงานไหม ?

ตกงานแน่นอน ถ้ายังทำงานในรูปแบบเดิมๆ อยู่
ดังนั้น QA/Tester ต้องปรับปรุงตังเองให้ได้มากที่สุด
การเขียน Test และ Automated test มีหลายแบบ
ดังนั้น QA/Test ต้องพัฒนาอยู่เสมอ และมองคุณค่าในเรื่องของ business มากที่สุด

Developer และ QA/Tester นั้นต้องทำงานร่วมกัน
ไม่ใช่ทำงานแยกกันนะ

แต่เชื่อเถอะว่า ยังไม่ตกงานง่ายๆ หรอกนะ
ถ้า developer มันยังคุยกับคนอื่นไม่รู้เรื่อง

3. Requirement เปลี่ยนทำยังไงดีล่ะ
ยอมรับกับการเปลี่ยนแปลง
เพราะว่า software มันคือการเปลี่ยนแปลง
ดังนั้น ระบบงานที่สร้างขึ้นมา จำเป็นต้องตอบรับกับการเปลี่ยนแปลง
นั่นคือ สามารถเปลี่ยนแปลงได้ง่าย

ดังนั้น ถ้ามีการเปลี่ยนแปลงก็ต้องแก้ไข
แต่ทำอย่างไรให้แก้ไข ได้น้อยที่สุด

ถ้าในเชิงหลักการแล้ว สำหรับการสร้างระบบที่ดี คือ
ถ้ามีการเปลี่ยนแปลงเล็กๆ ทาง business
จะต้องแก้ไขระบบเล็กๆ เช่นเดียวกัน

และอื่นๆ อีกมากมาย เช่น

  • TDD มีข้อดีและข้อเสียอย่างไร ข้อเสียคือ มันใช้เวลาสำหรับเริ่มต้นสูง แต่เมื่อทำมันไปเรื่อยๆ จะช่วยเหลือเรา
  • จะเริ่มทำ Automated Acceptance Test อย่างไรดี  ตอบง่ายๆ ว่า เริ่มที่วิธีคิด ว่าจะทดสอบได้อย่างไร
  • ไม่ได้ทำ regression test ต้องทำ Automated test ไหม ตอบง่ายๆ ว่า ต้องทำ

เจอกันใหม่ในครั้งต่อไป

ขอบคุณพื้นที่สำหรับการแบ่งปันดีๆ ครับ
BugDay 2014 by WeLoveBug.com

Tags:,