จาก Course The Whole Team Approach to Agile Testing ที่สิงคโปร์
มีสิ่งที่น่าสนใจมากมาย หนึ่งในนั้นคือ
เรื่องอุปสรรคที่มักพบเจอจากการนำเอา Automate Test เข้ามาประยุกต์ใช้งาน
ดังนั้น ก่อนจะนำเอา Automate Test มาใช้งาน
ลองกลับมาดูตัวเราเอง ทีม และ องค์กร ว่า
มีอะไรที่อาจจะเป็นอุปสรรคบ้าง ?
1. เรื่องทัศนคติของ Programmer
คำถามที่ Programmer จะถาม หรือ คิดอยู่ในใจคือ
ทำไมต้อง Automate ด้วยล่ะ ?
มีทีม Tester/QA ทำหน้าที่ทดสอบอยู่แล้วมิใช่หรือ ?
มี function ตั้งเยอะ ทดสอบได้ไง !!
ถ้าขั้นตอนการพัฒนาเป็นแบบเดิม
ต้องใช้เวลานานมากกว่าจะทำการทดสอบ
และกว่าจะได้ผลการทดสอบกลับมายัง programmer ก็นาน
ส่งผลให้การแก้ไขช้าไปอีก !!
ดังนั้น เราจึงตัดสินใจกันว่า จะไปแก้ไขใน release ต่อไปล่ะกัน !!
หรือ Programmer บางคนดีขึ้นมาหน่อย
ทำการทดสอบ code ของตัวเอง
ด้วยการนำแนวคิด Test-Driven Development (TDD) มาใช้งาน
แต่ก็สนใจเพียงการทดสอบในระดับ Unit test
โดยไม่ได้สนใจการทดสอบระดับที่สูงกว่า หรือ ภาพใหญ่
เช่น Functional test และ Acceptance test อีก
ดังนั้น สิ่งที่ต้องแก้ไข และ ปรับปรุงก็คือ
การให้ความรู้เรื่องความสำคัญของ Automate test
การให้ความรู้ความเข้าใจของ Automate test
แก่ programmer ซะ อย่าเพียงแต่สั่ง สั่ง สั่ง และ สั่ง
2. เรื่องของ Learning curve ที่สูง และ น่ากลัว !!
เนื่องจากการทดสอบมันคือเรื่องที่ยาก
ยิ่ง Automate test มันยากยิ่งกว่า
ยิ่งถ้าต้องทำให้มันดี มีประโยชน์ มันจึงยากกว่ามากมาย
ซึ่งกว่าจะได้ผลลัพธ์ที่ต้องการ
ต้องลงทุนทั้งแรง ทั้งเวลา และ เงิน
โดยแสดง Learning curve ของการเรียนรู้ Automate test ด้วย Hump of Pain
อธิบายว่า หลาย ๆ ทีมมักจะต้องใช้ความพยายามอย่างมากในช่วงแรก
สำหรับการนำ Automate test มาใช้งาน
ตัวอย่างเช่น ต้องเรียนรู้ TDD, Refactoring รวมทั้งเลือกเครื่องมือ
แน่นอนว่า มันยากมาก ๆ
ดังนั้น ถ้าทีมขาดความรู้ในเรื่องต่าง ๆ
จำเป็นต้องให้เวลาในการเรียนรู้
จำเป็นต้องได้รับการสนับสนุนฝ่าย management
หรือไม่เช่นนั้นก็ต้องหาผู้เชี่ยวชาญมาช่วย
เมื่อความรู้ในเรื่องต่าง ๆ ของ Automate test เริ่มดี
และมีความเชี่ยวชาญในวิธีการ และ เครื่องมือแล้ว
ทุก ๆ อย่างมันจะดีขึ้นตามลำดับ
ดังนั้น การลงทุนในช่วงเริ่มต้นจึงมีความสำคัญอย่างมาก
ลองดูสิว่า ทีมของคุณอยู่ตรงไหน ?
3. เพราะว่า Code มันเปลี่ยนแปลงบ่อย การทดสอบมันจึงไร้ประโยชน์
สำหรับ code ในส่วนการสร้าง User Interface นั้น
เป็นส่วนที่มีการเปลี่ยนแปลงบ่อยมาก ๆ
ดังนั้นการสร้าง Automate test สำหรับ User Interface มันจึงไร้ค่าอย่างมาก
คำถามว่า ต้องทำอย่างไรดีล่ะ ?
คำตอบคือ
การนำ Automate tool พวก record and playback มาใช้น่าจะเหมาะสมกว่ามาก
ส่วน code ในส่วนอื่น ๆ ที่ทำงานอยู่หลัง User Interface
ควรออกแบบและเขียนให้สามารถทดสอบได้ง่าย
รวมทั้ง programmer และ tester ต้องทำงานด้วยกันนะ
4. ทำงานกับ Legacy code มันยากนะ !!
แน่นอนว่ามันยากมาก ๆ
แต่สิ่งที่ต้องการอย่างมากสำหรับทีมคือ
เวลาในการเรียนรู้
ความเข้าใจจากฝ่าย management
เนื่องจาก Legacy code นั้น มันไม่ได้ถูกสร้างมาให้ทดสอบง่ายเลย
ไม่ว่าจะเป็น unit test และ functional test
ดังนั้น สิ่งที่ต้องการอย่างมาก คือ
เวลาในการทำความเข้าใจการทำงาน
เวลาในการ refactor code เพื่อให้ทดสอบได้ง่าย
ดังนั้น ต้องให้ความรู้เรื่องต่าง ๆ ให้ทั้ง
programmer, tester และฝ่าย management
ไม่เช่นนั้น จะไม่มีใครใส่ใจกับ Legacy code เลย
ทั้ง ๆ ที่มันสร้างรายได้ให้กับองค์กร !!
5. ความกลัวต่อ Automate test
เนื่องจากมันคือของใหม่ !
Programmer อาจจะเขียน production code ได้อย่างดี
แต่ไม่มีประสบการณ์ในการเขียน Automate test เลย
Tester แน่นอนว่ามีความรู้พื้นฐานเรื่องของ programming ไม่มาก
อาจจะไม่เชื่อใจ ไว้ใจ การทำงานของ Automate test อีก
ยิ่ง Tester บางคนที่ไม่มีความรู้เรื่อง programming เลย
ก็มักจะบอกว่า ตัวเองไม่พร้อมหรอกนะ
แต่ในความเป็นจริง แล้วมันไม่เกี่ยวเลยนะ
แต่ปัญหาเรื่อง Automate test นั้น
มันคือ ปัญหาของทีม
ไม่ใช่ปัญหาของใครคนใดคนหนึ่งนะ
Tester ก็ทำในสิ่งที่ตนเองถนัด
นั่นคือ การทดสอบ และ สอนแนวคิดการทดสอบให้ programmer สิ
นั่นคือ ทำงานร่วมกันไปเลย หรือ pair programming กันซะ
มันก็ช่วยทำให้ทุกอย่างดีขึ้นกว่าเดิมแล้วนะ
เมื่อใดก็ตามที่เกิดความกลัว
อย่าเดิน หรือ ทำเพียงคนเดียว
แต่ให้ทำกันเป็นทีม
6. เรื่องของนิสัยเดิม ๆ ที่ชอบทำกัน !!
เมื่อใดก็ตาม ที่เราเผชิญกับคำว่า Deadline
เรามักนำนิสัยเดิม ๆ หรือ ความคิดเดิม ๆ มาใช้
นั่นคือ
การละทิ้งทุกสิ่งทุกอย่างที่เรามองว่าไม่จำเป็น
หนึ่งในนั้นคือ ไม่เขียน Automate test
และทำการทดสอบแบบ manual test ไปเลย
และเรามักใช้เวลาทดสอบนาน
พร้อมด้วยความหวังว่า มันจะดี มันจะทำงานได้อย่างถูกต้อง
และค่อยกลับไปสร้าง Automate test ตามหลัง (Later is Never)
หรือถ้าทำแล้วก็ยังไม่ทัน
ดังนั้น ก็ลดจำนวน feature
หรือลดคุณค่าที่จะส่งมอบให้ทาง business ก็แล้วกัน
และเราก็จะทำแบบนี้ไปทุก ๆ รอบของการทำงาน ไปเรื่อย ๆ
แล้วเราก็จะได้ข้อสรุปว่า มันก็เหมือนเดิมนะ !!
โดยผลที่ออกมา มันก็แย่เหมือนกับที่เคยทำมานั่นเอง !!
