คำถาม
Automated test มันควรเขียนด้วยภาษาเดียวกับที่ใช้พัฒนาระบบหรือไม่ ?
เป็นคำถามยอดนิยมของคนที่จะเขียน Automated test
ซึ่งสามารถตอบได้ดังนี้
ถ้าเป็นคำตอบในอดีตจะตอบว่า ใช่แล้ว
ควรที่จะเขียน automated test ด้วยภาษาเดียวกับที่ใช้พัฒนาระบบงาน
เนื่องจากมันจะช่วยเหลือทีมพัฒนาไม่ต้องไปศึกษาภาษาอื่นๆ
เนื่องจากทีมพัฒนาไม่ต้องเปลี่ยนภาษาไปมา
เนื่องจาก code ของการพัฒนา และ แก้ไขอยู่ที่เดียวกัน สะดวกดี
เนื่องจากง่ายต่อการทดสอบทั้ง unit test, integration test
เนื่องจากทีมพัฒนาสามารถช่วยเหลือได้ เมื่อเกิดปัญหาขึ้นมา
เนื่องจาก …
แต่ คำตอบที่ดีกว่าในปัจจุบันน่าจะเป็น แล้วแต่ทีมมากกว่า !!!
เนื่องจากในปัจจุบันนั้น มี Automated test framework
ที่พัฒนาด้วยภาษาอื่นๆ และมันง่ายต่อการศึกษา และ ใช้งาน
และไม่จำเป็นต้องไปผูกกับทีมพัฒนาอย่างเดียว
ไม่เช่นนั้นก็จะกลายเป็นคอขวดอีก
ลองคิดดูสิว่า Automated test ประกอบไปด้วย
- Unit test
- Integration test
- Functional/Acceptance test
- UI test
ในส่วนของ Unit test และ Integration test นั้น
ควรที่จะพัฒนาภาษาเดียวกับที่ใช้พัฒนาระบบงาน
เนื่องจากมันคือ ความรับผิดชอบหลักของทีมพัฒนา
หรือคุณยังไม่เขียน test กันอีกนะ ?
แต่ในส่วนของ Functional/Acceptance test นั้น
สามารถใช้ภาษาอื่นๆ ได้นะ แต่ต้องพิจารณาดูว่า
ภาษานั้นๆ มันเหมาะสม และ ให้คุณค่ามากน้อยกว่าภาษาเดียวกันเพียงใด
ตัวอย่างเช่น
บางบริษัททำการแยกทีม QA/Tester ออกมาเลย
ถ้าภาษาที่ใช้พัฒนา Automated test ต่างจากภาษาที่ใช้พัฒนาระบบแล้ว
มันจะทำให้ทีม QA/Tester ยากต่อชีวิต
ดังนั้น ส่วนใหญ่มักใช้ภาษาเดียวกันซะเลย
เพื่อให้ share ความรู้และ library กันได้ง่ายๆ
แต่การหาคน หรือ จ้างคนที่มีความรู้ความสามารถทั้ง
เข้าใจ business model
เข้าใจการทดสอบระบบ
รวมทั้งต้องมีความรู้ technical skill ในภาษาต่างๆ เช่น Java, PHP, Python, Ruby และ C เป็นต้น
มันหายากมากๆ ไม่เช่นนั้นก็มีค่าตัวที่สูงมากมาย !!
ปล. คนในกลุ่มนี้เข้าอยากเขียน code กันนักหรอ !!!
คำถาม
ดังนั้น หาวิธีการอะไร ที่มันง่ายกว่าเดิมไหมนะ ?
คำตอบ
ลองใช้ภาษาอื่นๆ บ้างสิ
เพื่อเป็นการทำให้ทั้ง QA/Tester และ ทีมพัฒนา
มีมุมมองใหม่ๆ ในการพัฒนา Automated test
ที่สำคัญ ภาษาที่ใช้มันควรจะ
- เป็นภาษาที่เข้าใจได้ง่าย
- เป็นภาษาที่เรียนรู้ได้ง่าย
- คนทั่วไปอ่านเข้าใจได้
- สามารถทำงานแบบอัตโนมัติได้ง่าย
ตัวอย่างเช่น
- Robot framework
- Cucumber
- RSpec
- Watir
- Fitness
แต่อย่างไรก็ตาม มันก็ขึ้นอยู่กับ
โครงสร้างขององค์กร และ ทีม
วัฒนธรรมขององค์กร และ ทีม
รวมไปถึงความสามารถของคน
จะเลือกทางใดนั้น ควรที่จะพูดคุย
ดึงจุดเด่น และ เสริมจุดด้อย
เพื่อทำให้ทีมสามารถหาเส้นทางเดินที่ดีกว่าเดิม …
Just do it นะครับ เพื่อนำมาเรียนรู้ และ ปรับปรุงต่อไป ..
